In <20041105064205(_dot_)GC6162(_at_)dumbo(_dot_)pobox(_dot_)com> Meng Weng
Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> writes:
I would like spf.pobox.com to have a page on Sender ID that
accurately reflects the SPF community's position on the
matter, but as I have been given very little time (a little
over 12 hours to comply with this ultimatum), could someone
please put together a page that I can link to from
index.html?
As Frank correctly mentioned, I don't think the "SPF community" is
currently organized well enough to give a position on SenderID within
the alloted time period.
On Thu, Nov 04, 2004 at 08:36:07PM -0800, Craig Spiezle wrote:
| Meng, we need to know one way or another if you site will have Sender ID
| Framework content live and highlighted by Sunday night, (above the
| fold).
You already have some SenderID information on your website. Also,
isn't SPF-classic now officially part of SenderID and therefore
everything on the website is SenderID Framework content?
| As I am traveling, we need confirmation by 9:00 am tomorrow Friday.
| Otherwise we will follow your request and NOT have the site link to
| pobox.com. We will be happy to add the link once you have your site
| updated.
|
| Jacqueline, please have the link to spf.pobox.com / SPF removed from the
| site unless you hear from Meng by 9:00 am.
I'm a little confused by this. The only link to spf.pobox.com that I
know of on the MS website is at the very bottom of:
http://www.microsoft.com/presspass/press/2004/jun04/06-24SIDSpecIETFPR.asp
Did you request that it be removed? If so, why? It seems like such a
small link that I can't see it making much difference one way or the
other.
As far as my personal position on SenderID, I have long held that:
* The patent license is incompatible with far too large a percentage
of deployed MTAs for it to become a standard (de-jure or de-facto).
Unless a widely accepted alternative that covers the From: header
can be found, I will work to stop any standardization on the PRA.
* The PRA has many technical problems that make it unsuitable for use
in the real world.
* The PRA doesn't protect the From: header when phishing is going
on. So, the PRA only protects it when there is no need to protect
it.
* The PRA gives false positives (fails) on all the same things that
SPF does, but also fails on mailing lists and on some
person-to-person email when the MTAs incorrectly add the wrong
Sender: header.
From what I can tell, since mail coming from mailing lists are far
more common than mail coming from forwarders, this means that the
PRA has an error rate of at least 10 and maybe up to 1000 times as
high as SPF-classic.
* SenderID re-purposes the v=spf1 records. This will cause failures
in cases where deployed SPF records currently work. In some
cases, those failures can be fixed by changing things, in others
(e.g. SES exists:), it can't
* The PRA has had very limited deployment and testing, making it far
riskier than SPF-classic.
* The PRA requires the use of the Resent-* headers that many people
believe is inconsistent with the use defined in RFC2822. Almost(?)
no one currently uses these headers for either mailing lists nor
forwarding.
The only reason that I can tell that the Resent-* headers are used
instead of a new, PRA specific header, is that it a new header
would making very obvious that this is a significant change to the
current email enviroment.
I'm sorry that this isn't a web page as you asked for. I could create
one easily enough, but it would still be my opinion, and not the
consensus of the SPF community.
If I've missed something and I can help, please let me know.
-wayne