Gmail rejects forwarded mail with DMARC but I AM using SRS

Question

I'm forwarding mail from my domain leif@example.org to leifex@gmail.com.

I have followed this: Why is Google rejecting mails forwarded from my Postfix server?

Install pfix-srs.

Create an spf record for my mail servers domain, allowing my ip4 and ip6 to send.

(E.g. v=spf1 ip4:1.1.1.1 ip6:abcd:abc:123:4567::8 ~all)

Create an rdns entry for my mail severs domain, pointing to its IP.

My difference is I'm using postsrsd instead of pfix-srs and I'm using the domainname of my server instead of listing the ipv4 and ipv6 addresses. I have rdns to both ipv4 and ipv6.

gmail rejects the mail with 550-5.7.1 Unauthenticated email from netflix.com is not accepted due to domain's 550-5.7.1 DMARC policy.

It is as if gmail is not looking at the SRS-rewritten addresses, according to the logs the addresses DO get rewritten. What am I missing?

I am using MailScanner, so the message ids in the log gets changed in the way from received to sent.

Jan 17 22:09:10 mail postfix/smtpd[9438]: connect from a41-48.smtp-out.amazonses.com[54.240.41.48]
Jan 17 22:09:11 mail postfix/smtpd[9438]: 3396B328CF: client=a41-48.smtp-out.amazonses.com[54.240.41.48]
Jan 17 22:09:11 mail postsrsd[9443]: srs_forward: <010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@mailer.netflix.com> rewritten as
                  <SRS0=YrTC=PZ=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>
Jan 17 22:09:11 mail postfix/cleanup[9442]: 3396B328CF: hold: header 
Received: from a41-48.smtp-out.amazonses.com (a41-48.smtp-out.amazonses.com [54.240.41.48])??
    by mail.example.org (Postfix) with ESMTPS id 3396B328CF??for <leif@example.org>; Thu, 17 Jan 2019 22:09:11 +0100
    from a41-48.smtp-out.amazonses.com[54.240.41.48];
    from=<srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>
    to=<leif@example.org> proto=ESMTP helo=<a41-48.smtp-out.amazonses.com>
Jan 17 22:09:11 mail postfix/cleanup[9442]: 3396B328CF: message-id=<010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@email.amazonses.com>
Jan 17 22:09:11 mail opendkim[812]: 3396B328CF: a41-48.smtp-out.amazonses.com [54.240.41.48] not internal
Jan 17 22:09:11 mail opendkim[812]: 3396B328CF: not authenticated
Jan 17 22:09:12 mail opendkim[812]: 3396B328CF: message has signatures from netflix.com, amazonses.com
Jan 17 22:09:12 mail opendkim[812]: 3396B328CF: signature=c9tTKm4w domain=netflix.com selector=emotixlbezkp6gpvmko5lunmgwd5syff result="no signature error";
    signature=VmSNlFSx domain=amazonses.com selector=ug7nbtf4gccmlpwj322ax3p6ow6yfsug result="no signature error"
Jan 17 22:09:12 mail opendkim[812]: 3396B328CF: DKIM verification successful
Jan 17 22:09:12 mail opendkim[812]: 3396B328CF: s=emotixlbezkp6gpvmko5lunmgwd5syff d=netflix.com SSL
Jan 17 22:09:13 mail MailScanner[31292]: Requeue: 3396B328CF.A0D92 to C662E32963
Jan 17 22:09:13 mail postfix/qmgr[9218]: C662E32963: from=<srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>,
    size=89685, nrcpt=1 (queue active)
Jan 17 22:09:13 mail MailScanner[31292]: Uninfected: Delivered 1 messages
Jan 17 22:09:13 mail MailScanner[31292]: Deleted 1 messages from processing-database
Jan 17 22:09:13 mail postfix/qmgr[9218]: 97B26328CF: from=<srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>,
    size=90760, nrcpt=1 (queue active)
Jan 17 22:09:13 mail postfix/smtp[9497]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c02::1b]:25:
    TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
Jan 17 22:09:14 mail postfix/smtp[9497]: 97B26328CF: to=<leifex@gmail.com>, orig_to=<leif@example.org>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c02::1b]:25,
    delay=0.5, delays=0.01/0/0.26/0.23, dsn=5.7.1, status=bounced
    (host gmail-smtp-in.l.google.com[2a00:1450:400c:c02::1b] said:
            550-5.7.1 Unauthenticated email from netflix.com is not accepted due to domain's
            550-5.7.1 DMARC policy. Please contact the administrator of netflix.com domain
            550-5.7.1 if this was a legitimate mail. Please visit
            550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about the
            550 5.7.1 DMARC initiative. j17si56462544wri.283 - gsmtp (in reply to end of DATA command))
Jan 17 22:09:14 mail postsrsd[9443]: srs_forward: <""> not rewritten: No at sign in sender address
Jan 17 22:09:14 mail postsrsd[9444]: 
 srs_reverse: <srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>
                                 rewritten as <010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@mailer.netflix.com>
Jan 17 22:09:14 mail postsrsd[9444]: srs_reverse:
  <srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>
                     rewritten as <010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@mailer.netflix.com>
Jan 17 22:09:14 mail postfix/cleanup[9442]: 20BA932965: message-id=<20190117210914.20BA932965@mail.example.org>
Jan 17 22:09:14 mail postfix/bounce[9596]: 97B26328CF: sender non-delivery notification: 20BA932965
Jan 17 22:09:14 mail postfix/qmgr[9218]: 20BA932965: from=<>, size=6444, nrcpt=1 (queue active)
Jan 17 22:09:14 mail postfix/qmgr[9218]: 97B26328CF: removed
Jan 17 22:09:14 mail postfix/smtp[9497]: Trusted TLS connection established to feedback-smtp.us-east-1.amazonses.com[72.21.206.91]:25:
     TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan 17 22:09:15 mail postfix/smtp[9497]: 20BA932965: to=<010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@mailer.netflix.com>,
                orig_to=<srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>,
    relay=feedback-smtp.us-east-1.amazonses.com[72.21.206.91]:25, delay=1.4, delays=0.01/0/0.93/0.5, dsn=2.0.0, status=sent (250 Ok XCS73MIlZ28B7iH7tzWF-1)
Jan 17 22:09:15 mail postfix/qmgr[9218]: 20BA932965: removed
Jan 17 22:09:34 mail postfix/smtpd[9438]: disconnect from a41-48.smtp-out.amazonses.com[54.240.41.48] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

score 3 · Answer 1 · answered Jul 12 '22 at 07:54

I forward my own domain's email to Gmail accounts, too, and OpenDKIM + OpenARC alone won't suffice for this setup. You will need DKIM + ARC + SRS ("Sender Rewriting Scheme") to make this work. This is well explained here: https://forum.howtoforge.com/threads/postfix-rspamd-do-not-dkim-sign-forwarded-messages-solved.87742/

Furthermore, OpenARC is not being maintained, so I went for a combination of Rspamd (handles DKIM and ARC) + postsrsd (for SRS) which were easily deployed on my Ubuntu 18.04 (bionic) box.

Rspamd installation:

wget -O- https://rspamd.com/apt-stable/gpg.key | sudo apt-key add -
echo "deb http://rspamd.com/apt-stable/ $(lsb_release -cs) main" | sudo tee -a /etc/apt/sources.list.d/rspamd.list
sudo apt update
sudo apt install rspamd

Rspamd configuration:

sudo -u _rspamd rspamadm configwizard

and then just answer the questions as in the "Configure Rspamd" section of https://pieterhollander.nl/post/mailserver/ . This will properly configure DKIM signing. Take note of the public keys that you will have to publish as DNS records (one for each of your domains), and then update your DNSs accordingly.

As for ARC, just copy the domain {..} section of /etc/rspamd/local.d/dkim_signing.conf into /etc/rspamd/local.d/arc.conf .

Make postfix use Rspamd:

Add these to your /etc/postfix/main.cf file (as in the "Configure Postfix" section of https://linuxize.com/post/install-and-integrate-rspamd/):

milter_protocol = 6
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_default_action = accept
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = inet:127.0.0.1:11332

Next, just restart the rspamd and postfix daemons.

postsrsd installation:

sudo apt install postsrsd

postsrsd configuration:

Usually the default configuration will be fine. Just make sure that SRS_DOMAIN in /etc/default/postsrsd is one of your domains (even if you manage email for multiple domains, you can just use one of them for SRS as discussed here).

Make postfix use postsrsd:

Add these to your /etc/postfix/main.cf file (as in https://github.com/roehling/postsrsd ):

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes= envelope_recipient,header_recipient

Restart postfix (and postsrsd if needed), and everything should now work.

Test the setup by sending an email from a Gmail account to one of your domains' accounts. This should be forwarded (SRS-ed and ARC-signed) to the corresponding Gmail account. Once you receive it, open it in Gmail and select "show original". If your setup is correct and your SPF, DKIM and DMARC DNS records are correctly set, you should see "PASS" for all of SPF, DKIM and DMARC. Otherwise, there will be FAIL or SOFTFAIL.

If you need to debug Rspamd, you may create a /etc/rspamd/override.d/logging.inc file with this content:

debug_modules = ["dkim_signing","arc"];

Restart rspamd and monitor the logs at /var/log/rspamd/rspamd.log

user117197 · Answer 2 · 2019-11-29T08:00:34.730

SRS assists by allowing you to rewrite the To: address and appends a Mail From: header, but does not change the original From:

In your example above, when the message arrives at Google's servers, they see the original From: in the message, and process DMARC, SPF, and DKIM according to the policy of the domain name used in the from address. This would most likely violate the origin domain name's SPF and or DMARC policy, and therefore cause Google's Gmail to reject the message.

The solution is to implement Authenticated Received Chain (ARC), RFC 8617.

ARC helps solve this problem by giving intermediate servers a way to sign the original message's validation results. Even if the SPF and DKIM validation fail, the receiving service can choose to validate the ARC. If the ARC indicates that the original message passed the SPF and DKIM checks, and the only modifications were made by intermediaries trusted by the receiving service, the receiving service may choose to accept the email.

You can use the milter OpenARC for sendmail and postfix MTAs to sign emails with ARC before relaying them. This gives the receiving mail server a way to verify that your relaying server confirmed the results of SPF and DKIM before relaying the message forward. Now the receiving mail server can verify the ARC signature that your relaying server added, and then take any action depending on its configuration.

Ultimately one has no control over the 3rd party receiving mail server. All we can do is attempt to make our email as trustworthy as possible. By adding valid ARC headers, we can at least give the receiving mail server another datapoint to prove the legitimacy of the messages, yet it is still no absolute guarantee that the message will be accepted, delivered, and not marked as spam.

The solution is to implement ARC. I've edited my response above to include information on what ARC is and how it can help. — user117197, Nov 29 '19 at 08:02

Gmail rejects forwarded mail with DMARC but I AM using SRS

2 Answers2