#1052624 debbugs: forwarded messages break DMARC, DKIM, SPF

#1052624#5
Date:
2023-09-25 12:38:14 UTC
From:
To:
Debbugs forwards messages from bug maintainers with their From lines
intact, which is quite problematic for senders whose domains use
DMARC, DKIM, and/or SPF.

SPF: Since the forwarded messages aren't coming from one of the
sender's domain's mailservers, they violate the domain's SPF policy,
if any.

DKIM: debbugs modifies the forwarded messages in ways that break their
DKIM signatures.

DMARC: because SPF and DKIM are both broken in the forward, these
messages can't possibly be compliant with domain DMARC policies.

As a result, transmission and distribution of these messages is quite
unreliable. At the very least these signals make the messages more
likely to be interpreted as spam. At most they are completely bounced
by some recipients' mail servers.

The most obvious solution to this is straightforward: the From line in
these messages should be modified to contain the email address of the
bug, not the email address of the original sender. The original
sender's address can be put in Reply-To and/or indicated in the header
in a number of other ways. For example, sometimes something like this
is done:

  From: Jonathan Kamens <jik@kamens.us>

becomes:

  From: "Jonathan Kamens <jik@kamens.us> via" <###@bugs.debian.org>
  Reply-To: ###@bugs.debian.org, jik@kamens.us

There are different implications of the various ways this can be done,
so some thinking does need to go into the best way to do it, but it's
not an unsolvable problem.

If there is resistance to making this change across the board, then
another possibility is to only modify the headers on messages which
have DMARC policies and/or restrictive SPF policies. MailMan has a
mode which behaves this way.

In any case the original DKIM signature from the sender should be
removed since the messages is being modified. I'm not sure whether
debbugs already does this.

I would be happy to "put my money where my mouth is" and work on
fixing this and submitting a patch. However, I am reluctant to just
"jump in" and send in a patch without some engagement from the debbugs
maintainers first, because (a) as noted above, some consideration
needs to be given to the ramifications of various solutions before one
is chosen, and I don't think I'm in any position to do that
unilaterally, and (b) because this is a relatively old problem with a
relatively straightforward solution, I suspect that there may be
non-technical reasons why a fix hasn't been implemented. I'm reluctant
to do work that is not going to be accepted for philosophical or
political reasons.

Jonathan Kamens

#1052624#8
Date:
2023-09-28 03:11:03 UTC
From:
To:
Control: reassign -1 bugs.debian.org
Cotnrol: forcemerge 830865 754809 -1

The problem with this specific From-rewriting is that it breaks replying
to the sender instead of just the bug (though maybe that's not a huge
deal).

Ideally we'd be able to oversign the messages, but DMARC and DKIM
weren't engineered to allow that. I've personally been ignoring it
because I've been hoping that the standards would get fixed, but if it's
impacting enough Debian contributors to matter, I don't mind accepting a
patch.

#1052624#15
Date:
2023-09-28 11:33:48 UTC
From:
To:
I mean, ARC was sort of intended to address this, but it doesn't really
because receiving servers have to explicitly decide which ARC signers
they trust, which honestly makes it only useful for the really big email
providers. Few sites are going to bother maintaining a trusted ARC
signers list that is sufficiently large and granular that it has email
senders like Debian on it. ARC has always felt kind of dead in the water
to me because of that, but maybe I'm unaware of some clever advance
they've come up with that is going to solve this problem.

I'm happy to work on a patch as my time permits, but there are two
unknowns here that make me reluctant to just jump in:

(1) I don't know what "impacting enough Debian contributors to matter"
or who's going to make that determination.

(2) As discussed above, there are numerous ways to do this, and I don't
know which of them will be considered acceptable by the BTS maintainers
or how to make that determination. I'm reluctant to just "take a stab at
it" and hope that whatever I implement gets accepted.

   jik