--On 9 December 2010 12:05:34 +0000 Jeremy Harris <[email protected]> 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/ -- ## List details at http://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/
