Re: [exim] unblocking gmail

トップ ページ
このメッセージを削除
このメッセージに返信
著者: W B Hacker
日付:  
To: exim users
題目: Re: [exim] unblocking gmail
Randy Bush wrote:
> Chris Edwards wrote:
>> | > Others have sugested the spf plan. But if you simply want to check the
>> | > DNS hostname, then add something like this to the ACL statement:
>> | >
>> | > !hosts = *.google.com : *.yahoo.com
>> |
>> | by double map i meant the in-addr and then a forward check.
>>
>> Yep - Exim does the two-way check by default, and if it fails, then the IP
>> is considered to not have a DNS hostname.
>>
>> So:
>>
>> - "hosts = *.google.com" is false
>> - "!hosts = ..." is true
>> - the host is subjected to your RBL test, as desired.
>
> please explain why
>
>      accept  !hosts        = *.yahoo.com

>
> accepts the following spam
>
> 2008-12-06 02:43:59 1L8n9A-000H6D-V3 <= tequilamockingbird1957@???
> H=([220.194.0.165]) [220.194.0.165] P=esmtp S=835
> id=4f119e23$517da2fb$0ec21d85@tequilamockingbird1957
>
> what am i not understanding?
>
> randy
>


All other considerations aside, any 'accept' is definitive or
'permanent' only within its acl_smpt_<whatever> phase clause-set.

IOW - the default behaviour if NOT matched is to continue checking
subsequent clauses AND subsequent phases. Which may or may not match
and/or may *default* to accept.


A 'deny class' verb (deny, drop, defer) OTOH, is the reverse.

Permanent. Final. Irrevocable. Not just for the phase, but for all.

No further checking is done *anywhere*.

So if you *really* want to block 'the real' *@yahoo.com' and not just
forgeries of it, you would use a 'deny on match', not an 'accept on
fail-to-match'.

But this might serve you better:

warn
   log_message     = MF5 Apparent forged Yahoo
   senders         = *@yahoo.com
   condition       = ${if match  /* remove this line-wrap */
                    {$sender_host_name}{\Nyahoo.com$\N}{no}{yes}}



Grep your logs for 'MF5' insure it is doing what is expected, then
change the warn verb to a deny if/as/when satisfied.

CAVEAT: You may see zero hits if you have already rejected on rDNS fail
and/or dynamic-IP RBL hit and/or HELO mismatch.

We check more than a dozen m'major' ISP as above, but all forgeries
we've ever seen had come from zombies w/o PTR RR who usually have all
the rest wrong as well....

HTH,

Bill