Meng Weng Wong wrote:
[Tao, Reagan, freedom, equality. Quebec, ...]
What does this have to do with Microsoft?
Nothing. Unless that was a rhethorical question.
We observe an equally natural connection between Sender ID,
the PRA, Microsoft, and MUAs.
They forgot a way to report PRA-test results to their MUAs.
Not very consequent, if you ask me. Or the MUA is supposed
to do these tests, but that's tricky, how do you determine
the IP of the Sender within Received: headers ? And if you
got it, are you still online to load some sender policies ?
where do you put SpamAssassin?
As Microsoft I'd put into the big "not invented here" box,
that's the big box with MIME and some other "obscure" ideas
without patent numbers.
It is an interesting question for fans of alternate
histories to ask whether, in a parallel universe where MUAs
were overwhelmingly opensource and MTAs were overwhelmingly
commercial, Microsoft would have been a proponent of SPF.
Why that's possible there are _technical_ issues with PRA, and
not "only" some ideological / political / commercial issues.
the same community has said that on a purely technical level
the PRA is simply unworkable, and will be exploited the day
it comes out
Yes. And unlike spammers publishing SPF sender policies it's
no feature in the case of "PRA". PRA promises to work against
phishing. I don't see it, not without some major fixes of the
latest Sender-ID drafts.
We must distinguish between these two positions. One is to
say that you would rather speak English than French; the
other says that French people are bad.
False promises are bad. It's like saying that SPF solves the
spam problem, which would be a lie.
I believe that a single syntax which can apply to multiple
identities is more gracious than a syntax which excludes one
of them by design.
You have a point there. Even Wayne sometimes mumbles something
about 2822 headers (and his spf2.0/from draft makes sense for
some users with their own domain and smtpd on their own box).
I am arguing for PRA support not because I think PRA is
technically right, but because giving Microsoft what it has
asked for is gracious. And if Microsoft is going to take it
even if we don't give it to them, then it is not only
gracious; it is pragmatic.
Yes, you really have a point here. But at the bare minimum
this would be a _SPF_ protocol-05 with the title _SPF_ and no
"Sender-ID" vaporware with spf2.0/mfrom as an afterthought,
maybe even covered by fraudulent and frivolous patent claims.
I have no doubt that we would quickly see a full-blown
standards war.
What's that meant to be ? They are free to test their PRA in
the same way as SPF was tested. In fact they are free to fix
the d####d holes in it. Some recipes are archived in MARID -
Errors-To, default Sender, Authentication-Results, what else ?
If we refused to allow PRA at all
"We" (tinw) are not in the position to refuse anything, and
vice versa. Protocol-04 has no clause about derivative work.
Microsoft would publish Sender ID as a standard anyway and
say goodbye to the IETF.
Now here's an idea.
Part of the fallout from that standards war would be delayed
adoption of SPF (both Classic and Unified) in the market,
There's no standards war. Protocol-04 stands far above such
nonsense, it "tolerates compatibility with PRA", as you say.
And "the market" implements SPF, doesn't it ?
If you do not believe that PRA will work, you are free not
to use it, and you are free to convince people of its flaws.
Sure, I know this. It's obvious. The only reason why some
folks don't see it is because nobody really tested it.
When Harry Katz, Jim Lyon, and Bob Atkinson discussed Sender
ID in May, we agreed that v=spf1 records could also be
interpreted in PRA context without risk.
Yes, that was a fatal error.
Margaret Olson and others in the IETF later objected
s/objected/demonstrated/
v=spf1 will in future apply to PRA also.
No. All existing v=spf1 policies are meant as god, oops, you,
defined it in draft-mengwong-spf-01.txt, which does not cover
PRA. If you want PRA use spf2.0/pra or spf2.0/mfrom,pra, but
don't abuse v=spf1 policies.
Senders who do not believe that PRA is useful at all can
ignore spf2.0.
That's the short term solution, but later they would simply
not specify "pra". v=spf1 can be translated to spf2.0/mfrom
(or to spf2.0/mfrom,helo if that matches "SPF classic" better).
The above is pragmatic because it allows spf1 records to be
used by the Sender ID / Microsoft / PRA camp
No, it's not pragmatic, it's abusive. v=spf1 does not include
PRA, it didn't, and it never will. For PRA you need spf2.0.
Getting Microsoft to tell people to publish v=spf1 records
would also have been in our interest.
No. Not this abusive form of "v=spf1 cum PRA", I'd tell my ISP
that he either deletes his v=spf1 policy or loses a customer in
this scenario.
Unfortunately, the purists won that round
Yes, some technically fluent people found the obvious hole in
this idea, and fortunately the "S" in SMTP stands for "simple".
I expect Microsoft to spend considerable resources telling
people to publish spf2.0/pra records only.
That's fine, and if somebody wants more than PRA he can use a
spf2.0/mfrom,pra. The rejects he'll get will tell him.
If we bundle mail-from into Sender ID
No. That should be "if we keep scopes in SPF for spf2.0", not
"Sender-ID", that's a trademark of somebody else (not M$ IIRC).
I think we should specify spf1 to include PRA
No. That would be a lie and abuse. spf2.0 can include PRA as
one of at least two scopes, but v=spf1 can't.
we should specify spf2.0 to allow explicit PRA scoping.
ACK. Unfortunately the MARID co-chairs killed protocol-04. :-(
It was more or less ready to play the role you want it to play.
And although I don't like PRA (as it is) I don't have a problem
if others want to test it.
appeasement has been known to fail in the past.
Your ideas for spf2.0 are okay, and I supported protocol-04 and
mailfrom-00. But you cannot redefine v=spf1 to include PRA.
Bye, Frank