Re: [exim] Data ACL - Received: from header

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: W B Hacker
Data:  
Para: exim users
Asunto: Re: [exim] Data ACL - Received: from header
Lena@??? wrote:
>> From: W B Hacker
>
>> But if it is a botnet, would it not fail:
>>
>> - forward/reverse lookup test?
>
> In such cases (and in cases of dynamic-looking hostname)
> I greylist instead of deny. Quite effective usually.
> I'm afraid of false positives.


CAVEAT: What has worked long and well for me may not fit 'others'.

- An IP WL that skips some/all of what follows:

- NOT advertising 'pipelining', and dropping those who ignore that.

- hard reject if no PTR RR *at all*. 'false positives' on this are not 'false'.

- add an 'earned' delay of 15s, PLUS heavy 'demerit' score for the 'full
forward/reverse lookup fail as it is usually, but *not always* the result of
finding a 'generic' adsl/dsl PTR RR but no matching A or MX.

Few 'bots are programed with sufficient patience to hang around for more than
roughly 13-14 seconds.

>
>> - AND the HELO <=> FQDN match test?
>
> Plenty of legitimate senders have $sender_helo_name differing from
> $sender_host_name. I even don't greylist if they differ.
> I greylist if $sender_helo_name doesn't contain a dot
> or is a bare IP-address or literal (IP-address in square brackets).


Properly bracketed IP-literal are protected by the RFC, though widely rejected.

We allow them - but only if destined for postmaster@, abuse@, hostmaster@,
webmaster@, as the incoming could be a kind soul telling us our DNS is broken.

> Besides, I have long local blacklists (which deny) separately for
> $sender_helo_name, $sender_host_name and $sender_host_address.
>


I use a single list for all of those, then do regex calls against it, not 'host'
or 'hostlist', as by definition most entries long-since failed any external
lookups, and I don't even want to look yet-again at a cache.

>> If you don't mind onpassing a few samples, I'll be happy to see if they've been
>> 'seen' here, and if so, which of our rules they escaped... or were caught with.
>
> The last two with fake Received which escaped my deny rules,
> didn't escape my greylisting rules but penetrated greylisting
> (I edited @ to # in my email address):
>
> Received: from c12.dnepro.net ([212.3.120.12] helo=home)
>     by lena.kiev.ua with esmtp (Exim 4.69 (FreeBSD))
>     (envelope-from <anyabysdfxuh@???>)
>     id 1M2SKb-000641-JX
>     for lena#lena.kiev.ua; Fri, 08 May 2009 18:49:50 +0300
> Received: from [212.3.120.12] by mx1.yandex.ru; Fri, 8 May 2009 17:49:49 +0200


*snip*

Not yet seen here. Would pass forward-reverse host lookup, earn non-fatal
demerits on HELO <-> FQDN mismatch, ultimately be non-fatally quarantined, not
to 'Suspect:' IMAP folder on the basis of the '*.ru' <tld>

>
> Received: from [78.97.53.179] (helo=e-net)
>     by lena.kiev.ua with esmtp (Exim 4.69 (FreeBSD))
>     (envelope-from <olyajdtbnszp@???>)
>     id 1M4BE5-0002bW-35
>     for lena#lena.kiev.ua; Wed, 13 May 2009 12:58:14 +0300
> Received: from [78.97.53.179] by mx3.yandex.ru; Wed, 13 May 2009 11:58:12 +0200


*snip*

Not yet seen here. Would deny in acl_smtp_connect for missing PTR RR.

> Now that same botnet I think (correction: I suspect that it's Ukrainian,
> not Russian)


. or Moldovan...

> sends like this:
>
> Received: from [59.98.93.25] (helo=microsoft)
>     by lena.kiev.ua with esmtp (Exim 4.69 (FreeBSD))
>     (envelope-from <yanadsbglovel@???>)
>     id 1M8YWk-000M1Q-Tn
>     for lena#lena.kiev.ua; Mon, 25 May 2009 14:39:36 +0300


*snip*

Not yet seen here. As above w/r demerits and '*.ru' <tld>

>
> Received: from customer-199.131.livas.lv ([84.245.199.131])
>     by lena.kiev.ua with esmtp (Exim 4.69 (FreeBSD))
>     (envelope-from <yanagoptlovem@???>)
>     id 1M9Kxo-000JrS-45; Wed, 27 May 2009 18:22:44 +0300


*snip*

Not yet seen here. Would pass PTR RR, fatally fail forward-reverse lookup.

NB: Our 'gong' on the *.ru <tld> is one of several such entire country-code
tests, (mayanmar, etc) and a far larger number (~600) of
'*.[<network>.]<domain>.<tld> tests.

None are cross-the-board 'fatal' by themselves, so this is nowhere near as
heavy-handed as, for example, Lena's blocking of entire Asian IP ranges.

;-)


> The set of conditions I'm testing:
>
>   deny  message = rejected because recognized as Ukrainian spam
>         condition = ${if match{$message_headers_raw}\
>                               {\N\A([^\n]+\n[ \t])+[^\n]+\nDate\N}}
>         condition = ${if eq{$received_protocol}{esmtp}}
>         condition = ${if eq{$bheader_X-Priority:}{3 (Normal)}}
>         condition = ${if match{$sender_address_local_part}{\N^[a-z]{10,}$\N}}
>         condition = ${if match{$bheader_To:}{\N^[^ @,;]+@[\w\.-]+$\N}}
>         set acl_m_domain = ${if match{$bheader_To:}{\N@(.+)$\N}{$1}}
>         condition = ${if match{$bheader_Message-ID:}\
>                               {\N^<\d{10}\.\d{14}@$sender_address_domain>$\N}}
>         condition = ${if match{$bheader_In-Reply-To:}\
>                               {\N^<[A-F\d]{44}@$acl_m_domain>$\N}}
>         condition = ${if match{$bheader_References:}\
>    {\N^<[A-F\d]{44}@$acl_m_domain> <[A-F\d]{40,44}@$sender_address_domain>$\N}}
>         condition = ${if !eq{${if match{$rheader_In-Reply-To:}{<(.+)@}{$1}}}\
>                          {${if match{$bheader_References:}{\N^<(\w+)@\N}{$1}}}}
>         condition = ${if match{$rheader_Content-Type:}\
>                               {text/(plain|html); charset=koi8-[ru]}}
>         condition = ${if eq{$bheader_Content-Transfer-Encoding:}{8bit}}

>
>


We do add 'demerits' for RFC, format, and MIME violations, but otherwise, much
of the above is more work that we care to perform outside of the reduced
test-set SpamAssassin [1].

Just as you could (probably) safely block all Chinese encoding in your
environment, we could (probably) block all Cyrillic.

... thankfully, we do not, as I am just now weighing a vacation to one of
several countries where hotel reservations and such include at least *some*
Cyrillic encodings.

Too much pain, too little gain in an increasingly internationalized world.

Side issue - but I've just had to turn-off DLP in ClamAV as it was triggering
as 'Structured.SSN' on European phone and fax numbers in hotel reservation
confirmations.

Off-topic, Lena, but can you advise what the driving environment and parked-car
crime risks are in your part of the planet? Ukrainia, Bulgaria? Romania?

Regards,

Bill

[1] One box is now running without SA at all, and we have high hopes that we
will be able to drop it everywhere, as it has become a bit of a monster to strip
down, and is of dimishing utility once Exim has swatted most of the insects that
are reliably 'detectable' at all.