Mail Station DKIM

[@rno]

Dit lijkt bij mij niet de reden te zijn. De O365 omgeving is exact zo ingericht zoals door Microsoft geadviseerd, inclusief CNAME records in DNS.

[Briolet]

In het log staat niet meer dan "Rejected". Ook niet meer info met extra logging.

Mij valt wel op dat jouw DKIM ondertekening geen timestamp heeft. Volgens mij staat die in bijna alle mail. Volgens de specificaties is het een "aangeraden" parameter en geen verplichte.

Als ik in de source van OpenDKIM kijk, dan krijgt de variabele "sig_timestamp" de waarde nul als die t ontbreekt.

Elders in de code vind ik:

Code: [Selecteer]

/*
**  DKIM_SIG_GETSIGNTIME -- retrieve signature timestamp
**
**  Parameters:
**  sig -- DKIM_SIGINFO handle
**  when -- signature timestamp (returned)
**
**  Return value:
**  A DKIM_STAT_* constant.
*/

DKIM_STAT
dkim_sig_getsigntime(DKIM_SIGINFO *sig, uint64_t *when)
{
assert(sig != NULL);
assert(when != NULL);

if (sig->sig_timestamp == 0)
return DKIM_STAT_INVALID;

*when = sig->sig_timestamp;

return DKIM_STAT_OK;
}

Dat doet vermoeden dat OpenDKIM de waarde null als een ongeldige waarde beoordeelt. Als ik dat goed interpreteer is dat een fout van OpenDKIM omdat de tijdcode geen verplicht veld is.
Maar misschien dat er nog ergens in de code nog iets staat dit nog overuled.

Is het voor jou mogelijk om aan serverzijde de timestamp toe te voegen?

[@rno]

Nee, helaas niet. Nadeel van een cloud dienst. Ik kan DKIM enkel aan- of uitzetten (en aan kan enkel als DNS van het domein goed is ingesteld).

[Briolet]

Ik heb nu de "reject on-BadSignature" uitgezet. (Dat is eigenlijk de default van OpenDKIM, maar Synology heeft dat op reject gezet)

MailServer geeft een fail in de header:

Code: [Selecteer]

Authentication-Results: xxx.nl; dmarc=pass header.from=xxx.eu
Authentication-Results: xxx.nl; dkim=fail reason="signature verification failed" (1024-bit key)
Als ik de mail echter met een cliënt open die ook DKIM kan controleren, zie ik:



Thunderbird ziet de DKIM handtekening inderdaad als geldig. Ook nadat de mail door mailserver bewerkt is. Dit lijkt me toch een bug in OpenDKIM. Ik gok door de ontbrekende timecode. (Ik kan niets anders verzinnen)

[Briolet]

Ik vond hier nog iets over een missende 'timestamp' in de DKIM signing:

Spammers don’t normally set time values. Empty or incorrect time values, such as an expiration time dated before the email timestamp, will cause some mailbox providers to reject the message.

t= is the DKIM signature timestamp. It is meant to indicate the time that message is sent. The format is the number of seconds from 00:00:00 on January 1, 1970 in the UTC time zone.

Dus hoewel de timestamp optioneel is, gebeurt het vaker dat dit soort mail geblokkeerd wordt. Voor de betrouwbaarheid zou een mailserver dus altijd een tijdcode moeten toevoegen. Er is ook niets geheims aan de tijd van verzenden. OpenDKIM accepteert tot 5 minuut afwijking voor het geval van niet synchroon lopende klokken.

Edit:

De timestamp is toch niet essentieel voor OpenDKIM. Ik zag net dat de mailings van de Hanos ook geen timestamp hebben:

Dkim-Signature: ⁨v=1; a=rsa-sha256; c=relaxed; s=selector1; d=td42.tripolis.com; h=Date:From:To:Subject:MIME-Version:Content-Type:List-Unsubscribe:Message-ID; bh=X/d1yuiYnyIvRqhSQSU0fs0WSHFT8nzIqGCTLLsACMs=; b=dy0XqU6powzbAzGoWLShkLZtsrOKCtj56nHC8UMwqBmtB7EltJSq/HDqQTP5SX1yNKrIXfdnVg9C uy0C/swT4NFXDeKq7hxByf98k5PFNN8tSCTGh1oarwans30aLBUcejtQOARLonOLEkbrg6sD54tS xZAI9sdYQkwxmEz4Ofw=⁩

Er gaat dus iets anders fout.

[Briolet]

Die indirecte methode via een alias, is ook niet de reden. Het voordeel van die alias is vooral dat jij dat record niet hoeft te publiceren. Als de office server de key veranderd, hoef jij geen actie te ondernemen.

Ik heb jouw public key eens met die van Tripolis vergeleken Die mailing krijg ik altijd probleemloos binnen en loopt blijkbaar ook via zo'n CNAME constructie:

Code: [Selecteer]

Briolet$ host -t txt selector1._domainkey.xxxx.eu

selector1._domainkey.xxxx.eu is an alias for selector1-xxxx-eu._domainkey.xxxx.onmicrosoft.com.

selector1-xxxx-eu._domainkey.xxxx.onmicrosoft.com descriptive text
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxTrZ+VDlN3aazo0yCSl8WWIiHOzr4cWlBrcrdGxKdAlJnmjI230siLmDotGS4uxtnxg0BaySb7k4CwMuoBrBQXQKPy5y8d2mMmga+lLue3EMxWetrf12Y+4We75gS/91/sndq5EqcUkoN2Oim2DBJEkZ5isXzC20lsxpGTzi/aQIDAQAB;"

--------------
Briolet$ host -t txt selector1._domainkey.td42.tripolis.com

selector1._domainkey.td42.tripolis.com is an alias for selector1-td42.dkim.tripolis.com.

selector1-td42.dkim.tripolis.com descriptive text
"v=DKIM1;h=sha256;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8wISrBaa7vaO6zRxx7JxPWNPljUulngxMAdWOVEMba2438TqneT4WbLDPXnovuzYMKmK7" "SXMhjf5R1xGxtSmc9thOCa1VkzcVtgBbQywBL5TmoIc/f6YlRf9dFsmvm7WxwBkbbdZGD7bGys7kmndH5+xdQ2goazQudZ5kK8EUZwIDAQAB"

Daar zie ik geen fundamenteel verschil tussen.

------

Wat je kuny proberen is om geen CNAMe te gebruiken, maar het TXT record zelf te publiceren. Moet ook gewoon werken, zolang onmicrosoft.com de sleutels niet aanpast. In elk geval kun je voor de duur van een test die records eens aanpassen om te zien of het dan wel werkt.

[@MArtijn]

Sinds begin juni ook problemen met bijna alle office 365 beheerde domeinen. De mail log laat zien dat de mails gestuurd vanaf die domeinen geweigerd worden ivm bad DKIM Signature.


Na met meerdere beheerders gesproken te hebben, bleek dat zij de instellingen precies zo hadden ingesteld als geadviseerd door microsoft. Uiteindelijk een ticket aangemaakt bij synology, welke vrij spoedig opgepakt werd. Uitkomst (
2018-07-31) zie hieronder:


Hi Martijn,
 
Thank you for waiting.
 
After confirming by our developer, this is a known issue that our developers are working hard to address in a future release.
Please kindly stay tuned for the update, and in the meantime, we apologize for any inconvenience caused.
 
[Fix]
Please install the Mail Server package (attached with in the message) in Package Center.
 
Please let us know if the issue is resolved after installing the package in Package Center, thank you.




De fix nog niet geprobeerd... zal deze in het weekend toepassen.

[@rno]

Fix heeft inderdaad geholpen, stond bij mij sinds 2 uur in package manager beschikbaar. Zojuist geinstalleerd, een mail gestuurd en DKIM signature is nu wél in orde!

[Briolet]

Ik kan niet zien wat veranderd is omdat alles van mailserver vernieuwd is. De config file is in elk geval wel gelijk gebleven.

Mooi dat het nu wel werkt.

[Briolet]

Misschien hebben ze wel niets zelf gefixed, maar alleen OpenDKIm een keer geupdate. Ik zie nml dat versie "2.10.0" van december 2014 nu naar versie "2.10.3" van mei 2015 geupdete is.

De releasenotes van de OpenDKIM updates zijn:

2.10.3      2015/05/12
   LIBOPENDKIM: Make strict header checking non-destructive.  The last change
      to this code resulted in failing signatures.  Reported by Pedro
      Morales and Wez Furlong.

2.10.2      2015/05/10
   Fix bug #221: Report a DKIM result of "policy" if MinimumKeyBits
      or UnprotectedKey cause the signature to result in a "pass"
      override.  Reported by Kurt Roeckx.
   Fix bug #227: Revert removal of SenderHeaders configuration setting.
      Document that it is now limited to signature selection.
   LIBOPENDKIM: Fix bug #226: Deal with header fields that are
      wrapped before there's any content.  Reported by
      Alessandro Vesely.
   CONTRIB: Update to contrib/systemd/opendkim.service.in from
      Steve Jenkins.

2.10.1      2015/02/03
   Fix bug #214: Handle arbitrarily large From: fields.  Reported by
      Tomohiko Sasaki.
   Fix bug #220: Make DB_SIGNINGTABLE symbol available in Lua scripts.
      Problem noted by Klaus Heinrich.
   LIBOPENDKIM: Fix bug #213: Remove "dkim_default_senderhdrs" from
      dkim.h.  Problem noted by Daniel J. Luke.
   LIBOPENDKIM: Fix bug #219: Unresolved CNAMEs are not failures,
      according to the DNS (see RFC6604), so report them as
      NXDOMAIN or similar.  Reported by Alessandro Vesely.

2.10.0      2014/12/27

[@rno]

Misschien hebben ze wel niets zelf gefixed, maar alleen OpenDKIm een keer geupdate. Ik zie nml dat versie "2.10.0" van december 2014 nu naar versie "2.10.3" van mei 2015 geupdete is.

Dat is toch wel schandalig dat er zo veel DS updates verder nog altijd niet naar de laatste versie van OpenDKIM geupdatet was..... In elk geval zijn ze nu bij en werkt het nu ook. Thanks voor al je inzet bij het meehelpen uitzoeken nog.

[Briolet]

Storend is dat DKIM toegevoegd is in DSM 5.2. Deze DSM versie heeft een releasedatum van 2015-05-12. Heel toevallig dezelfde releasdatum als de laatste versie van OpenDKIM.

Waarschijnlijk was versie 2.10.0 de actuele versie toen DSM 5.2 de beta fase in ging maar hebben ze er verder niet meer naar omgekeken toen er nog een paar bugfixes verschenen.

Ook vreemd dat ik uit de relesenotes van DSM 5.2 moet halen dat DKIM toegevoegd is, terwijl hierover niets terug te vinden is in de releasenotes van MailServer zelf. Terwijl het daar toch echt in zit en niet in DSM.

Beter laat dan nooit, zullen we maar zeggen.