Subject: RE: Forged Sender (Resent-From) attacks

From: "Harry Katz" <[email-masked]>
Date: Thu, 19 Aug 2004 11:29:44 -0700

On Thursday, August 19, 2004 1:44 AM, Chris Haynes
[mailto:[email-masked]] wrote:

> <snip>
> >
> > - More importantly, this allow us to give much clearer 
> directions to 
> > senders in terms of what to publish. You publish the IP 
> addresses of 
> > servers authorized to send mail on behalf of your domain. We're not 
> > trying to mix this up with the IP addresses of servers that receive 
> > bounce messages on behalf of your domain.
> >
> <snip>

> 
> Is it possible that, all along,  there has been a fundamental 
> misunderstanding of SPF amongst the designers of Sender-ID?
> 

No there is no fundamental misunderstanding.  There may be a wording
problem, though.  :-)

The point I'm trying to make, and which has been made many times before,
is that there is a semantic difference between the 2821 MAIL FROM
address and the 2822 headers.  So maybe I should have said "the IP
addresses of servers authorized to transmit mail on behalf of the domain
that receives your bounce messages."

---

From: "John Glube" <[email-masked]>
Date: Fri, 20 Aug 2004 10:20:05 -0400

From: Harry Katz
Sent: August 19, 2004 2:30 PM
 
>The point I'm trying to make, and which has been made many
>times before, is that there is a semantic difference
>between the 2821 MAIL FROM address and the 2822 headers. 
>So maybe I should have said "the IP addresses of servers
>authorized to transmit mail on behalf of the domain that
>receives your bounce messages."

While recognizing this semantic difference, can we put
together a BCP as you propose, which suggests receivers do
at least these two things:

* Do a check of the 2821 MAIL FROM address to see whether
it is malformed and if it is to reject the data transfer.

(I believe you have already proposed this part.)

* In the absence of PRA at the data transfer stage, do a
2821 MAIL FROM address check using SPF records and if the
2821 MAIL FROM address is spoofed, reject the message at
the data transfer stage.

(This would pick up the concerns others have expressed.)

In the first case, since there is an invalid or malformed
2821 MAIL FROM address and in the second case, since there
is a spoofed 2821 MAIL FROM address, the only question is
what form of rejection notice should be sent and to whom
should it be sent?

I would suggest in the first case, since it can be said the
message is a nullity, no rejection notice is required.

Chris has suggested in the second case, since this message
is also a nullity, no rejection notice is required.

Although I tend to agree, my concern is that a spoofed 2821
MAIL From address could be the result of mis-configured SPF
record and not deliberate spoofing by a spammer. 

(We have already seen examples of this in the field.)

As a result would not a simple 55x message with the content
as suggested by the SPF draft protocols suffice to alert
someone of the potential problem?

I am putting forward these comments as suggestions for
discussion purposes, so that the proposal of a BCP can be
moved forward allowing folks to square the circle. :-)

John

P.S. There has been a suggestion put by both Scott and
Wayne in the Point of Order discussion concerning how to
deal with the two version string question. I simply note
these suggestions for your consideration. Cheers, John 

John Glube
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004