--Tony Finch <dot(_at_)dotat(_dot_)at> wrote:
It says that the Resent- headers are for MUA resending, not for MUA
encapsulated-message forwarding and not for /etc/aliases or .forward
forwarding. Read the paragraph starting "Note:" in section 3.6.6 of RFC
2822.
Interesting. So it mentions /etc/aliases and .forward specifically and
excludes them?
Anyway, that's not important, the PRA can be drawn from a number of
headers, such as those added by my default installation of Postfix 2.0:
Delivered-To: gconnor(_at_)neko-base(_dot_)nekodojo(_dot_)org
At any rate, the multiple headers that make up the PRA were chosen
carefully -- those are the headers that most forwarders and many MTAs
*Already* add to their forwarded mail, so many forwarders will not have
to change anything -- those that do will just need to upgrade their MTA
to the latest version or edit a config file.
That is incorrect regarding the behaviour of MTAs. The Caller-ID draft
explicitly says that they require all alias-forwarders to change their
software. Read section 3.2.3 of draft-atkinson-callerid-00.
Hmm, I haven't read that draft yet, perhaps I should. But I believe
"draft-ietf-marid-core-00" is more important because it is newer and
describes the SPF/CID merged proposal, not just the CallerID proposal.
Anyway, it says:
4. Determining the Purported Responsible Address
...
(3) The first of either the Delivered-To, X-Envelope-To or Envelope-
To headers in the message. These headers are added to forwarded
messages by some well-known MTAs.
So it looks like Resent-Sender and Resent-From are supported, but so are a
few others. This, I think, represents the value of PRA over some other
forwarding schemes like SRS.
Let me know if I am misunderstanding you in some important way?
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>