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