ietf-mxcomp
[Top] [All Lists]

Re: Is the back door open?

2004-07-29 10:47:16

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:andy(_at_)hxr(_dot_)us]
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


<Prev in Thread] Current Thread [Next in Thread>