ietf-mxcomp
[Top] [All Lists]

Re: SPF abused by spammers

2004-09-12 09:46:58

"Alan DeKok" <aland(_at_)ox(_dot_)org>
"Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org> wrote:

The MAIL FROM mailbox-domain was passed through the mail channel
for messages not originating at the SMTP client.

  WHAT "mail channel"?  I have described what I think of as the "mail
channel", and given reasons for my conclusions.  You haven't.

Mail is normally passed from MTA to MTA on its journey to the destination.
The MTA making the public delivery is often not where the message was
created.  The sequence of Mail Transfer Agents carrying the MAIL FROM
identifier is what I had referred to as the mail channel.

  I explained why the SMTP server cannot verifiably know that, and why
(for all practical purposes), the SMTP client is the only verifiable
originator of the message.  You haven't explained why you disagree, or
what errors (if any) exist in my message.

It is how the SMTP client is identified.  This identifier, to allow safe
reputation assertions, must reflect the identity of those administratively
in control of the sending machine, and able to take immediate corrective
action.  An SPF record does not give a reputation service license to hold
those that may have "authorized" the MTA to be accountable for the actions
of this potentially different entity.  Jim Lyon even stated an expectation
of holding the mailbox-domain accountable even when the MTA had not been
specifically "authorized" as a result of an "open" list.

  Simply stating a contrary position is not an argument.

You are saying one can not be sure of the origin of the MAIL FROM, but it
is okay to use this identity to assert a reputation assessment against the
actions of the SMTP client.  I agree one can not be sure of the origin of
the MAIL FROM and, as a result, the mailbox-domain MUST NOT be used to
assert a reputation assessment against the actions of the SMTP client. 
There is an identity that accurately identifies the SMTP client.  This is
either the IP address or an authenticated EHLO.

This is normally the case for the SMTP client performing public
delivery.  This adds at least an additional SMTP client/server pair.

  Which is effectively what I said in the paragraph below the one you
quoted, and where I explained why it didn't matter to the SMTP server.

I am not attempting to dodge your scenario.  I do not agree you have
adequately described the situation or considered risks involved making
negative assessments against a name.

  The risks involved are undertaken by the mailbox-domain, when it
publishes MTA authentication records in DNS.

What assurance can you provide that supports this opinion?  There is AOL
asking people to publish SPF records so they may be white-listed.  Now you
are saying publishers should also expect to be black-listed when they
publish an "open" record as have AOL.  Is this do as I say and not as I
do?

The scope of those risks are defined by the documents under discussion in
this group.  As for my consideration of those risks, I've explained my
reasons, and I don't think I've seen you refute any of them.  You've just
stated that you disagreed, and then talked about your position.  That's
nice, but it doesn't give me any insight as to why you disagree with my
position, or what's wrong with my position.

Rather than justifying not obtaining the SMTP client name out of
expediency, consider the outcomes when reputation is used to block the
names obtained.  Showing the name being blocked is the entity that
actually sent the abusive mail will greatly aid the defense of the
reputation service.  To suggest it does not matter that the name being
blocked only authorized the SMTP client and therefore accepted
accountability for these disparate entities will be a much more difficult
position to take.  I would expect this position will not provide much
protection in what will likely be a sizable litigation.

The concept of good and bad should be reserved for reputations of
the MTA name.

  Why?  I've explained why and how MAIL FROM accountability can be
safely applied.

You have not.  You simply say you can hold the MAIL FROM entity
accountable because they published with the clear warning within some
discussion within this WG.

A message (or message action) authorization is not sufficient to
hold the mailbox-domain accountable and asserting a reputation for the
mailbox domain.

  Why?  If any MAIL FROM authentication system is intended to hold a
domain accountable, then MAIL FROM authorization is perfectly valid
for holding that domain accountable.

It is not authenticating, it is authorizing the delivery of the message. 
The EHLO name can be authenticated, the MAIL FROM provides authorization
as does the CSV record in a generic sense.

You seem to suggest the MAIL FROM and EHLO identities are equally
strong. They are not.

  Why?  And I'm not suggesting they're equally "strong", but that both
may be used, each for different purposes.  Saying "they have different
kinds of accountability" is a clear statement that one may be more, or
less, accountable than the other.

The high risk act of asserting reputation demands authentication of those
entities directly accountable for the actions of the SMTP client, and not
based upon implied acceptance of accountability and assumed integrity of
the mail channel.

The MAIL FROM name may not correlate to the to entity accountable
for the actions of the MTA.

  And sometimes it may.  The two statements are not contradictory.
The MAIL FROM name may also correlate with the entity accepting
accountability for the *message*, which is what I've been saying all
along.

Yes you have.  But where does it say publishing an SPF record is accepting
accountability for any message using this mailbox domain coming from an
SMTP client?  That is the million dollar question.

And that statement does not contradict, or invalidate, the
idea that an entity (possibly different is responsible for the
actions of the MTA.

I am of the opinion these assumptions are caviler and needlessly risky.
This risk will represent the demise of the reputation service.

-Doug







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