0

For my own domain (mydomain.com, hosted with a free G Suite), I have setup DMARC in testing mode:

v=DMARC1; p=none; sp=reject; aspf=s; adkim=s; rua=mailto:dmarc@mydomain.com

I have sent out test emails to a bunch of email addresses to get an idea whether this is working OK or not, including my personal Gmail account and two work place email addresses (workplace.com and otherworkplace.com) that use Exchange/Outlook/OWA which I redirect to my personal Gmail account.

DMARC validates for all except one of two workplace addresses, but only after forwarding to my personal Gmail account. Meaning, this is how the headers looks when it's received at my work place (line breaks changed by me):

Authentication-Results: mx-ext2.workplace.com (amavisd-new);
    dkim=pass (2048-bit key) header.d=mydomain.com
...
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.5.16
    (mx-ext2.workplace.com [IP]); Mon, 22 Jan 2018 21:59:22 +0100 (CET)

When that same mail arrives at Gmail, this is the authentication result instead:

ARC-Authentication-Results: i=1; mx.google.com;
   dkim=neutral (body hash did not verify) header.i=@mydomain.com
       header.s=google header.b=PbtXBzel;
   spf=pass (google.com: domain of myname@workplace.com designates WorkPlaceIP as
       permitted sender) smtp.mailfrom=myname@workplace.com;
   dmarc=fail (p=NONE sp=REJECT dis=NONE) header.from=mydomain.com
...
Received-SPF: pass (google.com: domain of myname@workplace.com designates
    WorkPlaceIP as permitted sender) client-ip=WorkPlaceIP;
Authentication-Results: mx.google.com;
   dkim=neutral (body hash did not verify) header.i=@mydomain.com
       header.s=google header.b=PbtXBzel;
   spf=pass (google.com: domain of myname@workplace.com designates WorkPlaceIP as 
       permitted sender) smtp.mailfrom=myname@workplace.com;
   dmarc=fail (p=NONE sp=REJECT dis=NONE) header.from=mydomain.com

Note body hash did not verify and dmarc=fail.

The email body is empty, except for some HTML tags. As received by Gmail directly:

Content-Type: multipart/alternative; boundary="94eb2c0d242e6d935c056363b612"

--94eb2c0d242e6d935c056363b612
Content-Type: text/plain; charset="UTF-8"



--94eb2c0d242e6d935c056363b612
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><br></div>

--94eb2c0d242e6d935c056363b612--

As received by Gmail through another workplace email:

Content-Type: multipart/alternative; boundary="f403045f58c6ca3863056363b147"
X-MS-Exchange-Inbox-Rules-Loop: myname@otherworkplace.com

--f403045f58c6ca3863056363b147
Content-Type: text/plain; charset="UTF-8"



--f403045f58c6ca3863056363b147
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><br></div>

--f403045f58c6ca3863056363b147--

As received by Gmail through that non-working workplace email:

Content-Type: multipart/alternative;
    boundary="_000_3b36ca239c7e4763redacted_"
MIME-Version: 1.0

--_000_3b36ca239c7e4763redacted_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



--_000_3b36ca239c7e4763redacted_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <37000954F9D6364E955236140257787E@ad.workplace.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
</head>
<body>
<div dir=3D"ltr"><br>
</div>
</body>
</html>

--_000_3b36ca239c7e4763redacted_--

So workplace.com is changing not only the charset, which should not be a big deal due to normalization before computation of the DKIM signature; but also the body by introducing extra HTML tags into the attachments. otherworkplace.com does not seem to be doing that.

workplace.com seems to be using OWA 2013 (and thus Exchange Server 2013), while otherworkplace.com seems to be using a newer version, judging from the UI.

My takeaway is that

  • I could ask my own workplace IT people to look at what their Exchange server may be doing (and maybe have them stop it), but
  • I cannot control all Exchange servers in the world, and having one do something like this in my very small sample makes this a likely problem to hit in other places, as soon as people forward email from the Exchange/OWA email address.

So how should I re-configure my DMARC settings for maximum security while maintaining reasonably high compatibility?

bers
  • 200
  • 1
  • 9

1 Answers1

1

TL;DR: This is not a problem of an insecure DMARC configuration. The DMARC fail you see is due to a broken DKIM signature. The DKIM signature got broken due to one mail server in the path not supporting 8BITMIME. Fix is to make sure that you have an ASCII-only mail before applying the DKIM signature on your server. I've described the problem in more detail in Breaking DKIM by Chance.

DMARC passes if either SPF or DKIM passes. Passing means for SPF in the context of DMARC that the the source IP address is the expected one and that the sender according to the SMTP envelope matches the sender according to the Rfc822 envelope (i.e. From header in the mail). For DKIM passing means that the DKIM signature is correct and that the domain in the DKIM signature matches the domain of the From header in the mail.

If you send the mails directly from your domain then SPF will pass and thus the result of DKIM does not matter. If instead you redirect the mail through another server then SPF will no longer pass and the DMARC result depends on DKIM only.

The DKIM signature includes a hash over the body of the mail. This hash is created from the source code of the body as seen by the signing server. Any changes to the body during transport will thus invalidate the signature.

Unfortunately, such changes can happen if one mail server supports 8 bit input (8BITMIME SMTP extension) but the next hop mail server doesn't support it. In this case any 8 bit data in the body need to be recoded so that the body is ASCII only. And this is what happens in your case: one mail server on the path does not support 8BITMIME and thus the sending mail server will recode the mail with Content-Transfer-Encoding: quoted-printable. But, this breaks existing DKIM signatures and thus DKIM will fail.

Since you usually cannot control which path your mail takes through the internet and if all mail servers in the path support 8BITMIME you should make sure that the mail is already ASCII-only before the DKIM signature gets created. Only this way you can make sure that no breaking of the DKIM signature due to recoding happens later. The easiest way to do this might be to configure your own mail server to not accept 8BITMIME and thus force any sender to recode the mail to ASCII-only before it gets submitted to your server. For the postfix mail server the relevant option is the smtputf8_enable parameter.

For more information see Breaking DKIM by Chance where I describe this problem in more detail.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thank you, although it took me a while to go through this answer. I do not doubt that your explanation is correct. My "problem" (I am not sure it is an actual problem, but let's call it that) is that I use G Suite to host my domain, and I use their email servers, too. So I do not see that I have an actual influence on how the DKIM signature is created, as my users may be using any kind of email client (in the example above, this is just the Gmail web client). – bers Feb 25 '18 at 20:12
  • Are you aware of any solution that applies in this case? Have I missed anything in the admin dashboard? Should I just mimic gmail.com's [DMARC settings](https://mxtoolbox.com/SuperTool.aspx?action=dmarc%3agmail.com), which is `p=none`? Should I take Google's setting as an indication that I should not try anything stricter than that (which is basically, nothing)? – bers Feb 25 '18 at 20:12
  • 1
    @bers: again - this is NOT a problem of the DMARC policy and you cannot fix it by changing the policy. It is a problem that the server which creates the DKIM signature accepts 8BITMIME and does not convert the mail to plain ASCII before applying the signature. If you have no way to change the behavior of this server contact the support of the mail provider which is responsible for the server and explain the problem. – Steffen Ullrich Feb 26 '18 at 04:37
  • Alright, I get it :) I take this as "if Google does not have a solution to use DMARC on their servers, I certainly won't, either". Thanks! – bers Feb 26 '18 at 07:07
  • 1
    @bers: you've almost got it. Only that the problem is not directly DMARC but DKIM - which is then used as part of the DMARC verification later. And, while the incoming server (i.e. your domain hosted by Google) creates a proper DKIM signature it fails to convert the mail to pure ASCII before applying the signature. This way a later conversion of the mail to pure ASCII will make the signature invalid. Note that the DKIM standard explicitly points out that the server should convert the mail to pure ASCII before applying the signature, only few care what the standard says. – Steffen Ullrich Feb 26 '18 at 07:13
  • I agree. You are almost certainly talking about [section 5.3 of RFC 6376](https://tools.ietf.org/html/rfc6376#section-5.3): as you rightly said, this one says "SHOULD", so there is no hard blame to give to Google, unfortunately. – bers Feb 26 '18 at 07:22
  • 1
    @bers: while this part of converting the message says only SHOULD a few lines later it says *"More generally, the Signer __MUST__ sign the message __as it is expected to be received by the Verifier__ rather than in some local or internal form."*. Thus, unless Google can control that no conversion to ASCII happens on the path to the recipient (i.e. all MTA do 8BITMIME) they MUST convert the message so that the signed message is the same one as the recipient verifies. – Steffen Ullrich Feb 26 '18 at 07:36