...

received_header_text = Received: \
      ${if def:sender_rcvhost {from $sender_rcvhost\n\t}\
      {${if def:sender_ident {from $sender_ident }}\
      ${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}} }}\
      by $primary_hostname \
      ${if def:sender_address {(envelope-from\n\t\
      <$sender_address>)\n\t}}\
      ${if def:received_protocol {with $received_protocol}} \
      ${if def:tls_cipher {($tls_cipher)\n\t}}\
      (Exim $version_number)\n\t\
      id $message_id\
      ${if def:received_for {\n\tfor $received_for}}

• Sendmail
  Mike Markley reports: Sendmail can be trivially made to insert the envelope-sender into the Received header by setting confRECEIVED_HEADER, or by using the builtin REC_BY macro (used to construct the default Received header) like:
  

define(`_REC_BY_', `$.by $j (envelope-from $f) ($v/$Z)$?r with $r$. id $i$?{tls_version}')

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. Recording Return-Path is still useful and required, but this is an 'extra' which allows this data to be visible for all stages of the message relay flow. – JustinMason

...