Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Authentication-Results and Spam-Level header only if they are added by a trusted server #1607

Closed
Massedil opened this issue May 27, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@Massedil
Copy link

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

Return-Path: XXXXXXXXXX
X-Original-To: XXXXXXXXXX
Delivered-To: XXXXXXXXXX
Received-SPF:                        <<< my server analyse
Authentication-Results: XXXXXXXXXX   <<< my server analyse
Received: from XXXXXXXXXX
Received: by XXXXXXXXXX
DKIM-Signature: XXXXXXXXXX           <<< NOT my server analyse
X-Spam-Checker-Version: XXXXXXXXXX   <<< NOT my server analyse
X-Spam-Level: XXXXXXXXXX             <<< NOT my server analyse
X-Spam-Status: XXXXXXXXXX            <<< NOT my server analyse
Received: from XXXXXXXXXX            <<< NOT my server analyse
DKIM-Signature: XXXXXXXXXX
Message-ID: XXXXXXXXXX
[...]
From: XXXXXXXXXX

Expected behavior

Here the spam level is not displayed on the user interface, because it is untrusted.

Screenshots

image

Please complete the following information:

  • Browser: Firefox
  • SnappyMail Version: 2.36.3
  • Mode: standalone
@the-djmaze
Copy link
Owner

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)

@Massedil
Copy link
Author

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 ?

@the-djmaze
Copy link
Owner

the-djmaze commented May 28, 2024

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?

@the-djmaze the-djmaze added the needs feedback Further information is requested label May 31, 2024
@Massedil
Copy link
Author

Massedil commented Jun 3, 2024

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")

@the-djmaze the-djmaze added enhancement New feature or request and removed needs feedback Further information is requested labels Jun 4, 2024
@the-djmaze
Copy link
Owner

the-djmaze commented Jun 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants