Re: [exim] adding a header to a message in an ACL, even whe…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: W B Hacker
Datum:  
To: exim users
Betreff: Re: [exim] adding a header to a message in an ACL, even when the condition defers
Josip Rodin wrote:
> On Tue, Nov 14, 2006 at 04:15:56AM +0800, W B Hacker wrote:
>>> 2006-11-13 08:32:13 1GjWIe-0006bK-LW H=unicorn.laczpol.net.pl
>>> [193.24.220.34]:2930 I=[192.168.54.235]:25 Warning: ACL "warn" statement
>>> skipped: condition test deferred: all attempts to verify a sender in a header
>>> line deferred
>> If it had been truly 'skipped' the logger would not have known anything about it
>> though - least of all that it had tried to make a callout and 'all attempts..'
>> were deferred. 'condition could not be evaluated in the time permitted' is what
>> happened. It DID try.
>>
>> 'Skipped' would have been 'too tired, ain't trying no more callouts today'
>>
>> ;-)
>
> Okay. It's still a bit unsettling to see this in the log file. It also
> clutters it a little bit.
>
>> 1) insure that *your* server supports a response to the sender verify of
>> *others*. That wins YOU credibility and helps traffic flow smoothly.
>
> Granted.
>
>> 2) Rather than penalize on the sometimes unreliable 'fail' of a sender
>> verify,
>
> It's not fully reliable, I know, but it's good enough for my purposes.
> Elsewhere I just reject unverifiable senders, but on this system I wanted
> to be a bit more careful and make it an SA score.
>


You can (also) limit the test to a 'hostlist'.

You can also set 'points' then add the result to the SA spam_score-int or
spam_score instead of having SA actually check (again).

SA runs much faster with fewer tests.

>> instead use the result of a sender verify *success* as 'positive' QC
>> points.
>
> That sounds like a good idea in theory, but spammers have long been abusing
> other people's valid addresses to deliver their crap.
>


They certainly do, yet another reason we don't bother with callouts here.

But that is another sort of test - not just as to whether a HELO/EHLO
backtracks, to 'something', but as to seeing if it is a 'probable' forgery w/r
the arrival IP used (not always guaranteed, either, BTW. Think pools w/o proper
DNS, as in NetSol):

Less of a problem since the 'big guns' have started spending serious bucks to
take away the Porsche's of the vermin, but 'used to be' essential code:

   warn
         log_message     = MF5 Forged Yahoo
         senders         = *@yahoo.com
         condition       = ${if match \
                           {$sender_host_name}{\Nyahoo.com$\N}{no}{yes}}
         set acl_m2      = $acl_m2 Forged Yahoo Address=100
         set acl_m5      = ${eval:$acl_m5 + 100}


   warn
         log_message     = MF5 Forged  hotmail or MSN
         senders         = *@msn.com
         condition       = ${if match \
                           {$sender_host_name}{\N(msn|hotmail).com$\N}{no}{yes}}
         set acl_m2      = $acl_m2  Forged MSN Address=100
         set acl_m5      = ${eval:$acl_m5 + 100}


...and a dozen others...

Scoring is in acl_m5, message in acl_m2 both for later use.

HTH,

Bill