Re: Multiple SpamAssassins: how many X-Spam-Status header fields?

Bill Cole <[email protected]>
Newsgroups gmane.mail.spam.spamassassin.general
Message-ID <[email protected]>
On 2024-10-25 at 13:19:58 UTC-0400 (Fri, 25 Oct 2024 18:19:58 +0100)
Ralph Corderoy <[email protected]>
is rumored to have said:

> Hi,
>
> An email travelling through multiple MTAs at different institutions
> arrives with the earlier SpamAssassin X-Spam-... header fields intact,
> including X-Spam-Status, but a later check adds X-Spam-... fields except
> for X-Spam-Status.
>
> The later institution say this is because only one X-Spam-Status should
> be present so they don't add a second, or replace the first.  It means
> I see an X-Spam-Flag: No from the later check but not the tests which
> hit.
>
> - Is there some documentation for me to read which says one
>   X-Spam-Status is the maximum?

Nope.

However, many sites will clear pre-existing X-Spam-* headers with remove_header because they are inherently untrustworthy and confusing. This may be implemented in a 'glue' layer instead, such as a milter or SMTP proxy.

> - If one is the maximum, which of the assassins has their field kept?
>
> - Where is SpamAssassin's logic to handle this?

As there is no such limit, there is no such logic implementing it.

> I've had a look at the source — add_header, ham_headers, etc. —
> but don't obviously see anything which avoids adding a duplicate.

The way to avoid duplicates is to remove the existing ones before adding your own.

While the "X-" convention for non-standard experimental headers has been deprecated for years, it still is a strong sign that the header is NOT well-specified and could change in meaning over time. There are no "rules" about X-* headers except that devising new ones is a bad idea.


-- 
Bill Cole
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.