Autor: W B Hacker Fecha: A: exim users Asunto: Re: [exim] splitting mails
Jethro R Binks wrote: > On Wed, 18 Apr 2007, Marc Sherman wrote:
>
>> Ronan McGlue wrote:
>>> Is there any trick in the book that I could use to take all multiple
>>> recipient messages and resubmit them as multiple single recipient
>>> messages at the MTA level?
>> In the RCPT acl, defer all RCPTs past the first (checking $rcpt_count in
>> a condition). This causes the sending server to resubmit the message
>> later with the next recipient.
>
> This has been suggested before, and ACLs suggested for it.
>
> However, I have often wondered about its reliability? Do most
> well-behaved MTAs properly re-transmit only the refused recipients (second
> recipient and higher)?
We have an R&D box running a version of that for months.
So far, very reliable. The typical delay, however is anywhere from 2 to 15
minutes for each sucessive recipient. Can be hours before the last one straggles
in, and a large enough list can be abandoned before it is finished.
Also not easy to explain why three folks at adjacent desks in the same office
get their copies spread out over half an hour instead of at the same time.
Plus - it is technically a violation of the RFC, which wants you to accept at
least 100 recipients per go.
Good news is that it is transparent on all singleton arrivals, 'nearly so' when
there are only two recipients, and it *does* help boot out the zombots with
dictionary attacks.
> Are there cases where an MTA will try and submit
> all the recipients again on re-connecting?
Cannot be ruled out, just not enough data here. But we haven't seen that yet
except on zombots.
> Is it a big enough problem to
> worry about?
>
> Jethro.
>
That last part depends entirely on your clientele - their typical arrivals
profile and need for prompt receipt - plus what *their* correspondents expect as
to response timeliness.
I'd rather see Sam's experimental extensions to DATA imported from Courier-MTA
so that there would at least be TWO MTA that could handle per-recipient DATA
phase selection.