There still some serious problems with the PRA algorithm.
Checking identities in non-standard headers makes invisible spoofing
easier, and substantially negates the benefits of checking header
identities instead of envelope identities. Section 7.3 says that "MUAs
will need to start displaying at least the header that was verified" but
in early deployments the MUA won't know anything about Sender-ID
verification.
Section 9.2 uses ambiguous language. Forwarding means several different
things. If it is being used to mean aliasing (per the language in
draft-crocker-email-arch-00) then the recommendation to add a Resent-From
header is contrary to the sematics in RFC 2822 section 3.6.6 (see the
paragraph starting Note:). This must be made more explicit. The similar
recommendation in section 9.3 is only marginally less dubious.
The PRA algorithm in section 4 makes a probably-incorrect assumption about
the relative priority of Resent-* and Envelope-To. What if a message is
re-sent in an RFC 2822 manner to an address which is aliased and which
causes an Envelope-To: header to be added at that time? The PRA algorithm
will get it wrong.
The systems I run will have to be modified to work with any version of the
PRA algorithm, since none of them add any of the necessary headers when
dealing with aliased addresses. One of the claimed benefits of Sender-ID
was that it makes SRS unnecessary, and one of the reasons people dislike
SPF/SRS is that it requires systems with aliased addresses to be modified.
Not such a good benefit from this perspective!
There's also a very tricky problem dealing with messages for multiple
recipients, since they may end up going to multiple aliases which target
the same destination domain. At the moment we can send a single copy of
the message on to its next hop with multiple envelope recipients. This
isn't possible with Sender-ID -- adding an Envelope-To: header listing the
multiple recipients is a privacy problem (it breaks BCC: and cheapo
alias-based mailing lists), and mis-using Resent-From: requires us to
de-optimise onward delivery to one recipient per message and I'm not sure
we can do so without de-optimising everything.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
BERWICK ON TWEED TO WHITBY: SOUTH 3 OR 4 VEERING SOUTHWEST 4 OR 5 LOCALLY 6.
CLOUDY, PERIODS RAIN THEN RISK SHOWERS. GOOD FALLING MODERATE AT TIMES. SLIGHT
INCREASING MODERATE.