Subject: [Asrg] Re: IBM invents return to sender

From: "Douglas Campbell" <[email-masked]>
Date: Wed, 23 Mar 2005 15:51:33 -0800 (PST)

Barry Shein said

> Ok, to be fair, I'm now studying their docs:

>      http://www.alphaworks.ibm.com/tech/fairuce

I agree that C/R methods can be used for DOS and spammers can use them to
determine valid e-mail addresses.

That said, the fact that this is coming from IBM's alphaworks shop says that
a) You have access to the source code, and
b) the ability to comment to IBM about what you've seen, and
c) the documentation enabling you to understand what the source code does.

A bit of IBM alphaworks stuff has made it into the mainstream (see Eclipse
for an example).  When I was an OS/2 fanatic, I spent a lot of time at the
alphaworks site looking at what IBM was doing with OS/2; I could draw
hints from this with regard to how to code my own applications.

For example in the current case, if you strip out the C/R component, could
the remainder be turned to some use?

Reversion of topic:  The author of FairUCE is making some simplistic
assumptions about the nature of e-mail; for example, they send back a
challenge to the machine connecting to the recipient's e-mail server. 
That assumes that any MTA emitting outbound mail is prepared to accept
inbound mail.  We all know that this is rarely the case, so the product
may well work with the current crop of viral spamservers.

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 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.  This introduces a level of
accountability now missing -- one can always interrogate the ICANN domain
records to determine the current owner of a domain. 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.

Throw away domains:  assume that a spammer creates a domain and uses it
for exactly one "job".  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.

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.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Bill Cole <[email-masked]>
Date: Wed, 23 Mar 2005 20:44:06 -0500

At 3:51 PM -0800 3/23/05, Douglas Campbell wrote:

>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
>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
>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

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;
         };

>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

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...)

>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
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 24 Mar 2005 07:53:46 +0100

Bill Cole wrote:

> The mess that is SPF shows what is needed to describe such
> sets of addresses

It's rather odd why FairUCE considers to _not_ challenge an
SPF PASS from unknown strangers.  It's one of the few cases
where a challenge shouldn't hit innocent bystanders, and a
PASS only means "sender plays by the rules", not "no spam".

> 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.

The users of SPF FAIL obviously disagree with this opinion,
they are happy to get rid of "traditional forwarding" when
it also gets rid of numerous bounces / challenges / etc.

For a PR of the SPF Council published yesterday see also:
<http://spf.mehnle.net/Press_Release/2005-03-23>

                       Bye, Frank

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 25 Mar 2005 04:34:09 +0100

> challenge to the machine connecting to the recipient's e-mail server. 

This is the thing I like most about it.
a) C/R systems currently work, as there is no standard (which is also
   the crux, so they cannot be processed automatically)
b) as soon as there is some kind of standard, C/R systems will become
   useless, as spammers will approve the R.
c) sending the C/R to the machine that emitted the suspicious messages
   makes it even simpler for the spammer to ACK the C/R, even if the
   sender address is faked.

There was a article on ZDNET that was quoted in a german business club
antispam forum. In that article they had an interview where the IBM person
said that they plan to kinda counter attack the sending machine to limit
its bandwidth and reduce the harm it causes.

"A few weeks of developing and testing can save a whole afternoon
in the library."

    http://security.clevertech.net/adobe/sans_001213.pdf

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"