Re: [exim] splitting mails

W B Hacker wrote:
> 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.

We have had a production system here for a few months doing something
similar for user-specific spam preference settings - any that don't
match the first are temporarily rejected.

Very few problems reported. There should never be more than three
re-tries needed as there are only four spam preference options, so
delays may exist but are not a major issue. (The large majority of users
use the default setting, which helps here too).

> Plus - it is technically a violation of the RFC, which wants you to
> accept at least 100 recipients per go.

I admit I haven't gone back to the RFC, but can it really intend that we
have to accept all recipients or none? (assuming there are no more than
100)

> 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.

Yes, but not many. Where there are issues with a specific (non spam)
sender we can advise the remote site to get their mailer fixed or our
users to agree their spam preference or all (or none) to whitelist the
sender.

> > 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 wouldn't say it's a show stopper (I can't even recall any queries for
some time now).

> 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.
>
> 'Worthwhile experiment' that one would be.
>
> HTH,
>
> Bill


Richard

--
Richard Rogers
IT Development and Innovation Manager
Staffordshire University


The information in this email is confidential and is intended solely for the addressee. Access to this email by anyone else is unauthorised.



If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, except for the purpose of delivery to the addressee, is prohibited and may be unlawful. Kindly notify the sender and delete the message and any attachment from your computer.