Bug 11634 (DMARCREJECT)

(In reply to Michael Tremer from comment #0)
> This is our ultimate goal which is a not possible to be done short-term.
> Therefore this is a tracking bug that is supposed to track all steps that
> are necessary for this to be achieved.
Well, we have do differ between _sending_ and _receiving_ mails.

Looking at the sender side, we have to make sure all mails can be validated (correct DKIM signature) and there are no mails with "internal" accounts - such as nginx - left. ARC is needed here, too, to add the Authentication-headers before a mail is delivered to the mailing list.

Looking at the receiving side, we need to deploy ARC and it probably will take some time until we can switch to DMARC reject mode, since mailing lists are causing a lot of trouble here at the moment.

Can you create the appropriate tickets to roll out ARC?

(In reply to Michael Tremer from comment #2)
> Can you create the appropriate tickets to roll out ARC?
I am currently researching abount appropriate software (openarc vs. authenticating-milter), but as soon I am through this, tickets will be created.

Well, this is actually ON_DEV by now. As soon as we are done with new mail01, I can test ARC signing for Mailman.

ARC signing is now working. Two things need to be solved before we can switch to DMARC reject policy:

(a) DMARC reports from Google look bad - DKIM signatures are invalid for almost any messages. We do not observe this for any other DMARC reporter but I have no idea about the root cause.

(b) Mailman sometimes renders DKIM signatures invalid (see #11635).

These are both very severe blockers.

The vast majority of emails that we sent is going to Google, unfortunately.

And we need to be able to rely on emails reaching their destinations. Of course we cannot bounce-handle a large amount of emails.

> (a) DMARC reports from Google look bad - DKIM signatures are invalid for
> almost any messages. We do not observe this for any other DMARC reporter but
> I have no idea about the root cause.

This turned out to be a bug in the DMARC reports parser we use, the actual results from Google look quite good. As soon as this is fixed upstream, we will be able to see valid data again.

The DMARC reports parsing issue has been fixed meanwhile.

For some reason, Mailman behaves better (at least the DMARC reports suggest this), which is why I propose to start by setting ipfire.org's DMARC policy to "quarantine" for 10% of the mail volume.

Did we learn anything, yet?

> Did we learn anything, yet?

Not really, aside from me being surprised how clean our DMARC reports are. On the
other hand, the number of entities we receive reports from is not very diverse, with
GMail of course leading the list.

Sometimes, Mailman still seems to break DKIM signatures, for a reason yet to be
investigated further. Since this only happens for some - but not all - UTF-8 mails
without a Content-Type header (as emitted by "git send-email"), I am tempted to blame
Python's email module here. However, I have spent hours on trying to reproduce this
- as of today, without success. :-/

Mail.ru occasionally reports some messages spewed out by various dial-up IPs in
Russia and some countries in Eastern Europe (I am puzzled to see they even accept
mails from such IP ranges - some of them do not even have a PTR). While their number
is very low, I have not observed Mail.ru to apply a quarantine policy on them.

After the mass mailing following your blog post the other day, I have now increased
the percentage of IPFire.org's DMARC policy to 25 %.

> After the mass mailing following your blog post the other day, I have now increased the percentage of IPFire.org's DMARC policy to 25 %.

Meanwhile, for the records, we run ipfire.org with a DMARC quarantine policy for 100 % of the mail traffic for several months. I am unaware of any issues.

https://lists.ipfire.org/mailman/private/infrastructure/2022-May/000286.html