the-djmaze / snappymail

Simple, modern & fast web-based email client
https://snappymail.eu
GNU Affero General Public License v3.0
924 stars 109 forks source link

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

Closed Massedil closed 1 month ago

Massedil commented 1 month ago

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:

the-djmaze commented 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)

Massedil commented 1 month ago

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 commented 1 month ago

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?

Massedil commented 1 month ago

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 commented 1 month ago

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.