docker-mailserver: Problem with strict DMARC policies

I am struggling with a problem resulting from a mixture of strict DMARC policies and a forwarding scheme. I found this reddit (without a proper solution) from a guy who runs exactly the same setup than I do. I hope it is okay to just post the link here.

https://www.reddit.com/r/email/comments/6ivppl/forwarding_emails_and_dkimspfdmarc_whats_correct/

My question is, if there might be a solution for this. At the moment, I completely lose this emails and do not get any notification that this happens. The only way to figure out about this is the log file which I do not regularly check.

mail              | Dec 28 14:55:21 mx0 postfix/smtp[2064862]: CDD1762E74: to=<mandraxx@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.71.27]:25, delay=1.1, delays=0.04/0.01/0.34/0.74, dsn=5.7.26, status=bounced (host gmail-smtp-in.l.google.com[74.125.71.27] said: 550-5.7.26 Unauthenticated email from dhl.com is not accepted due to domain's 550-5.7.26 DMARC policy. Please contact the administrator of dhl.com domain if 550-5.7.26 this was a legitimate mail. Please visit 550-5.7.26  https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.26 DMARC initiative. x17si33555950wrr.148 - gsmtp (in reply to end of DATA command))

I think, there might be different possible solutions:

Implement ARC (http://arc-spec.org/). Do we already support this with docker-mailserver? I am not even sure if that would help, but I am willing to give it a try.
forward the emails in a way, so that Gmail accepts them. (Can we automatically check the senders DMARC policy and rewrite the From header for those emails? I really do not want to rewrite every single from header and lose the senders information.
Notify me in case gmail rejects and mail because of strict DMARC policies.

Any other thoughts are welcome. 😃

Cheers Lukas

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 1
Comments: 32 (31 by maintainers)

Most upvoted comments

@fbartels master/latest, stable and the versioned images already exist, they are what we have now.

We could certainly name the buster branch “next” or something like that. Then the branch can live on when we merge it back to master as well and represent the next major release.

I intended to cherry-pick changes from experimental (and @mindrunner it does not exist yet), but yes it will get a bit messy. We could have an arc branch that is basically the master branch but with arc. That will also get messy if other features are introduced. We don’t want too many branches.

Perhaps it is best to try to get it into master quickly after all. A deb package is one option, a multi-stage build also works. The key to that is to ensure that it doesn’t affect the stability of the image in any way for people who don’t use it. If we use a deb package I would prefer to build it in a docker container from the make file rather than adding it as a binary file built elsewhere. It could be an optional step (reuse deb file from last build if it exists, build it if missing) to keep the normal builds fast. Then we will always get the latest code when we build for real.

erik-wramner on Jan 5, 2020

Sorry to bother this late, is there any maintained implementation as of now?

Please do open a new issue; we do not revive dead issues 😄

A strict SPF policy would block out too many useful emails. All of the emails I had found wrongly blocked had a ARC header, so right now I had loosen DMARC policies to avoid losing too many useful forwarded emails as a temporary measure. Could ARC solve this issue?

Haven’t looked into ARC and whether it could be useful here. DMARC should not actually fail though, I rarely see emails fail DMARC.

georglauterbach on Feb 7, 2023

I get it. First of all: Thank you for investigating in this. Contribution is always nice to see. We’ll leave the arc branch open. Maybe someone in the future is interested.

Currently there seems to be no interest however and there are a lot of other things going on related to master (looking at you, #1605). Therefore, I’ll close this and mark it as frozen. If you or anyone else feels like re-opening this issue because of some reason, feel free to do so.

georglauterbach on Sep 13, 2020

Seems like it is working:

ARC-Seal: i=1; a=rsa-sha256; d=domain.com; s=201808; t=1578189874; cv=none; b=[.......]
ARC-Message-Signature: i=1; a=rsa-sha256; d=domain.com; s=201808; t=1578189874; c=relaxed/simple; bh=[...]; h=Received-SPF:MIME-Version:Message-ID:Date:From:To:Subject:
	 Content-Type:Content-Transfer-Encoding; b=[.......]
ARC-Authentication-Results: i=1; mx0.domain.com; arc=none

mindrunner on Jan 5, 2020