On Thu, 17 Jun 2004, Seth Goodman wrote:
I think this is a useful idea, but it needs some elaboration. In
particular, remember that the usual way for a message to be re-sent by an
MUA involves adding Resent-*: headers and submitting the new message such
that its return path refers to the re-sender, not the original sender.
i.e. you need to use the PRA algorithm to work out which header to compare
with the de-signed return path. For original messages, compare with the
Sender: or From: and for re-sent messages compare with Resent-Sender: or
Resent-From:.
"Forwarding" resulting from a user hitting the forward button in their MUA
is not the same as forwarding by an MTA set up by a recipient on his own
behalf.
I know. (I prefer to call the latter aliasing, as in
draft-crocker-email-arch-00.)
Note that the requirement in the MARID draft that forwarding MTAs add a
Resent-From: header conflicts with these existing semantics (because the
return path remains the same rather than agreeing with the Resent-*:
headers) as well as requiring a lot of software to be changed (in which
respect it's as bad as SRS).
Keeping the return-path the same and adding a Resent-From: header makes
sense, as this is an actual forward, which the RFC's consider a redirection
rather than a redistribution of the message. I think the behavior of the
MUA that you list above should be different, as it is potentially
misleading. The behavior you describe from the MARID draft would still
allow enforcing MAIL FROM: == Sender: or MAIL FROM: == From:.
Pine's re-sending behaviour which I described is what RFC 2822 describes
in section 3.6.6. The RFC explicitly says that Resent- headers are not for
use in alias-style forwarding (or encapsulation-style, for that matter).
However draft-atkinson-callerid-00 section 3.2.3 proposes to change this.
This produces two cases: The standard meaning, in which you would expect
the return path to be the same as the Resent-Sender: if it is present; and
the Microsoft meaning, in which you would expect the return path to be the
same as the Sender: whether the Resent-Sender: is present or not.
Yes, RFC 2822 re-sending makes From: forgery easier. MUAs that fail to
display Resent- headers are simply broken in this respect.
This kind of problem is why I advocate a signed counterpart to each
originator address in the header. Each address is then individually
verifiable, independently of shaky chains of trust or algorithms that do
not take into account the gamut of behaviour out there or which require
everyone to install new software.
--
Tony Finch <dot(_at_)dotat(_dot_)at> http://dotat.at/