Subject: RE: SPF abused by spammers

From: "Sauer, Damon" <[email-masked]>
Date: Mon, 13 Sep 2004 09:15:48 -0500

> > 
> > "Douglas Otis" <[email-masked]> wrote:
> > > A DNS check that obtains a list of addresses for a 
> mailbox-domain, 
> > > MUST assume channel integrity when holding the apparent 
> originator 
> > > of the message accountable.
> > 
> >   What channel?  The only parties involved are:
> > 
> >   a) SMTP client
> >   b) SMTP server
> >   c) DNS server being queried
> 
> I think he is refering to the channel referenced by 
> information theory (guessing by the previous reference to 
> Lampson's covert channel paper). This could refer to the 
> complete path through the communication system, or it could 
> refer to a single hop in a multihop system.
> 
> Further, you've oversimplified the parties involved:
> 
> 	The end user, 
> 	optionally a third party relay [one or more]
> 		(because connection and mail services may be unbundled)
> 	The mailbox provider (where responses will go)
> 	The Mailbox provider nameservers
> 	The recipient mail server [one or more]
> 	The recipient nameservers
> 	The chain of nameservers between the recipient, root, 
> and mailbox 
> provider.
> 
> At any point spoofing could occur.

 This is true HOWEVER the only points at which this can be checked are
between the two current MTA's and DNS. How can my MTA possibly see what
the other MTA's are doing? buzzzzz

> 
> Going back to my spam examination where you are examining a 
> spam message: Suppose the IP address in the received from 
> header no longer matches the SPF records:  In this case you 
> don't know if your SPF check passed because DNS records were 
> spoofed, or if the real DNS records were changed.  All 
> you know is that you got a spam from a certain IP address.  
> You don't know 
> whether it was forged or not.

 This is why the delay time is there. (28 days?) If it is no longer
there, then it *MUST* fail.

> 
> Suppose the IP address in the received header does match the 
> SPF records. 
> You don't know if the abuser signed up for an account with 
> that domain, or 
> if they got an infected machine under that domain.  You don't 
> know whether 
> the nameserver was cracked, and incorrect records added. Most 
> people can't 
> tell the difference between a poisoned DNS cache and whether 
> the records 
> really come from an authoritative nameserver or even figure 
> out where they 
> got the DNS record from.   So, similarly, all you really know 
> is that you 
> got a spam from a certain IP address.
 
Again, in this case it *MUST* fail

> 
> In both cases, all that can be done is report the incident to 
> the operator 
> of the domain and the operator of the IP address.  And that's 
> all that can 
> be done now. THERE IS NO CHANGE.
> 
> SPF doesn't prevent email forgery, nor even indicate whether 
> forgery happened.

 It is only being used to authenticate the IP of the the sending MTA.

> 
> >   The DNS server may return one, or a billion IP's 
> "permitted" to send 
> > MAIL FROM with it's name.  Any particular message may have 
> traversed 
> > zero, or a billion intermediate SMTP hops before arriving at the 
> > current SMTP client, and being sent to the SMTP server.
> > 
> >   I fail to see how any party other than the three listed 
> above could 
> > possibly be involved in "MAIL FROM" DNS checks.  There is 
> no "channel" 
> > beyond the current hop, which can be verified to exist.
> 
> The current hop cannot be "verified to exist" beyond the TCP sequence 
> numbers. There is no way to tell that the mail isn't forged.  Even if 
> email comes from a certain server, there is still no way to 
> tell that the 
> mail isn't forged.  <user>@aol.com coming from an AOL 
> mailserver doesn't 
> mean that it really came from <user> Spammers can get 
> accounts at AOL. 
> Spammers can steal accounts at AOL by a number of vectors 
> such as viruses.

This would be AOL's problem. And considering AOL's propensity to sue
spammers on it's network, I would love to see them try.

> 
> And what's more, from outside of AOL we can't be sure that 
> AOL isn't pink-contracting with spammers.
> 
> The notion of "spam-herding" is just so much wishful thinking.
> 

"Spam-Herding" is my term and I believe that it will do exactly that. If
you are concerned about 'pink' contracts, then the spammers will be
herded to those. It will eventually become a matter of economics as
pressure is brought to bear on the otherwise legitimate IPS that may be
providing 'pink' contracts. Spam is not socially acceptable. It is
likely hated as much as paying taxes if not more. Social engineering
WILL take place with SPF fully deployed. The spam will be herded.

Regards,
Damon Sauer
"Putting my bee suit on"

*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you received this in error, please contact the sender and delete the material from all computers. 113

---

From: Dean Anderson <[email-masked]>
Date: Mon, 13 Sep 2004 11:26:25 -0400 (EDT)

> the other MTA's are doing? buzzzzz

Exactly. You can't ever know that a message isn't forged.  People wrongly 
think that SPF prevents forgery.

> there, then it *MUST* fail.

Delay time? 
*MUST* fail???

What are you talking about?

> > Suppose the IP address in the received header does match the SPF
> > records.  You don't know if the abuser signed up for an account with
> > that domain, or if they got an infected machine under that domain.  
> > You don't know whether the nameserver was cracked, and incorrect
> > records added. Most people can't tell the difference between a
> > poisoned DNS cache and whether the records really come from an
> > authoritative nameserver or even figure out where they got the DNS
> > record from.  So, similarly, all you really know is that you got a
> > spam from a certain IP address.
>  

Why would it fail if it the SPF "check" succeeds?

Or is this just another case of blind faith? Yes, it *must* fail if SPF is 
to work. Except that it doesn't fail, and as a result SPF doesn't work.

> > In both cases, all that can be done is report the incident to the
> > operator of the domain and the operator of the IP address.  And that's
> > all that can be done now. THERE IS NO CHANGE.
> > 

Which proves nothing about the message.

> > >   The DNS server may return one, or a billion IP's "permitted" to
> > > send MAIL FROM with it's name.  Any particular message may have
> > > traversed zero, or a billion intermediate SMTP hops before arriving
> > > at the current SMTP client, and being sent to the SMTP server.
> > > 
> > >   I fail to see how any party other than the three listed above
> > > could possibly be involved in "MAIL FROM" DNS checks.  There is no
> > > "channel"  beyond the current hop, which can be verified to exist.
> > 
> > email comes from a certain server, there is still no way to tell that
> > the mail isn't forged.  <user>@aol.com coming from an AOL mailserver
> > doesn't mean that it really came from <user> Spammers can get accounts
> > at AOL.  Spammers can steal accounts at AOL by a number of vectors
> > such as viruses.
> 

They already do this. Every day.  You seem to be saying that AOL sends no
spam, and has no spammers, no viruses, no stolen accounts???

> > And what's more, from outside of AOL we can't be sure that AOL isn't
> > pink-contracting with spammers.
> > 

I note that you wrote this notion as an admin for Bell South.  Has Bell
South been able to clean spammers out of Bell South? Or clean virus
infections out of Bell South?  Or make it impossible for Bell South users
to get viruses, worms, etc? Or do they just whack them as the find them?  
Or is this just another "blind faith" that you //think// will happen?

If you've found some special immunity from spammers/viruses/worms, then I 
think you should share that. //That// would be far more valuable than SPF. 
If we could prevent spammers/viruses/worms then we wouldn't need anti-spam 
tools at all.

		--Dean