1

Since a few weeks, mails sent via my mailserver at the-grue.de fail dkim authentification. That's very strange, because I'm not at all aware of any changes on my part...

mxtoolbox checked the mail, with this result:

https://mxtoolbox.com/deliverability/e6fcc04f-2e51-4884-bce8-c09897e99ba9

My MTA is postfix with opendkim on debian buster.

I definitively didn't change keys.

That's (most of) the opendkim configuration:

Syslog                  yes
UMask                   007
Socket                  local:/run/opendkim/opendkim.sock
PidFile               /run/opendkim/opendkim.pid
OversignHeaders         From
TrustAnchorFile       /usr/share/dns/root.key
AutoRestart             Yes
AutoRestartRate         10/1h
SyslogSuccess           Yes
LogWhy                  Yes
Canonicalization        relaxed/simple
ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts
KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable
Mode                    sv
SignatureAlgorithm      rsa-sha256
UserID                  opendkim:opendkim
FixCRLF                 yes
KeepTemporaryFiles      yes

Please tell me if I should add more information. Thanks!

Updates:

2022-05-09 I still have to compare outgoing and incoming messages. But I have a (desperate) idea: I'm sure nothing changed on my side. So only other thing that might have changed is the TXT record at my DNS provider which is:

% dig mail._domainkey.the-grue.de TXT     

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> mail._domainkey.the-grue.de TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59918
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mail._domainkey.the-grue.de.   IN  TXT

;; ANSWER SECTION:
mail._domainkey.the-grue.de. 1426 IN    TXT "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0TpEH5ah1skjwh85+U1LiiywnquMF8yI78Y+p/METvBIdud64zvVRNrP0zsVOc+n/ZZ2JZnkjMBKcsXW1nQIpSJS2JpIa9UD5SRJmarBeTqQaBAlE4oxJfmVaL1eP8EnuzY0xGHsmlCeEpWAG51rc1uJ7SFF4R1K6Q68JVcE56dM0ugWi2oOJic" "Hm/6Q2dhrhWJ4fHy7G/Kbd89bcDDcfht9mtdE6XupdGjpVXaBNEL8isf9SH46ATBXiDe8kb/4f3dTCj4LCNhUN47SOYZojcwtwejLnSt1u24sPIuqvh0XK66JdOYh6qNJcT7TptBeUz5M3cJw3cSGPX39ktNS6wIDAQAB"

;; Query time: 21 msec
;; SERVER: 46.182.19.48#53(46.182.19.48)
;; WHEN: Mo Mai 09 21:35:50 CEST 2022
;; MSG SIZE  rcvd: 490

Could there be a problem? Maybe because the TXT record is not one string but two? Note that the record has the form

"v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqh...i2oOJic" "Hm/6Q2...IDAQAB"
Markus Grunwald
  • 13
  • 4
  • For starters, review what other software is processing messages as they go through postfix (e.g. other milters). Temporarily use the `IgnoreMalformedMail` feature in opendkim to verify that what opendkim is signing looks well formatted. Compare the source of a message as you sent it (e.g.: as stored by your MUA in a *Sent* folder) to a message a remote server received and see if any of the headers you sign or any of the body structure has been modified in transit. – anx May 04 '22 at 05:55
  • @anx thanks for your input! Until now I have only briefly checked messages but didn't find any modification. I also set `IngoreMalformedMail` to `No` but saw now errors. Please have a look at my update. – Markus Grunwald May 09 '22 at 19:43
  • Your DKIM TXT record has to be served in two strings because you are using a 2048-bit RSA key, and the public key record will be longer than the 255 octet limit. – Paul May 10 '22 at 15:27

0 Answers0