On Tue, 2004-11-23 at 04:34, James Couzens wrote:
Everyone,
I don't care if you love me, or hate me, please consider the following:
http://www.openspf.org/OpenSPF_community_position_v102.html
IF you do NOT agree, PLEASE RAISE what issue
you have with the wording to this list as anyone participating on this
list in a positive and generally non disruptive fashion is considered a
member of the SPF community.
I almost, but don't quite agree with the position paper.
Part of my objections are technical, part of them are marketing-type
objections, namely:
A. Position papers shouldn't sound whiny. Everything should be
clear, straightforward, and with a levelheadedness sound to it.
B. Position papers should only make real, solid, unquestionable
points, not weaker points that are mostly-somewhat-true or
merely debatably-true.
So going through things section-by-section, including objections,
agreements, and confusions:
1. I do not understand the objection in the
"Using SenderID _REQUIRES_ SPF" section.
Now I *do* think that if you're going to do MTA-level rejects
based on Sender ID, that you should either make sure you have
an SPF PASS result, or give temporary rejects to recipients with
differing per-user receipt policies, since otherwise you could
contribute to the blowback problem.
However, I don't think that's what this section is getting at.
It's also not related to the annoyance of spf1-records-interpreted
in-senderID scope.
As far as the SenderID spec itself referring to SPF--I really
see no greater problem with that than with the SPF spec referring
to and building upon rfc 2821.
So I really don't get what's being claimed as objectionable here.
2. "Microsoft's patent license for SenderID is incompatible with"
I have no complaints about the wording or existence of this point.
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. Whilst this technical aspect was not the
|sole contributor to the demise of the MARID working group it played
|a key role in acting as a major stumbling block for many.
The second sentence should be deleted. It doesn't belong in a
position paper, and sounds like sour grapes.
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:.)
However, my disagreement is that it's not right to force-fit
SenderID into the SPF model..not quite.
PRA tests make more sense if the test is made by the MTA, and
acted upon by an MUA--then your MUA could warn you of problem
messages. (Note: I'm biased because I still think that
sender_agents can seriously help here.)
The PRA algorithm isn't something I'd consider reliable enough
to use for MTA-time rejects though, but that doesn't make it
completely useless on technical grounds. It just means that you
can't use it to reject at MTA time *yet*, (and maybe never), but
you can still possibly use the results the MTA tells you from within
your MUA.
So I would change the first sentence to:
!"PRA" (Purported Responsible Address) as it is implemented within
!SenderID, has many technical problems that make it currently
!unsuitable to use for MTA-time rejects in the real world.
(or something similar.)
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.
4. I have a bias that sender_agents can allow a PRA-ish algorithm
to protect against phishing.
So I would change this section to add a couple "by itself"'s in.
"The PRA algorithm used in SenderID will not _by itself_ protect",
"So, the PRA _by itself_ only protects"
5. Because I think the PRA algorithm can be improved, I'd change
the beginning of this section to "The current 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.
So I would drop half the sentence, leaving things as:
|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.
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.
(They should also add List-ID headers, but that's more of
an IMHO thing.)
Given that it's not as easy for a recipient to white list
such lists if they're using SenderID testing only, (unlike
the greater ease involved in white listing on the basis of
spf/mailfrom records), the fact that there's not a good
temporary workaround is a valid complaint.
However, it's not the sort of out-and-out super-strong
complaint/issue that I think is appropriate for a position
paper.
Because of that, I'd remove that section entirely.
6. On the re-purposing of spf1 records.
GRR.
While I understand that from a technical point of view, the
records would likely be similar, it's still...just not right.
I am perfectly fine with this section.
7. I'm fine with the SenderID-isn't-as-well-tested section too.
8. Resent-Headers section: I'm mostly fine with that section.
(Maybe I'd have reworded the last paragraph a bit more politely
perhaps, though as I'm currently at a loss as to how to do that,
I can't really complain too loudly. :-) )
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com