I would like to point out that in some cases use of Resent headers
by some forwarders but not by others would cause widespread failures
of PRA algorithm.
In particular I note that currently majority of mail list software
modify/add "Sender" header to indicate that email is coming from the
mail list (and marid-core draft notes that in section 7.3)
On the other hand majority of forwarders do not add new header at all
with some inappropriatly adding Resent-From header.
The marid-core draft specifies in sections 7.2 and 7.3 that both mail
list servers and forwarders should add Resent-From headers.
When one reads the draft and sees PRA algorithm, a person may believe
that updating mail list softwre to add Resent-From header is a low
priority if the same software is already adding Sender header and
since that header is already checked. Same person would believe that
updating forwarders to add a header is high priority since most dont
do it and that would cause widespread failures. But this intrepretation
is actually not true.
Lets consider the scenario of email path A->F->L->Z where A is sender,
Z is destination and where F is forwarder or mail list software that
has been updated to add Resent-From header and L is mail list that
has not been updated and only adds Sender header. In this situation,
email would contain Resent-From headers added by F on top somewhere
in between the Received headers. But the Sender header added by
mail list server L would be on the buttom (actually based on PRA
algorithm, it does not matter where it is, it would not be checked
if Resent-From is present). The result of interpretation of such email
based on PRA algorithm would be that Resent-From header added by F
would be found to be PRA when system Z is doing the SPF2.0/PRA
verification and such SPF verification would fail because the stage
it is verifying is actually L->Z.
So in order for PRA algorithm to be used without failures its not only
all forwarders that will need to be updated to add new Resent-From
headers but also all mailing lists. That represents a significant
issue for the quick deployment and adaption of SenderID because
number of mail lists is very larger and update of all their software
may take many years.
This issue SHOULD be mentioned as part of the marid documents so that
everyone understands the necessity to make necessary updates before
it is possible to publish "-all" with SPF/PRA prefix if we actually
choose to proceed on this path.
P.S. I would like to request that this email be counted as part of
last-call comments eventhough its 12 hours too late. I do also note
that previous email (about Resent-From being incompatible with RFC2822)
should also be counted and that it was not too late because Sunday still
falls within 3rd added week of last call period (eventhough chairs have
already announced their decision by that time, which may not have been
appropriate given timeframe they themselve specified).
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/