Subject: Re: [Emailcore] [mailop] Spamhaus Public Mirror Error Return Code Update

From: Michael Peddemors <[email-masked]>
Date: Tue, 16 Feb 2021 16:49:07 -0800

On 2021-02-16 4:26 p.m., Vsevolod Stakhov via mailop wrote:
> On 16/02/2021 21:25, Michael Peddemors via mailop wrote:
>> FYI, you might want to check your outbound spam filter ;)
>>
>> X-Spam: Yes
>>
>> One thing to note, and maybe should be something to actually take up
>> with RFC's, but wonder if flags like this should some how become trace
>> headers..
>>
>> Eg, which system put that header into the header list..
>>
>> Especially now that inbound, outbound, and in transit systems and MTA's,
>> may actually be involved..
>>
>> Or better yet, if a system flags a message as spam, should you allow it
>> out the door?
>>
>> Looking at the headers, have to 'guess' that it was inserted by ..
>>
>> Received: from mail.highsecure.ru
> 
> Yes, that's because of DBL listing of some of the urls quoted by myself
> in the reply. I have a mail system configured to mark both inbound and
> outbound flows mainly for testing purposes. Normally Rspamd removes this
> header for outbound traffic but it could be useful to keep X-Spam header
> for the mailing lists traffic (and that's the reason why this is
> configured so in my mail system, well, apart from my laziness to make it
> properly via Rspamd settings). Anyway, thank you for pointing that out!
> 
> I would strongly support any standards around mail trace headers for
> spam, as they are very common and very different in the email flows. We
> use several regular expressions to use those headers
> (https://github.com/rspamd/rspamd/blob/master/rules/regexp/upstream_spam_filters.lua)
> but this list is very far from being complete.
> 
> Apparently, any standard would reduce and simplify (likely) this
> processing, especially if there is a way to check if this header is
> genuine - e.g. ed25519 signatures are fairly cheap and they are
> deterministic, meaning that a single signature might be reused for the
> same input + keypair for both signing and verification so caching might
> make it even cheaper for popular values and domains.
> _______________________________________________

Yeah, we have a pretty long list of 'upstream_spam_filters' as well, 
maybe it would be worth while to find a location to put a definitive 
list that everyone can contribute to.. but to reiterate, I don't have a 
solution, but whatever convention(s) that we come up with, it should be 
something that can 'show' which mail processing system added the header, 
and thus by making it a 'trace header' (adding it in order) might make 
sense.

I don't think we have to check if it is genuine, I mean who would forge 
a 'This is spam' header, let's not make it too complex.

But really this work on standards for 'flagging' a message in transit, 
should probably be taken up in the IETF, or at least M3AAWG could come 
up with some recommendations to get it start. But one form of 'flag' 
could be 'I consider this to be spam'.

However, I should point out, because of the many different systems that 
flag a message as spam, some upstream spam filters are more trust worthy 
than others, eg not all messages flagged as spam, would we reject, some 
"we" (as in MTA operators) might just filter to the spam folder, or 
weight more heavily in scoring etc.. If that is beneficial, then maybe 
standardized on a single naming convention might not be best.

And of course, there is the case where a header COULD be forged, eg a 
'this is not spam' flag, but I think everyone would ignore that.

And then the case where if everyone used the same flag, if I believed my 
spam filter was more accurate than others, I would have to strip that 
header, so I could make the decision on whether to add that.  Which 
makes another case for having it a trace header, where each transiting 
MTA can make their own determination.

(Currently of course, we have to strip message header flags incoming 
that normally only our own systems would insert at delivery time, before 
we do our own evaluation)

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.