The relay connection only had `secure`, so with `secure: false` nodemailer
still upgraded to STARTTLS whenever the server advertised it, and there was
no way to talk cleartext to such a server. Pass nodemailer's `ignoreTLS`
through as `ignoreTLS` on the relay config, wired to
--outgoing-ignore-tls / MAILDEV_OUTGOING_IGNORE_TLS / `outgoingIgnoreTls`.
smtp-server reverse resolves every connecting client before it sends the
220 greeting, unless disableReverseLookup is set. MailDev never reads the
resolved hostname, and without a network the lookup does not answer, so
each connection waited for smtp-server to give up on it.
SMTPConnection only calls the connect() callback once the handshake
succeeds; a refused or timed out connection is emitted as an 'error'
event, which was only logged. relay() then never settled, so its finally
block (which now releases the email stream) never ran, auto-relay held
the incoming SMTP transaction open without a reply, and the REST relay
request hung. Reject the connect promise from the 'error' handler.
relayEmail opens a read stream on the .eml file for every relay, and only
client.send() ever consumed it. When the auto-relay rules left no
recipients, or the outgoing server failed the send (e.g. rejected a
recipient), the stream was never read or destroyed and its file
descriptor stayed open. Destroy it on the early return and in the finally
block; after a successful send it is already fully read, so that is a
no-op.
MAILDEV_HTTPS is listed in BOOLEAN_VARS, but envVarToConfigKey() had no
entry for `https`, so the boolean pass skipped it and the raw string from
ENV_MAPPING stayed in the config. MAILDEV_HTTPS=false then enabled HTTPS
and validation demanded httpsCert and httpsKey.
* fix: build CID attachment URLs against the API route and base path
replaceCidReferences rewrote cid: references to /email/:id/attachment/:file,
which matches no route: attachments are served from the API server, mounted
at ${basePath}/api. When MailDev sits under a subpath the prefix was missing
as well, which is the setup described in #439.
Emit ${basePath}/api/email/:id/attachment/:file, root-relative by default, and
thread the API server's basePath through getEmailHtml. baseUrl still prefixes
//host for a caller that passes it.
On the current code this does not change what the web UI shows for a typical
message: mailparser already inlines related parts as data: URIs, and a cid:
that survives parsing is one that matches no attachment. replaceCidReferences
is exported from @maildev/smtp, though, so the URL it builds should resolve.
Refs #439
* fix: omit the base path prefix when it resolves to the root
A caller passing basePath '/' produced //api/email/..., which a browser reads as a protocol-relative URL rather than a path. Strip the slashes first and only add a prefix when something is left.
A caller passing basePath '/' produced //api/email/..., which a browser reads as a protocol-relative URL rather than a path. Strip the slashes first and only add a prefix when something is left.
replaceCidReferences rewrote cid: references to /email/:id/attachment/:file,
which matches no route: attachments are served from the API server, mounted
at ${basePath}/api. When MailDev sits under a subpath the prefix was missing
as well, which is the setup described in #439.
Emit ${basePath}/api/email/:id/attachment/:file, root-relative by default, and
thread the API server's basePath through getEmailHtml. baseUrl still prefixes
//host for a caller that passes it.
On the current code this does not change what the web UI shows for a typical
message: mailparser already inlines related parts as data: URIs, and a cid:
that survives parsing is one that matches no attachment. replaceCidReferences
is exported from @maildev/smtp, though, so the URL it builds should resolve.
Refs #439
dualfroz
upstream