Re: [exim] Follow up to hole in bucket message

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] Follow up to hole in bucket message
Phil Chambers wrote:
> There is a spam-blocking scheme where you allow users to opt in or out of SMTP
> rejections. This is done by deferring at RCPT TO time any users who have opted
> differently from the first recipient. So, at DATA time you can to accept or
> reject all recipients which did not defer because they have all opted the same
> way. You expect the other recipients to arrive in a re-try later.
>
> Is this widely used? Are there any significant reasons for not doing it?
>
> Phil.
> ---------------------------------------
> Phil Chambers (postmaster@???)
> University of Exeter
>
>


IMNSHO, not all that widely, and more trouble than it is worth.

But ...

'..and the ape went out a fifth way..'

Aside from correcting the OP's SQL, there are two other things required
to avoid the necessity of deferals:

1) One needs to calculate the MIN and MAX acceptable thresholds for the
'ad hoc group' of recipients - not just one figure (done when passing
through acl_smtp_recpt_to ) and carry those values forward.

2)

- if below MIN (the most paranoid recipient would accept) then it is
accepted for all.

- if above MAX (the most generous recipient would reject) then it is
rejected for all.

- betwixt and between, the fakreject triggers.

This has been tested extrensively, though no longer in production here.

Why so..

CAVEATS:

A) Most arrivals in a group will be for the same domain.tld, and, at
least in our case, settings tend to be much the same for all users in a
given commercial enterprise. Ergo, the gain isn't worth the pain.

Universities, to name one, and 'general service' ISP's will have a
different experience.

B) The 'fakereject' message, in our case (w/o MUA line-wraps..):

control     = fakereject/HAS BEEN DELIVERED, but marked as Spam, so 
MIGHT NOT BE READ!


Cannot be counted on to accomplish much.

C) The instances where it triggers are usually 'edge' cases anyway, yet
the calculations et al have to ba applied all the time because of the
smtp sequencing.

D) Again not universal - in our case a very high percentage of arrivals
were 'singleton' recipients - so it is ALL for nought.

YMMV, but we found it not worth the bother for typical SME clients.


Bill Hacker