ietf-asrg
[Top] [All Lists]

[Asrg] Re: IBM invents return to sender

2005-03-23 18:46:11
At 3:51 PM -0800 3/23/05, Douglas Campbell wrote:

However, a kernel of that idea might well be one way of detering spamming;
allow only those machines listed in MX records for the domain to be e-mail
emitters for that domain.

That's probably the idea that was a seed for just about every one of the many MARID variants, and its flaws are so significant that the *fixed* models are things like SPF, SenderID, and FairUCE.

That means that, for a spammer to use a machine
to emit e-mail for a domain, they must own the domain and a dns server
prepared to name the machine via an MX record.

In other words: they have to do what Atriks has been doing for well over a year now through zombie machines.


 This introduces a level of
accountability now missing -- one can always interrogate the ICANN domain
records to determine the current owner of a domain.

In theory, yes. In practice, no. Spammers have been using bogus registrations and willing accomplice registrars (as well as the just plain careless or readily duped ones) for years. ICANN has never really exercised their theoretical power to act against such things in a serious way. Counting on domain registration data to be accurate is a faulty plan.

 Thence, rbl's can be
built to incorporate both domains and IP addresses.  Unless the spammer
has one domain name per machine, you can kill many of his distributed
servers with one block entry if we force the spammers to use domain names.

There is a nugget there.

My anti-Atriks method is to have a caching resolver BIND instance used just for the MTA into which I configure any nameserver servicing Atriks-like spammers. This is not perfect (it has scaling/maintenance issues) but I get a lot of spam rejection out of this piece of /etc/named.conf:


 // This is for networks where the nameservers deal in garbage
        blackhole {
            // Various bits of Korea and China
            211/8;
            218/7;
            220/6;
            61/8;
            // Atriks
            64.255.175/24;
            65.204.19/24;
            207.180.24.0/24;
            216.177.6.0/24;
            65.204.12.224/24;
            65.223.192.128/24;
            140.186.159.0/24;
            208.251.154.64/26;
            // fabulous.com
            64.15.205/24;
            //Reinertsen
            216.237.188.0/24;
            66.239.110.0/24;
            //Avtech/eNom/InterNap
            67.173.36.242;
            63.251.163.102;
            216.52.184.230;
            63.251.83.36;
            64.74.96.242;
            212.118.243.118;
            // Ralsky? nameless L3 machines
            4.79/16;
            // ai.net/w0rdx.com porn spammers
            205.134.160/19;
            // chinese garbage spammers using 'bcwdns.com'
            65.203.151.0/24;
        };



Throw away domains:  assume that a spammer creates a domain and uses it
for exactly one "job".

They do some of that, but largely they are creating third-level domains. I have not yet seen a spammer responding to the 'shun the nameservers' tactic.

  If the RBL list resulting from such a spamflood is
based on domain name, all resources for that job can be tempoararily
blocked based on a domain name entry rather than a large list of IP
entries.  Since domain names have expiration dates, aging of such lists
could occur in a natural way.

Tangent: note that 'RBL' is a trademark of Kelkea. Lists using the mechanism pioneered by the MAPS RBL is generically referred to as DNS-based lists or DNSBL's.

At present, the DNSBL support in MTA's for domain names as the key (sometimes referred to as 'right hand side' blocking lists) is very spotty. Just about any serious MTA supports DNSBL's for connecting IP and many will support multiple such lists and specific return value detection, but I think the RHSBL support is pretty much limited to a small handful of MTA's, notable not including Sendmail or Exchange. (although the later needs MORE reasons for exile from the public net for the public good...)

I haven't thought this through completely, but it seems that enforcing an
MX rule would require spammers to retool their infrastructure in a far
more substantial way than what would be required of legitimate ISPs.

I think you might do well to go digging in the Google Usenet archives for the history of this idea, as well as well as those of this list and the MARID list for some insight as to the extent of retooling by ISP's and other domain owner (keep in mind that most mail systems are not run by entities anyone would call an ISP) needed just to identify the predictable legitimate sources of mail from their domains. The mess that is SPF shows what is needed to describe such sets of addresses, and the hard failure mode of SPF in dealing with traditional forwarding shows the place that any such attempt will break. There is a lot of room for arguments in principle that traditional forwarding is a flawed model, but those arguments lose when it comes down to trying to deploy anything that conflicts.


--
Bill Cole
bill(_at_)scconsult(_dot_)com


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg


<Prev in Thread] Current Thread [Next in Thread>