Background on DMARC:
https://wordtothewise.com/2014/04/brief-dmarc-primer/

Official statements from Yahoo and AOL about their DMARC policy changes:
http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-protect-our-users
http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/

Background on damage inflicted on mailing lists by inappropriate uses
of a DMARC p=reject policy and possible solutions:
http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail


Short summary: a p=reject DMARC policy is not compatible with mailing
lists (because their messages come from a different source IP and the
body usually is modified).
Some large freemail domains implemented a p=reject policy to fix
significant phishing attacks on their customers, but when their users
send mail to Debian lists the signatures on the messages become invalid
and they are rejected by the mail servers of the lists subscribers
receiving them.
The bounces may cause these innocent receivers to be unsubscribed from
the lists.


Yahoo and AOL explained in no uncertain terms that they will not revert
this change.
We have not suffered too much from this so far because few users post to
our lists from yahoo.com and aol.com domains, but at least another very
large freemail provider (used by a significant fraction of Debian lists
subscribers) has privately announced that they plan to switch to
p=reject as well.


I propose that our priorities should be, in this order:
- prevent damage to third party receivers
- properly support posts from users from p=reject domains


I propose that:
- we immediately start rejecting mails to our lists sent from domains
  with a p=reject policy to prevent unsubscribing innocent third parties
- we start discussing a long term solution which will allow posts from
  p=reject domains as well

This requires installing opendmarc and its dependencies and verifying
the results in smartlist.
The possible solutions are:

a) keep rejecting mail from these domains
"Soon" it will apply to too many users, so I do not believe that this
can be a long term approach.

b) rewrite the From headers of messages from these domains
The least annoying solution could be to rewrite p=reject domains with
something like s/$/.rewritten-by.lists.debian.org/ (and maybe add the
original domain to the Reply-To header).
We could even setup a MX for *.rewritten-by.lists.debian.org and reject
mail sent to it with instructions about how to reconstruct the original
header.
This can be intrusive and annoying for readers, but if the impact on
the usability for the readers is considered acceptable then it is still
better than just rejecting the messages.

c) implement a permanent and elegant solution like http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Relay_one_copy_through_author_domain_server
This solves the problem for all sides, but requires writing some
non-trivial code and forces us to store the SMTPAUTH credentials of the
submitters, which would be a big security risk for them.
(A possible alternative to phishing the submitters' credentials would be
to use some not yet specified OAUTH authentication scheme.)

I would implement that at smtp time with a postfix policyd.
in my eyes this is the only solution, that we have in the moment. I am not
happy with it, but DMARC is total broken by design and there are no
satisfying solutions.
I have some experience with such rewrites from other lists (they all reverted
such settings) and they are annoying as hell. So I would object against
implementing such a scheme.
to be honest I can't see what is elegant with collecting SMTP Auth
credentials. I don't want to collect such credentials (and users should not
encouraged in handing out credentials to third partys).

The whole DMARC thing is a nightmare for every mailinglist.

unsatisfied

Alex

Hi,

DMARC is so obviously broken in this regard.  I tried but couldn't find
anyone with influence on the DMARC working group who cared about this
issue.  It was 'outside of scope' or something.

I think Debian and other communities should really use their influence
here;  simply go with option 1 (the easiest) and encourage users to
register another email account elsewhere to use the lists.  Some people
do that anyway for list email to avoid spam or as an alternative to
filtering into separate mailboxes.

Besides, we've heard plenty of other reasons recently why users should
be looking to avoid certain email services, or to consider setting up
their own.  And I suppose it's never been easier;  there is good
software for this, many excellent tutorials now, and a wave of cheap
low-powered devices that could run email services on a home broadband
connection unobtrusively, for yourself and friends/family.

Or maybe this would pressure a few providers to forget about using
p=reject, or the DMARC standard to finally address this problem, any of
which would still be forward progress.

Thanks,
Regards,

Would you mind pointing to the mails in the archives of the DMARC IETF
group where this was proposed? Want to try to address this if at all
possible, but don't want to re-hash things which have been addressed.

Marco d'Itri, 2014-06-19 16:10+0200:

d) set up lists so DKIM-signed messages are not modified in any way
Mailing lists break SPF and solutions to that are heavy, but DMARC
relies on /either/ SPF /or/ DKIM, and mailing-lists do not necessarily
break DKIM: they only do when the message is altered, often to add a
footer explaining how to unsubscribe. Now, there has been a standard
mail header for that for some time, which should now be recognized by
all serious mail user agents, so altering messages to add such a footer
could be avoided now, at least for DKIM-signed messages.

This has nothing to do with DKIM. d) is not a solution for our problem.

If a user from a p=reject domain posts to our mailinglist, every subscriber
from a domain checking dmarc will get a bounce.

Alex

what in detail means unmodified? body? headers?

Does that mean if we only add some headers and let everything as it is, we
will be fine?

Alex

The body and the DKIM-signed headers. E.g. gmail by default signs:

h=mime-version:date:message-id:subject:from:to:content-type

and Yahoo:

h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type
Yes.

Ok, that seams possible.
Received? That probably means we cann add new received headers without
modifying the existing ones.
Good to know. I think THAT is a solution we are able to manage for most
mailinglists (except for things like *-announce where reply-to headers get
changed).

Alex

No, it means that you cannot modify the Received headers earlier than
the DKIM header (or the signature would never be valid after the first
hop).
I am not attached to it at all (MIME signatures hide it anyway...), but
currently all of our mailing lists have a footer.

Which - in practise - should be the same.
That is something I can change for DKIM signed mails, and that is something I
am willing to change. Information about unsubscribing is also in the header.

So, do you think too that we have a way to go here?
That means:

- don't add the footer for DKIM signed mails
- add DKIM on our own for outgoing mails to improve our own reputation

Alex

Yes (but these are unrelated goals).
But I think that it would be better to always add or not add the footer.

indeed, but the discussions are a little bit related, so I posted the summary
here.
I see the footer as a service to our users and I would like to keep it as
long as possible.

Alex

If it is viable and not too difficult to do this, then I'd ask the
listmasters to please consider it as a last resort to excluding users of
p=reject domains.

Fortunately the main lists.d.o do not rewrite the subject, which would
have been the most inconvenient change to make.  Still awkward for the
BTS and alioth lists.

I guess some of the added list headers might need to be moved to precede
instead of follow existing headers?

The footer is something I could personally live without.  The rare
message doesn't include the footer anyway (HTML?), so I'm used to
getting its Message-ID from the headers.  The unsubscribe instructions
in the footer are still not always followed.

And doesn't the footer already negatively affect PGP/MIME or inline PGP
signatures?  I think it causes signed mails to become only 'partially
signed'?

Regards,

See <20140620101537.GD7799@lisa.snow-crash.org> for my proposed plan.

Alex

Right, I forgot that this is relevant for the BTS as well since it
rewrites Subject and Reply-To.
Only if there are multiple headers IIRC, so it should not matter.
In mutt the footer is just hidden for signed messages.

thread, except *without* the Wiki debate position pages, so everything
went around in circles.

Since then I got the impression 10% of threads on dmarc-discuss@ were
reprising the same issue.

Mine was this thread, but below are some highlights:
http://lists.dmarc.org/pipermail/dmarc-discuss/2012-June/000945.html

Ironically, this was from zwicky at yahoo-inc.com :

msk at fb.com wrote:

I answered that and proposed there be some 'p=reject, but please accept
my mail if forwarded' policy:
http://lists.dmarc.org/pipermail/dmarc-discuss/2012-June/001045.html

It would be enough if the published DMARC record could optionally turn
off the 'alignment' requirement;  accept a DKIM signature from a
listserver in lieu of a valid author signature.  A further whitelist
lookup or reputation scoring by the sender could then decide if it was
valid list mail or not.

Then it would work as DKIM and ADSP do already (and DomainKeys did);  if
a list adds a Sender: header it could do DKIM signing without too much
effort, then DKIM validators would still pass it.

Regards,

I already proposed this as a simple and effective solution in another
bug report against lists.debian.org and Don Armstrong already seemed
to be willing to stop the footer for any type of signed email.

(Personally, I also think that doing that would be ugly and it would
be much better to drop the footer for all email).

Please do not reject this possibility so lightly. From all the
proposed solutions to this problem, I don't think this one is a
solution to laught at.

With great sadness I read from Alexander Wirt blog that you are
planning to (basically) boycott lists.debian.org usage for any user
whose email provider has a p=reject dmark policy.

But, if I'm not mistaken, everything we would need to support such
users in most cases (I'm not talking about bugs.debian.org here) is to
stop adding footers to our messages.

Alexander, the footer may be "useful" and "a service to our users",
but IMHO in no way it is reasonable to consider the footer so much
important that we have to forbid or boycott lists.debian.org usage for
a lot of already existing users.

Thanks.

read the bugreport again. at all.


Alex

El 20/06/14 22:19, Alexander Wirt escribió:

Hmm. What makes you think I didn't?

Maybe you refer to the fact that your blog entry is dated from yesterday
and solutions for this problem which are acceptable for you have been
proposed in the bug report after that? (If that's the case, I celebrate).

Thanks.

exactly.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752084#65

Alex

El 20/06/14 22:37, Alexander Wirt escribió:

While we are at it: Please consider moving the Archive: information in
the footer to the headers in either case (i.e. regardless of the message
being DKIM signed or not).

I've already seen cases where the message-id (and therefore the URL
shown) contains the equal sign (=) and the message is MIME invalid
because the header declares the body as being quoted-pritable. This
makes the = sign in the body not to be interpreted as an = sign.

You can't, not completely anyway.  The lookup key for the DNS record is the
body From.  The sender exposed in the Postfix policy interface is the envelope
From (Mail From).  In most cases for a submission to a list, they will be the
same, but it's not a 100% solution.

It should not be too hard to us a milter to do this.  I doesn't need all the
functionality of opendmarc, it just has to pull out the body from, do a DNS
lookup and then then reject if there is a p=reject DMARC record.

I've been peripherally involved in DMARC development (which is why I packaged
opendmarc).  Up until Yahoo and AOL went insane, the idea was that DMARC was
mostly for corporate transactional mail and the mailing list issue wouldn't
come up.

Scott K

indeed, then a milter, but thats not a problem, I did milters in perl before.

Alex

clone 752084 -1
reassign -1 bugs.debian.org
retitle -1 The Debian BTS needs a plan to deal with messages from DMARC p=reject domains
thanks

Please see #752084 for the details.

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.

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.

It's more complicated than that.  See my analysis below.
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: <debbugs@buxtehude.debian.org>
From: Mika =?UTF-8?Q?Pfl=C3=BCger?= <debian@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

It is always the receivers' call, but enough receivers implement DMARC
that we as senders will have to deal with it no matter what our opinions
are on its merit.
Agreed, but implementing ARC would still be a better solution.
I expect that next spring it will be more clear how much work this will
require.

Dear Customer,



Your item has arrived at the UPS Post Office at March 07, but the courier was unable to deliver parcel to you.



Please review delivery label in attachment!



Thanks,

Ray Horn,

UPS Delivery Clerk.

Dear Customer,



Your parcel was successfully delivered May 16 to UPS Station, but our courier cound not contact you.



Please check the attachment for details!



Thanks and best regards,

 ,

UPS Support Manager.

Has this issue ever has been dealt with for bugs.debian.org (as it
seems to have been solved for lists.debian.org in forked #752084) ?

Because I still have breakage when I submit mail to bugs.debian.org
and I get failure notices from other hosts as noted in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830865#45

(note: my DKIM validates elsewhere, and I do not have any other issues
with it except on bugs.debian.org mails). Forensic headers (requested
in DMARC with fo=1) seems to indicate DKIM breaks along the way near
bendel.debian.org, for example:

Authentication-Results: mail.susi-moog.de;
        dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=voyager.hr header.i=@voyager.hr header.b="EVrAhWxo";
        dkim-atps=neutral
Authentication-Results: mail.susi-moog.de; spf=none (mailfrom) smtp.mailfrom=lists.debian.org (client-ip=82.195.75.100; helo=bendel.debian.org; envelope-from=bounce-debian-bugs-rc=andreas.moog=warperbbs.de@lists.debian.org; receiver=<UNKNOWN>)
Received: from localhost (localhost [127.0.0.1])
        by bendel.debian.org (Postfix) with QMQP
        id ABCCC20BAE; Wed,  6 Mar 2019 03:15:08 +0000 (UTC)
X-Mailbox-Line: From debian-bugs-rc-request@lists.debian.org  Wed Mar  6 03:15:08 2019
Old-Return-Path: <debbugs@buxtehude.debian.org>
X-Original-To: lists-debian-bugs-rc@bendel.debian.org
Delivered-To: lists-debian-bugs-rc@bendel.debian.org
Received: from localhost (localhost [127.0.0.1])
        by bendel.debian.org (Postfix) with ESMTP id 9CF7820BA9
        for <lists-debian-bugs-rc@bendel.debian.org>; Wed,  6 Mar 2019 03:15:08 +0000 (UTC)
X-Virus-Scanned: at lists.debian.org with policy bank bug
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-10000 required=5.3
        tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
        HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3]
        autolearn=unavailable autolearn_force=no
Received: from bendel.debian.org ([127.0.0.1])
        by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)
        with ESMTP id r-35XNxN_7Md
        for <lists-debian-bugs-rc@bendel.debian.org>;
        Wed,  6 Mar 2019 03:15:06 +0000 (UTC)
Received: from buxtehude.debian.org (buxtehude.debian.org [IPv6:2607:f8f0:614:1::1274:39])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (Client CN "buxtehude.debian.org", Issuer "Debian SMTP CA" (not verified))
        by bendel.debian.org (Postfix) with ESMTPS id 78D1B20BA4;
        Wed,  6 Mar 2019 03:15:06 +0000 (UTC)
Received: from debbugs by buxtehude.debian.org with local (Exim 4.89)
        (envelope-from <debbugs@buxtehude.debian.org>)
        id 1h1N1L-0008UD-2y; Wed, 06 Mar 2019 03:15:03 +0000
X-Loop: owner@bugs.debian.org


I can provide whole forensic report if required, or do tests.

No: it is obvious that the messages relayed by the BTS are still
modified.
The problem is quite clear, but the is no commitment from the BTS
maintainers to choose a solution and maybe implement it.

Right; the only way forward for this is to completely stop rewriting the
subject of messages sent to submit@ or nnn@ or implement resending.

I don't have time to implement either in the near term.

My current longer term plan is to switch to resending messages and
rewriting From.

This bug, first opened almost 7 years ago, originally concerned the fast
that emails sent through lists.dmarc.org were violating DMARC, causing
bounces, and in general causing mayhem for domains with p=reject DMARC
policies and users whose mail providers enforce DMARC.

Since then it appears that lists.dmarc.org was fixed, bug
bugs.debian.org is still broken. I reported a couple of bugs to
bugs.debian.org recently for the first time in a while, and I see from
my incoming DMARC aggregate reports that I've received hundreds of
notifications about invalid notification emails sent as a result by
bugs.debian.org.

My domain has a p=reject DMARC policy, which means that users whose
email providers enforce DMARC (pretty much all the major email providers
nowadays) simply aren't going to see the emails about the bugs I report.
This is going to be true for a lot of people, and it significantly
hampers the effectiveness of the bug-tracking system.

I don't even know if the maintainers of the packages I report bugs about
see my bugs. They may have no idea they were filed, because their email
providers bounced the notifications or put them into their Spam folders.

The last activity recorded for this bug was nearly two years ago.

FYI Ubuntu fixed this issue in Launchpad something like a year ago.

It sure would be nice if Debian fixed it.

  jik

Same observation here:
DMARC aggregate reports notifies me that emails sends to the BTS
are not delivered to the final recipient.

I should not be surprised anymore if bugreports are left un-answered,
maintainers are simply not getting notification...

Since the last comment of this bug, 4 months have passed and no
reaction.
I suspect that nobody recieved the last email, and my guts tell me
that i'm writing to /dev/null rigth now :(

Without a working BTS, i'm wondering :
Is the project still interested by users' feedback ?

Hi all,

some more time has passed, and in the meanwhile an informational IETF
draft has been published which discusses the various mitigations to this
issue. You can find it here:
<https://www.ietf.org/archive/id/draft-levine-dmarc-listugh-01.html>

It does not contain any magical solution, but might be a good starting
point for someone wanting to figure out what is happening and eventually
working on a fix.

Bye!

P.S. my email domain has a DMARC p=reject policy

Hi,

I have recently updated much of my email server setup, including DKIM
signing and validation, and publishing DMARC records. Since I changed
the DMARC policy away from p=none (as that it is supposed to be only for
testing purposes), I started getting reports each time I send an email
to the BTS.

I came across this bug, that has been open for 11 years, and it seems
that nothing has changed. This email will probably not reach some of the
bug subscribers due to that problem.

Do we need to all change/downgrade our email setups, or is there a plan
to address this at some point?

This is not really correct... A restrictive DMARC policy should be used
if a domain is subject to spoofing (e.g. because it is a phishing
target). But p=none is a totally valid configuration.

Isn't any domain potentially subject to spoofing and phishing? One
shouldn't use strong passwords only if targeted by criminals :)

Bye!

Potentially, obviously yes.
But experience shows that it is an actual problem only for a tiny number
of domains.

On Sat, 17 May 2025, Martina Ferrari wrote:n

Addressing it requires having the BTS resend all messages from its own
addresses since the BTS has to rewrite parts of the mail in order to
function. That's a pretty big architectural change which I've been
working on very, very, slowly.

So you're better off not using DKIM until that's fixed.