Weird (to me) dmarc report from google

Networking Networking Software
1

My work email is public since it’s thoughtfully published by the Nevada/Louisiana bar associations, and judging by the amount of spam I get, frequently scraped. So my email domain has a “strict” dmarc policy that rejects spf and dkim failures. My spf only authorizes mail from the host pointed to by my mx record, and all emails from my host are signed by my dkim key.

Consequently, my domain’s postmaster account gets daily dmarc reports from google and others. But the reports have always been spf and dkim pass -> take no action (legit mail) or spf and dkim fail -> reject (probably a spammer masquerading as me).

About a week ago, I got a report from google that was spf fail, dkim pass. In 5 years of hosting my own email, I have not run into this situation.

dmarc report 
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
      <report_metadata>
            <org_name>google.com</org_name>
            <email>[email protected]</email>
            <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
            <report_id>1881472039149147891</report_id>
            <date_range>
                 <begin>1553817600</begin>
                 <end>1553903999</end>
            </date_range>
      </report_metadata>
      <policy_published>
        <domain>cliffordburnslaw.com</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>reject</p>
        <sp>reject</sp>
        <pct>100</pct>
      </policy_published>
      <record>
        <row>
          <source_ip>68.99.120.37</source_ip>
          <count>1</count>
          <policy_evaluated>
            <disposition>none</disposition>
            <dkim>pass</dkim>
            <spf>fail</spf>
          </policy_evaluated>
        </row>
        <identifiers>
          <header_from>cliffordburnslaw.com</header_from>
        </identifiers>
        <auth_results>
        <dkim>
            <domain>cliffordburnslaw.com</domain>
            <result>pass</result>
            <selector>201808</selector>
          </dkim>
          <spf>
            <domain>cliffordburnslaw.com</domain>
            <result>fail</result>
          </spf>
        </auth_results>
      </record>
</feedback>

The address of the host sending the mail to google was 68.99.120.37 which is not the A record for the host pointed to by domain’s mx record.

The ptr record for 68.99.120.37 suggest it’s a cox address:

clifford@Office-PC:~$ host 68.99.120.37
37.120.99.68.in-addr.arpa domain name pointer dukecmfep02.coxmail.com.

Searching through my logs, the day before the report came in, I sent an email to a client with a cox address:

Mar 29 12:01:07 mail-server-2 postfix/submission/smtpd[24010]: connect from unknown[fd00:8000::1]
Mar 29 12:01:07 mail-server-2 postfix/submission/smtpd[24010]: Anonymous TLS connection established from unknown[fd00:8000::1]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Mar 29 12:01:08 mail-server-2 postfix/submission/smtpd[24010]: 567BD140ED1: client=unknown[fd00:8000::1], sasl_method=LOGIN, [email protected]
Mar 29 12:01:08 mail-server-2 postfix/cleanup[24014]: 567BD140ED1: message-id=<[email protected]>
Mar 29 12:01:09 mail-server-2 postfix/qmgr[477]: 567BD140ED1: from=<[email protected]>, size=2158, nrcpt=1 (queue active)
Mar 29 12:01:11 mail-server-2 dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=fd00:8000::1, lip=fd00:8801:2909:6000::c441, mpid=24017, TLS, session=<DwhUS0CFTtn9AIAAAAAAAAAAAAAAAAAB>
Mar 29 12:01:11 mail-server-2 postfix/submission/smtpd[24010]: disconnect from unknown[fd00:8000::1] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8
Mar 29 12:01:12 mail-server-2 postfix/smtp[24015]: 567BD140ED1: to=<***redacted***@cox-internet.com>, relay=mx.coxmail.com[52.40.235.249]:25, delay=4.4, delays=0.9/0.01/2.8/0.67, dsn=2.0.0, status=sent (250 2.0.0 9wkXhMI9sYLKf9wkZhasxm mail accepted for delivery)
Mar 29 12:01:12 mail-server-2 postfix/qmgr[477]: 567BD140ED1: removed

But 68.99.120.37 is not address associated with mx.coxmail.com:

clifford@Office-PC:~$ host mx.coxmail.com
mx.coxmail.com has address 52.40.235.249
mx.coxmail.com has address 34.196.6.209
mx.coxmail.com has address 52.13.194.227
mx.coxmail.com has address 52.22.102.143

If this were a dmarc report from cox, I would archive the email and promptly forget about it. But what has me puzzled is trying to figure out why google sent the report.

I understand that the dmarc reject policy does not kick in unless both spf and dkim fail. And it occurs to me if cox’s server just forwarded the exact email then the dkim would pass, but obviously the spf check would fail. But I cannot think of a scenario where that would legitimately happen.

So if you made it all the way to the end of this, I guess my question for a more experienced email veteran, is this in fact unusual? Or is there an innocuous explanation that I simply lack the imagination to find?

2 Likes
2

Hm,

cliffordburnslaw.com. 299 IN TXT "v=spf1 mx -all"

Assuming you haven’t lost your email server keys, could it be cox was trying to forward an email in some weird way.

1 Like
3

I hope cox forwarding the email in a “weird” way is what happened. It just strikes me as odd because it’s not like there is a “forward and pretend to be the original sender” button on common MUAs (at least not to my knowledge).

Someone getting the private key is a grim thought. It’s readable only by the root and rspamd users on the server. To get in over ssh, you would first have to get behind the firewall, then have the ssh key and the password. There are no auth.log entries other than me. The only publicly exposed ports are postfix’s 25/587 and dovecot’s 143/993. So you would have to be able to either exploit postfix or dovecot which don’t run as root and then either elevate to root or exploit rspamd from presumably postfix since dovecot doesn’t touch rspamd. That seems like a lot of effort to forge an email (or maybe I have a whole lot of shit about to reign down on me). ;(

But just in case I changed the ssh key, reset the machine and the updated the dkim key and dns records.

4

Yeah. I don’t know what kind of thing people could achieve trying to impersonate a lawyer over email, and also, getting dkim right but messing up spf sounds strange.

Cox isn’t your ISP is it? (Thinking about them intercepting your TLS sockets to do “scanning” or something, that would be stupid but maybe not for an ISP)

It’s also possible Google screwed up and you got a bogus dmarc report, not likely but possible, internet should have more people complaining about dmarc in that case (ie. sooner or later bugs happen, for example, people try to write high performance software and reuse datastructures, but forget to make a copy of data before mutating it, and when it runs on a threadpool later, you get crossed wires between records from different emails)

1 Like
5

I do have a personal cox account, and turns out my assumption that

it’s not like there is a “forward and pretend to be the original sender” button on common MUAs

was wrong in this case. Cox webmail has exactly that “feature”:

cox_forwarder
cox_forwarder.PNG831×232 8.31 KB

And when I sent an email from my personal account to my cox account, the version google received was my original, unmodified email plus the headers:

X-Sieve: Pigeonhole Sieve 0.4.24 (13d42912)
X-Sieve-Redirected-From: 3@6494148

Apparently the sieve redirect action has a “:keepmailfrom” option that “retains the original envelope FROM address for use on the redirected message.” And the cox auto forward just creates a simple sieve rule that blindly forwards your mail to the specified address.

And that’s exactly what google received, my original message, but from a cox address, so the spf failed:

Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net. [68.230.241.218])
    by mx.google.com with ESMTP id p64si4958239ywd.194.2019.04.07.23.25.16
    for <***dontspamme***@gmail.com>;
    Sun, 07 Apr 2019 23:25:16 -0700 (PDT)
Received-SPF: fail (google.com: domain of ***toomuchspam***@sluggishmail.com does not designate 68.230.241.218 as permitted sender) client-ip=68.230.241.218;
Authentication-Results: mx.google.com;
   dkim=pass [email protected] header.s=201808 header.b=m4jzo9gP;
   spf=fail (google.com: domain of ***randomthings****@sluggishmail.com does not designate 68.230.241.218 as permitted sender) smtp.mailfrom=***dshfjjdfh***@sluggishmail.com;
   dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sluggishmail.com

At this point I bet my client has cox email forwarded to a gmail account.