spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kris Deugau <kdeu...@vianet.ca>
Subject Re: Spam filtering similar to SPF, less breakage
Date Tue, 09 Feb 2010 23:26:56 GMT
Darxus@ChaosReigns.com wrote:
> On 02/09, Kris Deugau wrote:
>> I'm still not seeing the whole picture;  maybe you can explain the  
>> difference between these two cases:
>>
>> 1) Legitimate sender, uses the NAT machine as the legitimate, designated  
> 
>> (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com).
>> 2) Spam, from an infected machine on the same LAN, either via relay  
> 
>> (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com).
> 
> The IP is sending spam, so it gets blacklisted (by a blacklist of domains
> which have MTX records for spamming IPs).

... So what incentive do I as:  (pick any one or more hats below)

ISP mail/DNS admin
Colo/self-hosted domain admin
Inbound mail admin

have to either set up this extra A record, or check for it, that 
existing blacklists don't provide?  Chicken<->egg.

Where do you draw the lines for adding someone to a/the blacklist? 
0.0001% spam?  0.01%?  1%?

How would you publish the blacklist?  Globally?  Rely on individual 
local DNS operators running their own blacklist?  (Good luck getting 
*off* ten million local blacklists...)

> Two options where smallbusiness.com doesn't have the ability to define its
> own PTR records.  For example, the PTR record is defined by isp.com.
> 
> 1) isp.com sets the PTR record to exchange.smallbusiness.isp.com, and
>    creates the MTX record for it (2.0.0.10.mtx.smallbusiness.isp.com
>    with a value of 127.0.0.1).  If 10.0.0.2 sends spam, isp.com gets
>    blacklisted.

Immediately?  Would you *really* blacklist eg AOL, Hotmail, or Gmail if 
you received *one* spam from any of their networks?

If you have paying customers using your mail systems, you'd be out of 
business in a matter of months.

> 2) isp.com sets the PTR record to exchange.smallbusiness.com, and
>    smallbusiness.com creates their own MTX record
>    (2.0.0.10.mtx.smallbusiness.com = 127.0.0.1).  If 10.0.0.2 sends spam,
>    smallbusiness.com gets blacklisted.
> 
>>  and some arbitrary (sub^n)domain A record based on the PTR.
> 
> Yes.  That's all.  What format should this arbitrary A record be?

Aside from considerations above, what you've posted is fine, 
structurally.  From a pure "how to publish data" perspective, a new DNS 
RR type would be slightly better, but reversed IPs concatenated to a 
subdomain is a well-established way to publish this type of data.

>> About all your scheme seems to do is identify IPs which may emit  
>> legitimate email, generally;  it's certainly nothing I'd score at  
>> anything more than an advisory -0.001 in SA.
> 
> Of course, unless you use a blacklist of domains which have MTX records for
> spamming domains.

Well, aside from getting tougher on customers with infected systems, how 
do you propose to actually stop the spam from being generated?  If you 
can't stop that, you-as-ISP *CAN NOT* fully prevent spam from being 
relayed through your servers unless you unplug the network and power 
cables...

>> Consider the case of a legitimate ISP's outbound relay - most of the  
>> mail is perfectly legitimate, but sooner or later *someone* on an IP  
>> controlled by that ISP (and therefore allowed to relay through that  
>> outbound relay host) will have their machine infected or someone with an  
>> account with that ISP will have their password stolen, and then that  
>> infected machine will spew out junk via the relay, or a machine  
>> somewhere else will use that stolen password to send SMTP AUTH mail  
>> through that relay....
>>
>> We regularly see both of those cases here (medium-sided ISP).
> 
> It's an issue of blacklisting.  What is involved in keeping your ISP off of
> IP blacklists?

Blocking outbound connections to port 25 from residential IP blocks, 
responding to reports (cutting of residential customers found to be 
infected, warning and eventually cutting off static-IP business 
customers;  notifying users whose passwords seem to have been cracked or 
stolen - among other standard measures).  It helps, and we've signed up 
for the feedback loop widgets with a number of places (AOL, Comcast), 
but there is NO WAY we can absolutely stop all spam from emitting from 
IP space under our control, short of turning off our core routers.

This is not exactly unusual.

>> The more I think about it and the more I read of what you're describing,  
>> the more most of it seems like a reasonable component of any blacklist  
>> operation, not a whole FUSSP[1] in its own right.
>>
>> [1] http://www.claws-and-paws.com/fussp.html, among other references
> 
> I have been directed to that url frequently in the last few days :)

<g>  The form may be a bit tongue-in-cheek, but taking it at face value 
is helpful in seeing if you're really trying something new, or if you're 
just putting a new coat of paint on something that's already in practice 
as a small subset of a larger operation.  (Or trying to resurrect a dead 
horse that was already beaten to a thin paste ten years ago.  I don't 
think you've gotten *that* far yet.)

TBH, what you seem to be trying to do seems far better suited to a local 
system of some kind that sees where mail is coming from, and whether 
it's spam or not, and applies some degree of filter white bias to sites 
generating less spam over time.  (.... AWL anyone?)  I'd exclude 
Hotmail, Gmail, and Yahoo from it though;  it's far too easy to pick up 
an account, spew out a bunch of garbage and then drop the account.

It's looking like effort (admittedly, not much) for no real return, 
given that *any* scheme like this needs a significant fraction of the 
Internet to be using it to see it behaving properly.

-kgd

Mime
View raw message