Re: [exim] Per-recipient post-DATA acknowledgements

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: W B Hacker
Ημερομηνία:  
Προς: exim users
Αντικείμενο: Re: [exim] Per-recipient post-DATA acknowledgements
Ian Eiloart wrote:
>
> --On 8 October 2008 00:06:24 +0800 W B Hacker <wbh@???> wrote:
>
>>> I favour XPRDR technically (strict timeouts enable tarpitting without
>>> losing compliant hosts, for example),
>> Not sure that cannot be done 'easily enough' anyway... and w/o overly
>> relying on timeouts.
>
> The problem is that some M$ clients time out earlier than some spambots.
>
>


*That's* not a problem.

Few spambots are either authenticated or in possession of PTR records
and HELO's that match a DNS record. They are mostly gone - or at least
'tagged' before acl_smtp_data.

M$ UA clients come in on a different port (587) and protocol (TLS/SSL)
in order to AUTH, so not expected to have those. Different acl's process
'em.

M$ alleged-MTA (Exchange) as clients can follow the rules, same as
everyone else, OR be whitelisted.. or go pound sand..

Workable per-user prefs for those things - all of which precede DATA,
are a road well-travelled.

Can't boil the ocean with a post-data-phase tool. But we could improve
the coffee, particularly w/r eliminating post-smtp DSN's..

Mind - IF/AS/WHEN we get the 'tools' - my plan is to stop deferring
second and subsequent delivery for those arrivals who can agree to a
post-data handshake. ELSE NOT. May be BFBI, but one-at-a-time is all we
have at present, and it works, and works well.

Either way, a post-data-phase DSN goes only to our own user community -
either when we are told 'no can do' by a destination (during smtp), or
when retry has run its course (by definition, no other server involved).

No risk with either of those.

Bill