Jeremy Harris 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).
Agree that. Generally. OTOH, if valid/invalid recipient is known AT acl_smtp_rcpt time - there may BE NO DATA phase, so... The case you outline below is of a different shade, however.. > > 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. > .. and requires rather few coding 'tuits'. One can do that now w/o modifying Exim itself at all. Take as a jump-off point the path Tom provided for in-session scanning, for example: Much akin to providing the message 'copy' to cooperative scanners, such as ClamAV, SA et al - except that the external executable called in this special case onpasses the message and reports back the smtp code instead of eating it and reporting how it tasted. EITHER - Got a '250 OK'. Now do an 'accept' and blackhole your own no-longer-needed copy to /dev/null. ELSE - was *unable* to deliver. Now do a [defer | deny] in the customary manner. But see below... Exim doesn't really need that sort of 'help'.. > 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). Not always 'minor', but spool file space is ordinarily MUCH larger than RAM.. > 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. AFAICS, acl_not_smtp is more akin to directly 'being born' already in the DATA phase. There are no 'handshakes', and the bytes are already on-box. > > 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 > At the end of the day, however, Exim's existing toolset for relaying is *highly* flexible and configurable, so should be good enough with no more than the odd - perhaps *very odd* tweak. And perhaps smacking a bit higher level of cooperation out of/into the downstream(s). Which is essential in any case.. Bill -- ## 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/
