...

Traditionally, the envelope-sender data has been added to messages as they pass through MTAs, but in varying ways (the Return-Path header, X-Envelope-From, etc.), and generally in terms of one header in the message. see EnvelopeSenderInHeaders.

Actually, the Return-Path is standard now,
and I don't see any need to add yet another
way to specify the envelope recipient. Go
read RFC-2821 section 4.4 where this header
is defined as a MUST.

   Arik Baratz

A very helpful addition to support MUAs and MUA-level filters, would be if this was added to the Received header for the MTA handover, e.g.

...

If you know of an MTA package that will add the envelope-sender data to the Received header, or can write a configuration stanza to add to config files to do this in any given MTA, please add a note about it on this page using the "EditText" button below.

Comments

Actually, the Return-Path is standard now, and I don't see any need to add yet another way to specify the envelope recipient. Go read RFC-2821 section 4.4 where this header is defined as a MUST. – Arik Baratz

The issue is that MUAs and MUA-level filters like SpamAssassin cannot reliably determine the envelope sender (note; not recipient) at intermediate steps along the Received chain. Some forwarding use cases, like mailing lists, fetchmail, or SRS-compliant forwarders, will resend the message with a new envelope sender, which means that a filter cannot check back beyond that step. Given situations where spam arrives via lists or at a forwarding address, this means that the filter cannot use the env-sender to detect spam in that case, and in the fetchmail situation, the filter cannot trust that data at all, and therefore cannot use env-sender or SPF at all. – JustinMason