spf-discuss
[Top] [All Lists]

Re: web page on sender ID

2004-11-05 16:21:03
My wife usually does this job for me, But I'll try to do it for you.  Be a 
little careful if you cut and paste any of this.  I have put in a few 
parenthetical comments (in double angle brackets, to make them more obvious).  
Those should be removed.



The sentences:
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. 

Should be:
Microsoft's patent license for SenderID is incompatible with far too large a 
percentage of deployed MTAs for it to become a standard (de-jure or de-facto). 
<<Omit second sentence.  Personal crusades are not a useful thing to advertise 
here.>>


The sentences:
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. 

Should be:
The PRA algorithm used in SenderID will not protect the From: header when 
phishing is going on.  Phishers will certainly adapt to making the 
Resent-Sender: header pass PRA checks.  When that happens, From:, Sender: and 
Resent-From: headers are left unverified by PRA and can still be forged.  So, 
the PRA only protects From: when there is no need to protect it and fails to 
protect it when needed.  (Note: SPF-classic has essentially the same weakness 
against phishing, but makes no claim that it provides superior phishing 
protection.)


This sentence:
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.

Should be:
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 MTAs 
incorrectly add the wrong Sender: header.


The sentences:
From what information is available the general consensus is that 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.

Should be:
From what information is available, the general consensus is that, since mail 
coming from mailing lists is far more common than mail coming from forwarders, 
this means that the PRA will have an error rate of at least 10 and maybe up to 
1000 times as high as SPF-classic.


The sentences:
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. 

Should be:
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 records, in others (e.g. SES exists:), they can't. Where 
SenderID breaks the function of existing v=spf1 records, domain owners will 
only learn of it when legitimate mail is not delivered.  SPF record publishers 
made their records public with the expectation that they would be used with the 
SPF algorithm.  SenderID puts those records to a different, possibly 
incompatible use, without any consent from the publishers.  <<Omit those last 
two sentences if you like. They are only a suggestion from me.>>  When SenderID 
was under consideration by the MARID task group, there was never any acceptance 
of the idea that SenderID would reuse v=spf1 records.  Microsoft, appeared to 
agree that SenderID would require its own records.  Since the time MARID failed 
to advance the SenderID proposal to the IETF for further consideration, 
Microsoft has proposed this reuse of v=spf1 records on their own.  <<You can 
omit those three sentences too, if you like.>>


This sentence:
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.

Should be:
The PRA requires a 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 or forwarding.

This sentence:
The only reason that one 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.

Should probably be:
It appears that only reason 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.



Hope this is helpful.

Mark Holm


<Prev in Thread] Current Thread [Next in Thread>