From: Tony Finch
Sent: Thursday, June 17, 2004 12:31 PM
On Thu, 17 Jun 2004, Seth Goodman wrote:
<...>
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.
I stand corrected. Thank you for pointing out the relevant section in 2822.
The Outlook MUA is definitely broken in this respect. It appears that due
to this provision of the RFC2822, my proposal to require the return-path to
be the same as Sender:, if it exists, or From:, if Sender: does not exist,
is not feasible.
The Atkinson draft, if adopted, might make such checks feasible, but that
creates a large problem in getting a lot of MUA's to change.
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.
That's starting to sound more reasonable, although validating a host of
signatures could be quite a load on an MTA.
--
Seth Goodman