spf-discuss
[Top] [All Lists]

Re: URGENT: Community Position on SenderID

2004-11-25 08:24:59
In 
<1101370485(_dot_)19980(_dot_)2917(_dot_)camel(_at_)localhost(_dot_)localdomain>
 Mark Shewmaker <mark(_at_)primefactor(_dot_)com> writes:

I almost, but don't quite agree with the position paper.

There are quite a few parts that I would liked to have had changed in
this paper also, but you can't get everyone to agree on every detail.

This paper started out when Meng received an ultimatum from Microsoft
to have SenderID content on the spf.pobox.com or links from the
http://www.truste.org/authentication webpage to SPF would be removed.
MicroSoft gave Meng only a few hours to comply, so the position paper
was very much of a rush job.  (Apparently, MS wasn't happy with the
result, as truste has active links all proposals, *except* SPF.
Pretty tacky, if you ask me.)

See:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200411/0135.html


Changing the paper now, however, has problems.  There have already
been around 90 people who have signed it, and if you are going to make
changes, you need to get those people to re-sign it.



1.  I do not understand the objection in the
    "Using SenderID _REQUIRES_ SPF" section.
    [...]
    However, I don't think that's what this section is getting at.

I think this section got mangled by having too many editors and is
probably the part of the paper I like least.


3.  |"PRA" (Purported Responsible Address) as it is implemented within
    |SenderID, has many technical problems that make it unsuitable for 
    |use in the real world. 
  [...]

    The first sentence--well, I actually disagree with it.  (!)

    I think the PRA concept could be saved, at least partially,
    (one thing I'd do is put "List-ID" between From: and Sender:.)

Unless you have more control over MicroSoft than Meng does, you can
not change the PRA.  You need to either accept it as is, or not.  Once
an SPF-classic spec makes it to RFC status, you won't be able to
change it either.  That's how the real world works.



    The fact that the PRA algorithm has problems because forwarders
    don't all insert Resent-From/Sender: headers doesn't eternally
    damn the idea--it just makes it currently unworkable at the MTA
    level for rejects.

What forwarders insert the resent-* headers?   I'm not sure there are
any.  (the "bounce" feature of Mutt and such are not the kinds of
forwarders that are being talked about here.)

MS's claim that many forwarders already insert these headers appears
to have no connection to reality.


5.  Because I think the PRA algorithm can be improved, I'd change
    the beginning of this section to "The current PRA algorithm",

Please explain how you can think that you can change the PRA
algorithm.  


    It's also not fair to complain that it drops mail with an
    unauthorized Sender:, since that's its *purpose*.  It would
    be just as wrong to complain that spf drops mail with an
    unauthorized MAIL FROM.

These problems with the PRA were all discussed before the paper was
written.  The problem is not that the Sender: header is unauthorized,
it is that the PRA assumes that it will be added under a certain set
of conditions, but there are other conditions when it is added when
the PRA doesn't expect it to, or not added when the PRA requires it.

It is bad enough that SPF and SenderID requires many forwarders to
change, but SenderID requires lots of other situations to be fixed
also. 


    |PRA gives incorrect results (false positives) on all the same
    |things that SPF does, but also fails on mailing lists, and
    |moderated newsgroups,

    But wait, there's more.

    I don't understand the newsgroups comment--why would anyone
    be applying SenderID tests to newsgroups--so I'd drop that.

It appears that you missed the discussion of the problems with
*moderated* newsgroups.  It is in the archive.



    Then we're left with mailing lists.  SenderID would work on
    lists that add a Sender: line.  In my mind, lists that don't
    add Sender: lines are technically broken and *should* be
    fixed.

There is *no* requirement in any RFC that says that mailing lists must
add Sender: lines.  In the real world, many don't.  The point is that
SenderID requires far more of the email world to change before it will
stop giving false positives than SPF.


Ok, things like DK requires even more upgrades to the email world than
even SenderID, but IIM and SPF+SES look far better at protecting the
email body than either SenderID or DK.


-wayne