ietf-mxcomp
[Top] [All Lists]

Re: Is the back door open?

2004-07-29 08:53:04


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>