Re: [exim] [off-topic] Using low-priority DNS MX record as s…

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: Re: [exim] [off-topic] Using low-priority DNS MX record as spam trap
gdub wrote:

>
> W B Hacker wrote:
>
>> gdub wrote:
>>
>>> Any thoughts on the idea of dedicating a
>>> host or interface as a trap by giving it
>>> the lowest priority MX record?
>>>
>>
>> IMNSHO 'traps' in general seem to be more likely to just eat b/w, CPU
>> cycles, and time.
>>
>
> You're right, of course. I am just currently
> frustrated with a growing volume of really
> high quality spam (heh). This stuff flies
> right under the radar and is targeted only
> at legitimate addresses. I'm grasping for
> any handle.
>
> The good news is that I know exactly
> where I can get a great mortgage and what
> companies have caps that are about to skyrocket.
> But my users don't share my disposition.
>
> -dub
>
>
>

ROFL!

I needed that.....

;-)

BTW - try 'capturing' the IP's *and* the (usually bogus) HELO strings they use
into a file [1] or DB [2]

Despite their IP-mobility (Zombie farms), we see a surprising sameness in the
forged HELO's and/or that they are consistently a) lacking a PTR b) on
dynamic-IP (tens of thousands of hits in the SQL DB, but far, far fewer unique)

Any of those alone can give FP's, so too, even AND b, BUT, with care, one can
soemtimes even ipfw the odd ---/8 'Bout half of Korea or Taiwan's dynamic
boradband IPS's f'rinstance, and a great many US ones whose adsl bloks are
voluntarily listed as not suited for MX by Tos.

CAVEAT: You need to manually inspect and perhaps whois before listing, but:

(a AND b AND <familiar forged HELO>)

- makes a pretty fair filter. Need 500 to 2000 of 'em if intelligently
wildcarded to drop about 80%+ on their head 'Real Soon now'. Before waking SA
anyway.

Your list will be different from mine, of course.

But a SELECT distinct ordered by timestamp shows a reasonable resemblance to a
gaussian curve within about 4 to 6 days as you start using the list you build to
'block on-sight'

HTH,

Bill

[1] A .csv file that can be loaded into a spreadsheet or DB:

logwrite = \
:panic:$tod_log,MBL,$sender_host_address,$sender_host_name,$dnslist_domain

Where: the paniclog is presumed to usually be empty, ELSE can have the odd entry
cleaned out.

MBL = Major RBL, NVR = No Valid Recipient, DYN = Dynamic IP, PTR = rDNS fail
etc... or whatever the acl was testing...



[2] PostgreSQL - should work same for other SQL's:

set acl_m19 = ${lookup pgsql{INSERT into brownlist (pg_when, pg_why, pg_ip, \
                pg_host, pg_where) \
                VALUES '$tod_log','NVR','$sender_host_address', \
                '$sender_host_name','$dnslist_domain')}}