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
