Subject: Re: Is the back door open?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 29 Jul 2004 10:47:14 -0700

I am at black hat.

The guy on stage is demonstrating voice over dns. It caches everywhere...

I think that the problems of people using reasonable uses of the dns that
might possibly be subverted are far less worrying than the likely total
abuses.

 -----Original Message-----
From: 	Andrew Newton [mailto:[email-masked]]
Sent:	Thu Jul 29 09:32:35 2004
To:	MARID WG
Subject:	Re: Is the back door open?

On Jul 28, 2004, at 8:11 PM, Dave Crocker wrote:
> There is no such thing as an RFC2821.TO identity.

Then we needn't worry about using a valid list of users when doing 
Sender-ID or SPF checks then.  :)

On Jul 28, 2004, at 6:06 PM, Douglas Otis wrote:

> SPF offered some relief, if the MTA creating the bounce checked the
> destination domain records for valid sources of the message.  This is
> lost with Sender-ID.  A solution for this problem could be found 
> through
> a combination of SPF and BATV, where BATV is less disruptive.  SPF
> accommodates an address based white-list, but such a list would be of
> less use, with CSV offering names.

I was under the assumption that BATV was a much better fit with domain 
keys than with SPF.  Actually, I have no idea what it has to do with 
SPF at all.  BATV is an interesting idea.

On Jul 29, 2004, at 3:19 AM, Douglas Otis wrote:

> Sender-ID checks the Purported Responsible Address (PRA) and may not
> include the RFC 2822 From.  Sender-ID does not check the RFC 2821 RCPT
> TO or the RFC 2822 To.  Such checks are done independently.

I'm glad there's agreement on this.  :)

> The scenario described was to illustrate a generation of a bounce
> (resending of the message to the RFC 2821 MAIL FROM) rather than an
> immediate message rejection with a 5xx error.  The bounce occurs, in
> this case, when the mail is being relayed by an MTA that does not have 
> a
> list of valid users, but is only checking the right hand side of the 
> RFC
> 2821 RCPT TO address.  If the message is initially accepted and then 
> the
> user is later discovered not valid, the message becomes bounced.

I understand the scenario.  And I keep asking, "why not just do a 
Sender-ID (or SPF) check and REJECTION at the first MTA"?  And you keep 
saying, "It doesn't have the list of valid users."  And I keep asking, 
"what does a list of valid users have to do with a Sender-ID or SPF 
check?"

> Acceptance does not require a full rating from Sender-ID, and may not
> include a full set of other checks at that time.  Sender-ID acceptance
> could be achieved using a domain with either none, open, owned, or
> borrowed records.

huh?  what?

>   A relay MTA may also opt to turn off Sender-ID
> channel checks.

Well, that is between you and the people you list in the target of your 
MX.  A relay MTA may also opt to block 0/0, but that's no fault of 
Sender-ID or SPF.

Are you trying to say that Sender-ID checks will only be one part of a 
spam-filter evaluation that can only take place on the delivery MTA?  
If so, isn't this your responsibility to handle properly since step 6 
of the PRA says "SHOULD" reject (meaning, if you didn't, you really 
ought to know what you are doing).

-andy

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 30 Jul 2004 08:46:49 -0700 (PDT)

> On Jul 30, 2004, at 2:35 AM, Douglas Otis wrote:
>> The message is accepted by the Sender-ID check with some rating other
>> than Fail, but a more complete check of the local part of the address is
>> done subsequent to acceptance.  This name check fails, as intended, and
>> the message is bounced.  The same could happen with a virus.
>
> So you are explaining that a bounce occurs because something other than
> Sender-ID has happened, and therefore that is a problem with Sender-ID?

Yes.

>>> And this is NOT the ralph, fred, bob scenario you started with.  So
>>> now we are back to receiving a bounce out of the wild, blue yonder?
>>
>> I had never used these names?  Sender-ID never checks the RFC 2821 MAIL
>> FROM.
>
> Ryan came up with the names after you backed into the use case when I
> asked why it was there was a bounce in the first place.  You said there
> was a bounce because the mail was relayed to an MTA with the list of
> valid users.  Now you are back to the first use case saying that the
> bounce just happens for some mystical reason.  Ok fine.  But then that
> is not a flaw in Sender-ID, which is where this thread started.

This must have been a conversation off this list.  The bounce does not
happen for some mystical reason.  The flaw, if you wish to call it that,
is that Sender-ID does not prevent the bounce spam/virus traffic as did
SPF.  I strongly feel the motivation for publishing SPF was to find relief
from this bounce traffic.  That relief is not available with Sender-ID.

The situation that creates the bounce is not uncommon.  If mail is being
relayed, it is often the relay only checks the right hand side of the
recipient address.  At some hop later, the local part of the recipient
address is checked.  At this point, the message may get bounced.  Spammers
are proficient at finding these configurations and using them in the
manner descibed.  It is also common for a virus check to happen after the
message had been accepted, with a similar result.

> On Jul 30, 2004, at 12:13 AM, Douglas Otis wrote:
>
>> To fully understand the scope of the problem, work only on what can be
>> assured.  Limit the reach to the most immediate with simple measures
>> and stop trying to indirectly authenticate the user.  SMTP was never
>> intended to preform this function.  BATV and CSV can make a dramatic
>> change without breaking mail, and can be put into play quickly.  We can
>> make a real difference,  if to recognize what is within our grasp, and
>> what is not.
>
> When you started this thread, I thought you were suggesting you had
> found a flaw in the PRA algorithm.  That is why I engaged in
> discussion.  Instead, this thread seems to have backed into the
> relative comparisons of CSV vs. SPF vs. Sender-ID, ground this working
> group has been over many, many times.  It is nothing new to find out
> that one proposal deals with forwarding better, one proposal deals with
> bounces better, and one proposal deal with phishing better.

Sorry, I found Rand Wacker able to understand these concerns and continued
to express what seems to be philosophical differences separating what
appears to be rather common agreement on most issues.  This statement does
not dismiss the initial concern, as you appear to have concluded.  Sorry,
I'll restrain myself to smaller aspects of these details.

-Doug