--On 9 December 2010 12:05:34 +0000 Jeremy Harris <jgh@???> wrote:
> On 2010-12-09 03:56, W B Hacker wrote:
>> IOW: rejection=SOMETIMES, (post-session) bounce=NEVER
>
> Recipient callouts can't help for the case of data-time reject
> (commonly dues to content-scan for virus/spam).
>
> I've often wanted to get the tuits together for a synchronous-delivery
> mode switch in Exim - a control modifier for ACL which converts
> the existing source session by placing an immediate destination
> recipient callout and then hooks the pair of datastreams together.
> The intermediate Exim would, apart from copying data and responses,
> only monitor for the termination of data phase. The point of
> doing this is to get the ultimate recipient system's response back
> to the sender, synchronously, avoiding another class of bounces.
Which is fine if you've only got one recipient, or where the response is
the same for all recipients. For multiple recipients, you'd want to be
using LMTP.
I'd propose LMTP as an SMTP service extension, which would work roughly
like this:
In the response to LHLO, a server could return a new EHLO keyword: "LMTP".
If the client supports it, it can now issue the command "LMTP" at any time
before issuing the MAIL command. Subsequent message transmissions are now
treated as LMTP submission, with the reply after data transmission giving a
return code for each recipient that was accepted at RCPT - as in 4.2 of RFC
2033
In a session, between message deliveries, clients can say "SMTP" to
indicate that subsequent messages should be handled according to SMTP
protocols instead of LMTP protocols. A session might switch back and forth
between LMTP and SMTP - always between messages - as many times as
necessary. I'm not sure I can think of a reason why - but perhaps when
punting to a smart host, a client might want to use LMTP only when all
recipients were known to be in the local domain.
Section 5 of rfc2033 argues against this, but there may be ways of
mitigating the problems identified there. For example, servers might choose
to queue messages for local recipients for whom they would otherwise return
a 4xx temporary failure message. Clients would need to remove recipients
from the recipient list in the event that the message was delivered to some
but not all recipients.
> The control would typically be used in the RCPT or PREDATA ACL.
> If we needed to be able to code it in earlier ACLs the implementation
> would have to delay action until RCPT time. If we needed to handle
> it at DATA (or MIME) time then we would play out the already-written
> spool file (note that the RCPT-time usage avoids disk I/O, a minor
> benefit). I don't see any use in QUIT, NOTQUIT, EXPN, VRFY, ETRN. I've
> not thought hard about not-smtp, but it would probably work like RCPT.
>
> A fallback to traditional store-and-forward mode should be available
> if the target system is unavailable. Bounces would still be generated
> for this case as per current handling; we're only addressing the use
> of MX for "user moved on" forwarding, not "resilience versus intermittent
> connectivity".
>
> Cheers,
> Jeremy
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see
http://www.sussex.ac.uk/its/help/
