I noticed that Mail::SpamAssassin::Conf describes the search algorithm for the message sender as follows:
| SpamAssassin will attempt to discover the address used in the | 'MAIL FROM:' phase of the SMTP transaction that delivered this | message, if this data has been made available by the SMTP server. | This is used in the EnvelopeFrom pseudo-header, and for various | rules such as SPF checking. | | By default, various MTAs will use different headers, such as the | following: | | X-Envelope-From | Envelope-Sender | X-Sender | Return-Path | | SpamAssassin will attempt to use these, if some heuristics (such | as the header placement in the message, or the absence of | fetchmail signatures) appear to indicate that they are safe to | use. However, it may choose the wrong headers in some mailserver | configurations. (More discussion of this can be found in bug 2142 | in the SpamAssassin BugZilla.) | | To avoid this heuristic failure, the envelope_sender_header | setting may be helpful. [...] | | If the header in question contains < or > characters at the start | and end of the email address in the right-hand side, as in the | SMTP transaction, these will be stripped. The existing algorithm doesn't seem to work very well (or at least it doesn't seem to work very well here; 2.64 seemed to be more reliable about this, but 3.0.1 only seems to find From). I haven't come across any significant discussion so I'm not sure what's going on here. I suggest the following order: [user-override first] Return-Path Sender Resent-Sender List-ID List-Post/-* non-standard headers (like Errors-To) From Resent-From The subset of List-* headers use different field structures (some of them use URIs) and therefore require additional pattern-matching than the simple matching. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
