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
