In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0410261756330(_dot_)6580-100000(_at_)bmsred(_dot_)bmsi(_dot_)com>
"Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com> writes:
On Tue, 26 Oct 2004, Roger Moser wrote:
Meng Weng Wong wrote:
I gave him my opinion that it was a good thing that MS's PRA checks could
reuse v=spf1 records.
If for some reason a domain can do only SES (signed envelope sender) and
publishes the SPF record "v=spf1 exists:%{l}._ses.%{d} -all", then this
works ONLY for MAIL FROM. If a stupid MTA uses this SPF record for the PRA,
then it will always fail and all mail will be rejected.
Thank you Roger, for pointing that out. I would like to reiterate
my desire (which doesn't seem to be shared by anyone else so far)
that any RFC2822 checks are based on the validated the 2821 MAIL FROM.
Far from no one else sharing your desire, that is exactly what my I-D
for Unified-SPF/From-Header is all about! See:
http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt
But, this draft was written long after I was already convinced that
the 2821.MAILFROM identity could and should be used to base the
validation of the 2822.From:. I argued *very* strongly on the
MARID list that this is a direction we should go. I argued that we
already have a good understanding about how to approach the
2821.MAILFROM identity, but that we didn't know of a good way to deal
with the 2822.From: identity.
Six months later, this is still true. SenderID is still untested, and
what little testing has been done has shown that it has a
significantly higher error rate than SPF-classic. Even Meng doesn't
support the PRA and thinks it is a terrible idea.
After arguing long and hard that MARID should address the
2821.MAILFROM/HELO identities first, and try and tackle the 2822.From:
identity after we picked off the easy stuff, the IETF co-chairs
agreed. They said that we wouldn't deal with the 2822 stuff until
later, taking CallerID off the table.
Things proceeded fairly well until right before the MARID interim
meeting. Then, Meng sprung a surprise deal on us that he was going to
merge SPF with CallerID. The co-chairs suddenly forgot their own
working group charter. The abandoned the 2821 identities, took
SPF-classic completely off the table and started running with
SenderID.
It was at this interim meeting when Jim and Harry said that the
CallerID license would be compatible with F/OSS software. (They
hadn't released the license yet, so no one knew.)
Of course, the co-chairs ran with SenderID straight into a brick
wall. The technical problems and licensing problems with SenderID
sunk it.
If it wasn't for Meng's "perfect leadership", we would have
SPF-classic as a standard-track RFC right now, instead of maybe a an
experimental RFC sometime Real Soon Now.
Yeah, I'm real impress by all the people coming out saying they
support Meng when they haven't done squat for SPF and many have never
even posted here before. Meng has made many good decisions, but he
has really screwed other things up. Things that others have had to
work real hard to undo. But Meng still thinks I should work for free
to get the SRS stuff that he wants done. Now that Microsoft is
onboard with the mfrom scope of SenderID, I think we should all just
wait for them to do SRS. Why work for MS for free?
-wayne