Score:2

(Why) Would email servers stop sending DMARC reports because of DKIM?

cn flag

I have a personal email server I've been running for years; very seldom has there been a problem with sending mail and so I've never really got up to speed with things like SPF, DMARC, and DKIM. Recently, while upgrading the system, I decided to do this.

SPF was very simple, since I use a single, fixed IP address.

DMARC was almost as simple; I set this up initially with a policy of "none" to receive reports and left this for a week or two then switched it to reject.

I've now implemented a DKIM signing filter for the mail server (Courier MTA, and no there is no ready made for this). For the complicated bits I used dkimpy. This also has a simple verification tool which works on whole messages, does it's own look-ups, etc., meaning it is dummy proof in that there is only one way to use it (whereas the signing can be configured various ways and possibly leaves room for me to muck it up). This passes messages that I think should pass and fails ones that I think shouldn't, so I'm reasonably satisfied that works; I've run it on messages as received from the server. Currently, to minimalize issues, I'm signing just the body and the From header.

However, none of my mail is going through to my test accounts -- one is gmail and the other is from my ISP. What's more, although I now have both rua and ruf addresses in the DMARC record, I am not getting any reports for them. Previously, they were both like clockwork.

If all I do is turn off the filter (so no DKIM sig), everything works again. I have checked that the server is actually trying in all cases; the failed DKIM ones seemed to get time-outs and closed connections resulting in an endless deferral -- which all alone seems a bit odd since it implies the "rejected" mail is not even being examined, yet removing the signature is all it takes to get it accepted again. I'll put that down to ambiguities in Courier's logging.

I realize no one is bound by any laws here, but is that a normal policy? Assuming the DKIM signature is wrong, shouldn't the receiving server send me a DMARC report of that?

So I'm currently up a creek. Although things like MXToolbox give me flying colours, I have not found a free service that actively tests the DKIM signature by taking mail except for one, which appears to have done what the other servers did -- never accepts the mail it is supposed to test (dunno if this is a potential clue).

Here's the relevant DNS records from dig:

  • SPF: cognitivedissonance.ca. 3600 IN TXT "v=spf1 ip4:138.197.150.177 -all"

  • DKIM:

      aporia._domainkey.cognitivedissonance.ca. 3600 IN TXT "v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAosptGk+J2mdjjc7RWmcnQ3yBqx1JT/lA0bw4GJCzZ+esa0f8rjHhPiW6NnUr64Kf5h0fPEthQhYGTjjw3jAd/3EE28hGA30+jODxEK7A0+5aeI82fWa/ZZk9FvyIhf+UkkX1B0klYhCRW5r91smJ+rwYrr2B6jOrw0DReHTAZ51NACSWI7ov2mA" "UIh2l8blA8hFFBOBwxlzC+smRsYlZCKZfsSMkyS/XIm2m58QNfw/aCHp5VufSrf/hh7f6AGKTgxHfgs+8RBbYdHEM2LAMT+WYsITC3R0OYfgplzWna6PRB9lx+FFzTtT/8XClYfUJ6rwWwM4koeX0yt9gDr/03QIDAQAB"
    

    Note that the FQDN of the mail server is aporia.cognitivedissonance.ca and so I used aporia as the DKIM selector out of lack of imagination. The email domain is just cognitivedissonance.ca. Should I be using the FQDN instead (ie. aporia._domainkey.aporia.cognitivedissonance.ca)?

  • DMARC:

      _dmarc.cognitivedissonance.ca. 3600 IN  TXT     "v=DMARC1;p=reject;pct=100;rua=mailto:[email protected],mailto:[email protected];ruf=mailto:[email protected],mailto:[email protected]; "
    

    There are some extra mailto's there for a dmarc validation service I signed up to. Unfortunately, they don't test DKIM signatures directly.

Finally, an example of a signature:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=cognitivedissonance.ca; [email protected]; q=dns/txt;
 s=aporia; t=1650468130; h=from;
 bh=3N81YR+AxHZqpkdMAh4Jti6JpRmUrlzO5bUjUoWdGeg=;
 b=kNzUid2LG8TfHoegur3JzlcktiJT+5A1E2en+IlV/GgDMZWL0Ft/4kE02LGFzb2kTMkav
 c9jLUqd2+NCrLDzVRBxgwif++vDwoljCI1X0wvbcCqhfA3uElcCuhCAtBkl/ZNqLR0H1Gjq
 XXA801KqyVrvottuv0+PmEOvqQ8skTpBvl4Da8JjQ73Zscm3/5Mfk0dGTLlggNgapszsP9z
 nt/1Oi6gzLasX933wIdLZWVex8QNfKr8+MTx6bmpVodaeklR+281u8k1zhCBu5pWrzlavUh
 CbWjUm4j3YbeztpG98r9MZOVKbJZyHaiHWcRa1vEq3Cz8AEnRyRkQhd5WtvA==
Paul avatar
cn flag
I don't know `courier`, but perhaps turn logging on verbose. It sounds more like your DKIM tool is making some change to the message and the receiving servers don't like it so they hang up on you. It would be helpful to see something like receiving logs or full received server headers where they do all the checks. DKIM authenticates against RFC5322.from domain. You might try sending a message to all of the freemail domains and check your logs for the transactions, as sometimes they leave messages that even include links to explain why they rejected your attempted.
anx avatar
fr flag
anx
From the information provided, I am not sure whether *Courir* is crashing on a problem with *dkimpy*, because of your method of integrating it, or whether you are hanging up on remote servers still trying to work out whether to accept your signature. Get us some more info on how you setup the filter, and logs, please.
Score:0
cn flag

Eventually I did find an online DKIM validator: https://www.appmaildev.com/en/dkim They'll test an upload of an existing mail or give you a test address to send to.

I am not 100% sure what the original problem was, because by the time I found this I had created another one: Using Digital Ocean's "floating IP" feature to set my DNS records from. The OS doesn't actually see this address, and other mail servers were reporting mail as from that "actual" IP, (which is still valid). Worth noting if you are a droplet user.

To be clear, that could not have been the original problem, because I only enabled the floating IP yesterday when, in desperation, I decided to move the node to see if anything fell out of the tree. However...

I have not found a free service that actively tests the DKIM signature by taking mail except for one, which appears to have done what the other servers did -- never accepts the mail it is supposed to test (dunno if this is a potential clue).

Note that service was not the one linked in the first paragraph here. Anyway, that other mail servers in general were refusing connections (as opposed to bouncing mail) does seem to scream "DNS issue". Why exactly this became a problem when the new install of the server had been running for a month I still don't know, so this is really only a partial answer -- although it does explain Why email servers would stop sending DMARC reports. Getting all my ducks in a row with the DNS records (A records for the domain and the aporia node, matching the SPF, etc), finally everything is working as it should be.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.