ietf-mxcomp
[Top] [All Lists]

Re: SPF abused by spammers

2004-09-16 15:52:12

On Thu, 2004-09-16 at 13:32, Alan DeKok wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
I see a conflict even within the specification.  Jim Lyon has already
indicated any domain publishing an "open" record, requesting forwarded
mail receive a "Pass" assessment, will receive the bad reputation they
deserve.  The specification does not warn of this problem.

  The goal of specifications should not be to anticipate all possible
uses or abuses, of the specification.  To ask this of a specification
is to guarantee that it will fail to achieve consensus.

This still leaves anticipating the use of "open" lists provided by the
draft and its effect of "inviting" spoofing.  This aspect should be
within the scope of a draft that purports to solve a spoofing problem.

By first performing CSV to authenticate and authorize the MTA, and then
obtaining an authorization list of names referenced by the mailbox
domain, this will specifically prevent spoofing.

  I do not believe that there is enough consensus as to what "EHLO"
checking means, or "MAIL FROM" checking means.  Without that
consensus, we have no quantitative way of comparing proposals, or for
deciding if a proposal meets our requirements.

There must be an exchange of ideas and concepts to arrive at a
consensus.  Announcing Caller-ID as the WG draft did not invite much
reflection other than largely the eventual removal of XML.  It would
seem a foregone conclusion more than consensus.  Publishing a draft
helps, but answering questions should provide clarity or offer a
perspective of the trade-offs considered.

As example, there were several serious issues never addressed.  The most
I heard with respect to network congestion avoidance, actually the lack
of avoidance, was "That would be bad."  The latest draft still retains a
required 10 script processing within 20 seconds minimum each.  The time
limit was added after it was pointed out valid record sets may take more
than a hour to resolve even with no packet loss.  The addition of the
time limit then fails to address a potential loss of network integrity
that may dramatically affect long haul links, or a potential for
flooding the network with UDP traffic.  A 3-5% packet-loss of UDP
packets is common but clearly not accommodated.  Ignoring this does not
make the problem go away.  Network considerations should be within scope
for a network protocol.  Plays well with others should be a requirement.

There should be some consideration given this, as you have indicated
your own expectation the results of this scheme will be used for
establishing reputations.

  That is a matter for a follow-up WG, or a re-charter of this WG,
once this WG finishes its current work.  Until then, I see no point in
discussing the benefits or impacts of reputation systems.

At the same time this group was declaring Last Call, there were
reputation services based upon the identities provided.  Statements of
being able to trust Sender-ID or SPF identities will not make these
identities trustworthy however.  There should be consideration given the
expectations created by hyperbola.   

I am not suggesting curtailing spoofing not be done.  I am simply
advocating a better, safer, cleaner approach.  And yes, it also makes
reputations safer as well.

  I'm not sure how any "MAIL FROM" checking can prevent spoofing on a
shared MTA.

The stronger the validation of a name associated with a message, the
less likely this validation will be spoofed.  As shown with Microsoft's
PRA algorithm, the name validated does not need to be the RFC2822 From
address.  Spoofing a Sender-ID or SPF check may only require asserting a
mailbox domain depending upon the nature of the list or the entry point
of the message.  CSV is not as easily spoofed, nor does it assault DNS
with a phalanx of variable records types to be resolved which may open
up other security risks as with SPF and Sender-ID.

Making this validated MTA name visible along with the RFC2822 From will
alert users to unexpected sources of the From mailbox domain based upon
the user becoming familiar with these identities during their normal
correspondents.  Unlike SPF or Sender-ID, the marid-mpr draft offers a
means for the domain administrator to specify these normal sources for
either the RFC2821 MAIL FROM or RFC2822 From mailbox domains that can
not be superseded as with Sender-ID.

The validation of the MTA name does not "invite" the spoofing of the
mailbox domain.  Use of a MAIL FROM constraint or the use of BATV will
also dissuade spoofing of this mailbox domain.  Institutions that find
themselves being phished or spoofed, should not employ outbound MTAs
outside their administrative realm and use a consistent identity for
their MTA names.  Unlike Sender-ID however, MPR can thwart spoofing of
the RFC2822 From as well as the RFC2821 MAIL FROM.  Such institutions
would need to alert their customers of this limitation, if their mail is
forwarded.  As MPR safely allows "open" lists, there can be a graceful
transition in making this restriction without "inviting" trouble.

-Doug