Page History

...

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

Wiki MarkupBut [SpamAssassin] sometimes runs as an MTA-level filter - \[http://marc.merlins.org/linux/exim/sa.html example at the top shows SA refusing mail at SMTP time\]. It should run as such wherever possible, IMO, and when it does, it should reliably determine the envelope. -- [– MatthewElvey]

However, a way for the MTA plugin to *inform* the SA code of the envelope data reliably is needed. The recommended way to do this, currently, is to ensure that the message text passed to SA contains that relay's Received header. Adding the envelope-sender info along with the other envelope info (HELO, connecting IP, rDNS) makes sense here. – JustinMason

...