fix: let a deployment name itself in the SMTP greeting

A real deployment could not send mail through an IP-authorized relay.
Every attempt surfaced as MAIL_PROVIDER_UNAVAILABLE while the relay was
healthy and swaks sent from the same machine.

The cause was the greeting, and it is generic rather than tied to any
provider. An SMTP client identifies itself in EHLO, and with nothing
configured Nodemailer derives that from the machine hostname —
substituting the address literal [127.0.0.1] whenever the hostname is
not fully qualified, which is the normal state of a container. The relay
closed the connection on it with a 421 before any message was offered,
which is indistinguishable from the relay being down.

EKKLESIA_SMTP_HELO_NAME now lets the deployment say what to greet as. It
is validated as a fully qualified domain name — no scheme, port,
brackets, whitespace, or control characters, and at least one dot, since
a single unqualified label is exactly the input Nodemailer already
discards. It is not a credential: it travels in the clear on every
connection, so Doctor prints it where an operator can compare it against
what the relay expects, and Doctor's probe performs the same greeting the
runtime does.

Absent preserves Nodemailer's behaviour exactly. It is deliberately not
defaulted to the sender's domain: a machine whose hostname is already a
valid FQDN may be greeting correctly, and some relays check that against
reverse DNS, so replacing it silently would trade one deployment's bug
for another's.

The regression guard is a raw SMTP server that refuses any greeting but
the expected one, because smtp-server exposes no EHLO hook and its
earliest hook is never reached by a send-nothing probe.

Co-Authored-By: Claude Opus 5 <[email protected]>

core/tests/host-configuration.test.ts

@@ -20,6 +20,7 @@ const productionEnvironment = Object.freeze({
   EKKLESIA_MODULE_SECRET__ANNOUNCEMENTS__STORAGE_CREDENTIAL: "module-secret-material",
   EKKLESIA_SMTP_FROM_ADDRESS: "[email protected]",
   EKKLESIA_SMTP_FROM_NAME: "Ekklesia",
+  EKKLESIA_SMTP_HELO_NAME: "mail.example.org",
   EKKLESIA_SMTP_HOST: "smtp.example.org",
   EKKLESIA_SMTP_PASSWORD: "sup3r-secret-relay-password",
   EKKLESIA_SMTP_PORT: "587",
@@ -67,6 +68,7 @@ describe("host configuration loading", () => {
     expect(host.mail).toEqual({
       fromAddress: "[email protected]",
       fromName: "Ekklesia",
+      heloName: "mail.example.org",
       host: "smtp.example.org",
       password: "sup3r-secret-relay-password",
       port: "587",
@@ -80,6 +82,9 @@ describe("host configuration loading", () => {
     });
     expect(relayByAddress.mail.username).toBeUndefined();
     expect(relayByAddress.mail.password).toBeUndefined();
+    // The SMTP client identity is optional too, and unset is the ordinary case: it matters only
+    // where the machine's own hostname is not a fully qualified name the relay accepts.
+    expect(relayByAddress.mail.heloName).toBeUndefined();
     // A source-IP-authorized relay has no credentials at all, and that must still validate.
     expect(createMailProviderConfig(relayByAddress.mail)).toBeDefined();
   });