On Fri, 15 Oct 2004, Meng Weng Wong wrote:
Excellent, I think we are beginning to agree on exactly
where we disagree.
This is not very encouraging...
I see the 2821.mail-from as the province of the MTA.
Ok. And there is nothing stoping them from adapting these checks it - for
either commercial or non-commercial MTAs... Great for all!
I see the 2822.pra as the province of the MUA.
I disagree with this in particular because PRA is technically bad idea for
MUA checking, but I agree in general that checking headers is good for MUA
verification while checking SMTP session parameters is good for MTA.
I think we can agree that a significant population of MTA in use are
opensource: sendmail, postfix, exim, qmail, and the like.
It does not make any difference if we assume that checking 2821 parameters
is non-encumbered by patent and can be implemented by both commercial and
non-commercial programs.
Similarly, the vast majority of MUAs are commercial:
Outlook, Outlook Express, Eudora, Mac Mail.
Ahhh, lets not forget about Pine, Mutt, Elm, Thunderbird, Ascension,
Pygmy, Mahogany and other mail programs I've used ...
And what about a multitude of webmail client deployed by ISPs, such as
Squirrelmail, Imp, Neomail, Gatormail, Noc, etc - 90% of the deployed
webmail programed used by ISPs are open-source!
I do not expect opensource MTA software to implement PRA checks.
How supportive of opensource MTAs of you ...
I do expect commercial MUAs to implement PRA checks.
I hope not!
I expect that Microsoft will bundled PRA checks into Hotmail
and Outlook; I expect Qualcomm will bundle PRA checks into Eudora.
Qualcomm is usually smarter then Microsoft, but its difficult to compete on
futures with company that has millions and makes it software available free
if there is any serious competition (and after achieving monopoly, they begin
to release non-commercial premium packages for those interested in next
version).
They don't need our permission to use v=spf1 in PRA scope; all they
need to do is tell people they're doing that, and people will listen.
Imagine the situation where somebody is being told to publish SPF record
for PRA / SenderID with reference to spf.pobox.com on what SPF is and
then when person comes to spf.pobox.com he sees the following statement:
"Attention Domain Administrators,
It has come to our attention that some companies are advising domain owners
to publish SPF version 1 records for purpose of compliance with Sender ID
verification system. We'd like to warn that such use of SPF records is
not in compliance with published SPF version 1 standard (see RFCxxxx at
www.ietf.org/... ) and that SPF version 1 records are only intended for
verification of Return-Path email parameter as explained in detail at ....
and such verification is properly supported by software packages offered
by the following companies:
1 ...
2 ...
3 ...."
Now is this going to stop Microsoft from publishing its own dns spf records?
Probably not - they are so large that they no longer care about statements
like this that they are violating standards. But is this going to bother
domain administrators who are the ones who want to publish SPF record?
Yes! The majority of domain administration is done by ISPs and ISP techs
are well aware of what RFCs are and will not be willing to violate it!
Additionally press will pick this up as well and you can be certain Microsoft
will get its share of nicely done editorials about how they are violating
standards for unproven technology.
And the patent problem is simply irrelevant to them. Therefore there
will be widespread acceptance of PRA in the MUA whether or not
opensource has a problem with it.
If there is a clear statement from SPF community that we do not approve
of PRA checking based on v=spf1 records, I do not think it'll be adapted
by anybody but Microsoft itself (mail software engineers are even more
aware of what it means to violate an RFC than domain administators).
And in the end Microsoft can not tell that it has achieved "de-facto"
standard if nobody else is doing it! So it may yet be a good lesson
for them about not ignoring IETF even if it takes them a year to
understand.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/