Re: [exim] UCEPROTECT Blacklists and why callouts are abusiv…

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] UCEPROTECT Blacklists and why callouts are abusive
Stuart Gall wrote:
> On 18 Oct 2006, at 11:46, Renaud Allard wrote:
>
>
>>Indeed, but, as mentioned before, some will argue that if the spf is
>>false you have no right to use their resources to verify things as
>>it is
>>probably a spam. And if spf != pass && spf != false (IE: not defined)
>>you still have no right to do a callout as you could be a player in
>>a ddos.
>>So there is no real solution to this, the best practice would be that
>>the callout should be your last line of defense (just before data
>>session). And also that it should be avoided if the host is trusted
>>(but
>>this last one is probably nearly unmaintainable for large
>>environments).
>
>
>
> One thing exim should probably do or at least have the facility to do
> is add all successful outgoing addresses to the callout cache.
>
> Or put it another way
> is there some way I can create a whitelist of all successful outgoing
> envelope to's so that I can use it in the rcpt acl
>
>
> Stuart


Not as fine-grained as all that but works to avoid BL'ing any <domain>.<tld>
that *any* user in *any* of our virtually-hosted domains has SENT to, and seres
as a user-controlled AWL as well:

====
  warn
     condition   = ${lookup{$sender_host_name}dsearch{/data/mail/archive}{yes}{}}


(then set a flag and use as needed...)

ELSE just NOT the condition before blocking....

- Where '/data/mail/archive' is the outbound-archive dirtree, stored by an
'unseen' router/transport set that places them by destination <domain>.<tld>,
not sender.

Creating /data/mail/archive/<domain>.<tld> lets you manually open a hole, so
too, sending a message to the person formerly blocked.

Other rules, etc. to keep it within bounds, of course...

HTH,

Bill