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