On Thu, 2004-11-25 at 10:24, wayne wrote:
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.
For a rush job, the document is amazing.
But IMHO it's not quite suitable for a long-term position paper.
Documents that describe a current direction a group is going in will
naturally incorporate all sorts of compromises within them, but
non-rush-job position papers detailing principled and well-thought-out
technical positions and reasonings behind them should be filled with
clear, noncontroversial (within the group), things that the group as a
whole fully believes in.
The timing of the creation of the position statement meant that it had
to cover both bases, which was sort of awkward, and I admit that I
misunderstood the urgency of the need for edits and suggestions, and
didn't speak up at the time.
However, there's a short breather here, and an opportunity to have a
clearer version. (And unlike getting an spf1 draft out, there's not
such a big rush.)
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.
True, but that's not an insurmountable task.
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.
I think these changes could improve the PRA algorithm:
o Inserting "List-Id: " between "From: " and "Sender: " to help
solve the mailing list problem.
o Incorporating trace headers or a Forwarded-By header.
o Testing on the basis of SUBMITTER or the PRA, appending your own
Resent-* header if they're different, and marking the change in
some sort of trace header. (not sure about this one.)
However, whether they would improve it or not, and I may well be wrong
in my ideas that it would improve the algorithm, (I'd rather not
distract folks in debates about improving the PRA algorithm at least
until after the council gets an spf1 standard of one type or another
through), it's unrelated to the notion that it's the current version of
the PRA algorithm that's really at fault here, not the idea of testing
something like the PRA in general.
A position paper can point out that the current version has problems,
while having an open mind about a potential for improvement.
IMHO, there is neither a technical basis nor a political advantage in
claiming that the very idea of the PRA in general is utterly beyond
redemption.
It appears that you missed the discussion of the problems with
*moderated* newsgroups. It is in the archive.
I'll look at it again. At the time I wasn't quite sure that this was an
intractable problem.
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.
In my mind it's part of the very definition of "Sender: " to begin with.
I do admit that there is a curious, and amusing, lack of symmetry here:
o We expect mailing lists to create new MAIL FROMs for submitted
messages. That implies that we consider them "new" messages
it at least some sense.
o Under the logic that mailing lists recreate messages, and the
messages are sent on behalf of the original "From" person,
the mailing list should set a new Sender: field.
o However, interestingly enough the message isn't completely
remade, since it keeps its old Message-ID--or at least it is
considered acceptable for mailing lists to re-use the original
Message-ID's.
The non-symmetry is interesting, but I still consider the "remailing" of
a message via a mailing list similar to a person sending a message via
another person's account, and setting themselves as the From: and
another person as the Sender:.
(Side issue: Can we also do an SES-type functionality within
Message-ID? Maybe even having the original MAIL FROM value match the
Message-ID?)
In any event it's not really that big of a problem for SenderID if you
act on the result of the test at the MUA level--anyone who sees their
MUA distrusting all their mailing list messages should be able to easily
whitelist any List-ID: or yahoo group (with its nonstandard
List-ID:-equivalent--ugh), at least until those lists change, which they
probably will in a decade's time or so.
The point is that
SenderID requires far more of the email world to change before it will
stop giving false positives than SPF.
That's true, but it's still not really an issue for senderID tests made
at MTA time and interpreted at MUA time.
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.
True.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com