[email protected] 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 <[email protected]>) > 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 <[email protected]>) > 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 <[email protected]>) > 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 <[email protected]>) > 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{...@$sender_address_domain>$\N}} > condition = ${if match{$bheader_In-Reply-To:}\ > {\N^<[a-f\d]{...@$acl_m_domain>$\N}} > condition = ${if match{$bheader_References:}\ > {\N^<[a-f\d]{...@$acl_m_domain> > <[A-F\d]{40,4...@$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. -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
