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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
