Keith Moore wrote:
even now I'm not sure that list-specific fields solve those problems,
part of the problem is probably (as you said) that the subtle
differences between return-path, from, reply-to, and sender
IMO, the whole construct is wrong. While the headers were appropriate for
the time and place of their design, the modern usage has gone to another
place which is not particularly well suited to the design. For example,
From vs Sender is a good model if From doesn't have connectivity, but in
the modern age, From is just another way for spammers to lie.
I've been thinking about this in terms of a revised format/protocol, and
am of the opinion that a better usage for the current Internet mail model
is to use a Sender and Signatories model. This solves a lot of problems,
but as with all of the other radical departures, it pretty much depends on
overhauling the infrastructure.
In the Sender and Signatories model, the Sender is the Original Sender, as
identified in the envelope. These must match, and Sender must always be
provided. If there is only one party associated with the message, then
only the Sender needs to be provided. If something like a mailing list
redistributes the message, it becomes the Signatory, but the Sender header
field remains (and must still match the Original Sender envelope). If a
secretary is sending mail on behalf of the PHB, the PHB is the Signatory,
and the secretary is the Sender. Default replies go to the Signatory,
Reply-to-All goes to the Signatory+Sender+CC.
Parts of that model are similar to Sender and From but parts are radically
different (mailing list becomes the new From-equivalent, for example).
One of obvious benefits to this approach is that forging From goes away.
Another benefit is that the mailing list model is more cleanly aligned
with the default usage. Another benefit ist that Reply processing is much
simpler. Also, following a Resent-* style of forwarding is clearer.
I know this is OT, but I wanted to make the argument that the canonical
problem is that the legacy model is not reflective of modern usages. If
anybody has any thoughts about the usage I've laid out, I'd be happy to
hear about them off-list.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/