Closed Massedil closed 1 month ago
It's not easy because there are many conflicts. Especially when mail is handled by a different server and imported/exported or other.
The only thing i can come up with, is to set priority which check comes first (per domain)
I don't really know what is the good way to solve this issue.
For Authentication result header, I remember reading something saying (in a RFC ?) that the recipient email server has to remove all other Authentication result header and then put the good new one (not sure at all about this). If this is true, it means that it is not really the mail display agen to be responsible of this.
But I don't know if there is something similar for spam checks.
And it is not sufficient : if recipient server does not handle Authentication result header at all, snappymail can be tricked by a Authentication result header put by the sender (or spam score).
Do you know how it works with Thunderbird or others mail display agent ?
https://datatracker.ietf.org/doc/html/rfc7601#section-4.1
In order to ensure non-ambiguous results and avoid the impact of false header fields, MUAs and downstream filters SHOULD NOT interpret this header field unless specifically configured to do so by the user or administrator.
So SnappyMail (Thunderbird, KMail, etc. etc.) SHOULD NOT show any results... EVER... And i can tell many reasons why.
But why make it so complicated and never? We can just assume the second part of RFC7601
(1) they are certain the header field will be validly added by an agent within the ADMD that accepts the mail that is ultimately read by the MUA, and (2) instances of the header field that appear to originate within the ADMD but are actually added by foreign MTAs will be removed before delivery.
And that's what SnappyMail (and most others) assume, because these days this part is very important and more common.
In your case (2) is not handled by your ADMD and SnappyMail should be in NEVER mode.
So should SnappyMail have a NEVER mode for your ADMD?
So should SnappyMail have a NEVER mode for your ADMD?
I think yes. And may be an admin property (per domain ?) can control if it is activated or not ?
And off by default ? (Because as you said "MUAs and downstream filters SHOULD NOT interpret this header field unless specifically configured to do so by the user or administrator")
And off by default ?
For now they are all on by default. This is easier to understand when adding new domains, because now you see the options and can remove them when not needed. And it is backward compatible with the old behavior.
Describe the bug
DKIM and spam level analyse should be ignored if they are not done by our server.
I don't know how to know which header is to trust and which to ignore. May be trust everything after the last
Received:
?To Reproduce
Expected behavior
Here the spam level is not displayed on the user interface, because it is untrusted.
Screenshots
Please complete the following information: