I've been meaning to do this for some time now, but didn't get around to it
until this winter's break.
As the bug (
http://bugs.exim.org/show_bug.cgi?id=1201) I've logged says:
> The modern world of spammers faking envelope-from combined with antispam
> defences doing content-scanning, combined with 2MX service provided by
> separately maintained systems, results in a bounce problem.
The (partial) solution developed for review by the assembled masses:
Make an onward SMTP connection for delivery while the inbound
SMTP connection is still active. Do not accept the data-content of the
mail from the inbound until the destination system has had a chance
to positively reject the mail.
This requires copying the data from the inbound connection to the outbound.
To retain traditional mail reliability a spoolfile is still written, and retained
for queued delivery in the case of a connection error or temporary-rejection
from the destination.
The implementation adds an ACL "control = cutthrough_delivery" modifier,
usable in recipient ACLs. If set then a following recipient-verify callout connection
is held open for later use during data-phase. If no such connection was made
during the ACL one is made automatically.
The intent is that the system providing 2MX service set this control for such
items, preferably before any recipient-verify-with-callout.
Gotchas and oddities:
- The Received-by: header line added by this system has a timestamp of the
*start* of reception for item where cutthrough was attempted, rather than
being that *after* reception as is traditional.
- The delivery log line appears *before* the acceptance log line rather than after.
It is flagged with ">>" rather than "=>" or "->".
- If the local data-time checks (ACL, local-scan etc) reject the item, the cutthrough
connection is rudely dumped, wasting the effort of passing the data on.
The second of the two patches attached to the bug extends the cutthrough routing
support into making TLS connections for the outbound. Since the connection used
is made by the ACL verify callout code rather than the SMTP transport code, additions
were needed for TLS - the callout code only ever did HELO! The code changes are
however quite extensive as the TLS support assumed there would only ever be
one TLS connection active at a time, and we need (potentially) two for the in-
and out-bound side SMTP. The cutthrough logging code is tidied up a little also.
--
Jeremy
