On 2024-10-25 at 13:19:58 UTC-0400 (Fri, 25 Oct 2024 18:19:58 +0100)
Ralph Corderoy <ra...@inputplus.co.uk>
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
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Reply via email to