On Wednesday, October 21, 2015 05:13:15 AM Marco d'Itri wrote: > On Jul 14, Marco d'Itri <m...@linux.it> wrote: > > The BTS too needs a solution to this, and it will be an harder problem > > since it does not have the option of not modifying the messages in > > transit. > > > > The AOL/Yahoo address book spammers now switched to forging gmail.com, > > so Google could be very close to enabling p=reject as well. > > gmail.com will switch to p=reject in June 2016: > https://wordtothewise.com/2015/10/dmarc-news-gmail-preject-and-arc/ > > The good news is that probably a technical solution will be ready in > time, but then we will have to either implement it (which will probably > require installing a backported OpenDKIM package) or reject mail from > domains with p=reject.
It's more complicated than that. See my analysis below. > Actually, until a solution will be available the BTS should already be > rejecting mail from domains with p=reject since it cannot be delivered > to significant parts of the Internet. My view is that those parts of the internet have said they don't want such mail, but that's there call. That doesn't mean we should go out of our way to avoid sending it. Setting this up might be nearly as much trouble as just fixing the BTS to send DMARC compliant mail. Analysis follows: Here's the relevant header fields from a recent bug report I received via the BTS: Return-Path: <debb...@buxtehude.debian.org> From: Mika =?UTF-8?Q?Pfl=C3=BCger?= <deb...@mikapflueger.de> Subject: Bug#799736: python-milter: [snip - details don't matter] No DKIM signature present. There are two possible stratgies: 1. Make DKIM signatures provided in the submission mail survive BTS processing so that DMARC for the originating domain passes 2. Make the mails originate from the BTS and the original domain's DMARC becomes irrelevant. To make the first strategy possible, the BTS would have to cease common modifications such as adding the bug number it assigns for a new report. This means new reports would have to be sent to the maintainer with no bug number and a separate mail from the BTS provided with the bug number. This seems problematic. Adding a Debian originated DKIM signature won't help make this approach work since the body From is still the original domain and the Debian DKIM signature will fail the DMARC identity alignment test and not be used (except in the case of mails from DDs debian.org addresses, but we can't really optimize for that). Strategy #2 would involve changing the body from the originating address to an internal BTS address. Once that's done, the originator's DMARC record is irrelvant. If desired, DKIM signing and an appropriate SPF record could be set up, but it's not really needed to avoid the consequences of these p=reject domains. For regular Debian mailing lists, the list masters chose strategy #1 (make is so originating DKIM signatures are not invalidated by the mailing list). I don't think this is feasible for the BTS. Strategy #2 is, in my opinion, ugly, but would work. Scott K
signature.asc
Description: This is a digitally signed message part.
