DKIM issue Transip+Office365

[Poenzkie]

Sinds kort is onze website verhuisd naar een VPS van TransIP en maken we ook gebruik van de vps mailservice van TransIP. TransIP verplicht je dan ook om voor hun mailservice DKIM records toe te voegen aan je DNS en we hebben toen ook besloten om dit ook gelijk in te richten voor de rest van ons domein, dit dus binnen Office 365. Uiteraard is voor beide server's ook SPF ingericht, SPF werkt als een zonnetje.

Het probleem waar we alleen tegen aan lopen is dat de DKIM van TransIP failed als hij wordt verstuurd naar Office 365.

In de mailheader geeft hij de volgende melding:

dkim=fail (signature did not verify)

Maar als ik dezelfde mail van de VPS naar bijv. gmail stuur, geeft gmail aan dat de DKIM goed is:

Authentication-Results: mx.google.com;
dkim=pass header.i=@contoso.net header.s=transip-a header.b=mGIgRaNf;

Voor de volledigheid hier de hele relevante mail-header, onze domeinnaam is vervangen door contoso.net

code:

Received: from DB7PR03MB4027.eurprd03.prod.outlook.com (2603:10a6:800:d2::31)
 by VI1PR03MB4029.eurprd03.prod.outlook.com with HTTPS via
 VI1PR08CA0201.EURPRD08.PROD.OUTLOOK.COM; Mon, 2 Jul 2018 06:54:25 +0000
Received: from AM3PR03CA0061.eurprd03.prod.outlook.com (2603:10a6:207:5::19)
 by DB7PR03MB4027.eurprd03.prod.outlook.com (2603:10a6:5:32::29) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.23; Mon, 2 Jul
 2018 06:54:24 +0000
Received: from VE1EUR03FT036.eop-EUR03.prod.protection.outlook.com
 (2a01:111:f400:7e09::202) by AM3PR03CA0061.outlook.office365.com
 (2603:10a6:207:5::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.906.24 via Frontend
 Transport; Mon, 2 Jul 2018 06:54:24 +0000
Authentication-Results: spf=pass (sender IP is 149.210.149.72)
 smtp.mailfrom=contoso.net; contoso.net; dkim=fail (signature did not
 verify) header.d=contoso.net;contoso.net; dmarc=pass action=none
 header.from=contoso.net;
Received-SPF: Pass (protection.outlook.com: domain of contoso.net
 designates 149.210.149.72 as permitted sender)
 receiver=protection.outlook.com; client-ip=149.210.149.72;
 helo=outbound1.mail.transip.nl;
Received: from outbound1.mail.transip.nl (149.210.149.72) by
 VE1EUR03FT036.mail.protection.outlook.com (10.152.19.204) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
 15.20.906.15 via Frontend Transport; Mon, 2 Jul 2018 06:54:23 +0000
Received: from submission12.mail.transip.nl (submission12.mail.transip.nl [149.210.149.86])
    by outbound1.mail.transip.nl (Postfix) with ESMTP id 41JyfQ1x7NzT4P6
    for <[e-mail]>; Mon,  2 Jul 2018 08:54:22 +0200 (CEST)
Received: from vps.contoso.net (IPADRES)
    by submission12.mail.transip.nl (Postfix) with ESMTPSA id 41JyfN1j7Wz1BFcs
    for <[e-mail]>; Mon,  2 Jul 2018 08:54:19 +0200 (CEST)
Received: by vps.contoso.net (Postfix, from userid XXXX)
    id CE3D5320B7E; Mon,  2 Jul 2018 08:54:17 +0200 (CEST)
To: [e-mail]
Subject: DKIM Test
Message-ID: <[e-mail]>
Date: Mon,  2 Jul 2018 08:54:17 +0200 (CEST)
From: [e-mail] (User)
X-Scanned-By: ClueGetter at submission12.mail.transip.nl
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 s=transip-a; d=contoso.net; t=1530514462; h=from:reply-to:subject:
 to:cc:references:in-reply-to:date:mime-version:content-type;
 bh=eJuUnCTPtOzo2ZDZ7ZHJIYvxnzt3Y8xTLfV5inPEMM8=;
 b=NeoBetYiwO0mnFCj3IxcnGohhDwDYL/+NOjZvyCI7DBb/Egq1mQxh6uPwKoNTPY/Y33Tat
 KI4FFlQj9EJ3wrbJuf7SUsj5+w0s3axsRr7H+V0DGPyOb9Lulgz3julXCUiLb7EBrLrtwD
 IecL+Oil+2erD3lUVR492g3XrvPddbHVeXEWgJilmzCybPB0iNu5UgoOahSAmo6fJC5gEE
 MzuHIbJhLC5KlyV4mFvezoGmFgyS0J9dvplJQ9QFxtO1dQDPDdGb8DsLV0Kad3LJ/tG0Yh
 twz+kgGKp6QqVyzhERHc6Nbt3Q6I4kMJuvWdWIl+R7/JXP+Yrjl1SmtNzVnrOw==

Samenvatting:
- Mail verstuurd van onze VPS naar Office 365 omgeving komt aan maar geeft aan dat de DKIM failed.
- Dezelfde mail verstuurd naar gmail wordt wel goed gekeurd door Google.

Vragen:
- Zit dit probleem bij Office 365, klopt hun implementatie van DKIM niet?
- Gaat Office 365 dit nooit goedkeuren omdat we het zelfde domein gebruik wat authoritative is binnen Office 365?
- Klopt de DKIM implementatie van TransIP niet, zij voegen namelijk de DKIM toe via hun mailservice, ik doe op mijn eigen VPS niks met DKIM.
- Zie ik een vinkje over het hoofd binnen Office 365?

Wat ik al heb geprobeerd:
- De outbound mailserver's van TransIP toegevoegd als receive connector binnen Office 365, dit heeft helaas geen effect
- Hij gaf deze meldingen al voordat DKIM aanstond op Office 365, het aanzetten van DKIM binnen Office 365 heeft ook niets veranderd.

[Khallouki]

Wat voor website is het? Ik heb in het verleden ook heel veel gedoe gehad met Transip's Mailservice, mails die gewoon niet aankomen, vooral outlook, hotmail, live, msn ontvangers. Allemaal microsoft. Ben toen overgestapt naar een mail dienst die het allemaal voor je regelt: https://postmarkapp.com/

Ze hebben een geweldige API en libraries om het makkelijk te integreren met je website.

[ik222]

Ik vermoed dat dit komt omdat er in de DKIM signing headers velden staan die niet als header in de mail zelf staan. Microsoft is de enige die daar moeilijk over doet heb ik vaker ervaren.

Je signing headers zijn dit:

code:

h=from:reply-to:subject:
 to:cc:references:in-reply-to:date:mime-version:content-type

En niet alle daar genoemde headers staan ook daadwerkelijk in je mail zo te zien (er staan er ook best veel genoemd die niet perse in elke mail hoeven zitten)

Maar goed als ik het zo lees dan regelt TransIP dit dus voor jou, dus ik zou een ticket bij hen inschieten.

[ Voor 16% gewijzigd door ik222 op 02-07-2018 09:47 ]

[Poenzkie]

Khallouki schreef op maandag 2 juli 2018 @ 09:43:
Wat voor website is het? Ik heb in het verleden ook heel veel gedoe gehad met Transip's Mailservice, mails die gewoon niet aankomen, vooral outlook, hotmail, live, msn ontvangers. Allemaal microsoft. Ben toen overgestapt naar een mail dienst die het allemaal voor je regelt: https://postmarkapp.com/

Ze hebben een geweldige API en libraries om het makkelijk te integreren met je website.

Betreft een website van een Basisschool. Enkele mailtjes per dag, gewoon via postfix. Alles komt gewoon aan verder, alleen DKIM gaat niet goed. Ben dus ook niet van plan om over te stappen op een andere mailservice.

ik222 schreef op maandag 2 juli 2018 @ 09:46:
Ik vermoed dat dit komt omdat er in de DKIM signing headers velden staan die niet als header in de mail zelf staan. Microsoft is de enige die daar moeilijk over doet heb ik vaker ervaren.

Je signing headers zijn dit:

code:

h=from:reply-to:subject:
 to:cc:references:in-reply-to:date:mime-version:content-type

Maar goed als ik het zo lees dan regelt TransIP dit dus voor jou, dus ik zou een ticket bij hen inschieten.

Had al een klein vermoeden dat MS hier een aandeel in had. Kan je me uitleggen wat je bedoeld met "de DKIM signing headers velden staan die niet als header in de mail zelf staan"

En uiteraard als blijkt dat dit een configuratie-fout van TransIP is zal ik een ticket bij hun inschieten. Ik wil alleen eerst weten wat het probleem is aangezien ik het zelf ook wil snappen. Daar is dit forum toch voor dacht ik?

[ik222]

Dat h= veld in de DKIM signing headers geeft aan welke header velden meegenomen worden in het aanmaken van de DKIM signature. Als je de RFC's er op na slaat zegt deze het volgende daarover:

Signed header fields (plain-text, but see description; REQUIRED). A colon-separated list of header field names that identify the header fields presented to the signing algorithm. The field MUST contain the complete list of header fields in the order presented to the signing algorithm. The field MAY contain names of header fields that do not exist when signed; nonexistent header fields do not contribute to the signature computation (that is, they are treated as the null input, including the header field name, the separating colon, the header field value, and any CRLF terminator). The field MUST NOT include the DKIM-Signature header field that is being created or verified, but may include others. Folding whitespace (FWS) MAY be included on either side of the colon separator. Header field names MUST be compared against actual header field names in a case-insensitive manner. This list MUST NOT be empty. See Section 5.4 for a discussion of choosing header fields to sign.

Samengevat voor wat hier relevant is:
- Alle velden gebruikt voor het berekenen van de signature moeten op volgorde genoemd worden in de "h=" tag -> Dat gaat ook goed bij jou anders zou elke DKIM validator falen.

- Velden niet gebruikt in de signature (in dit geval omdat ze helemaal niet in de mailheaders zitten) mogen ook genoemd worden -> Ook op dit punt voldoet de TransIP implementatie dus in principe gewoon aan de RFC, want er zitten inderdaad ongebruikte velden in maar dat is ook toegestaan volgens de RFC. Echter Mircrosoft laat hier de DKIM validatie dus toch op falen wat ik al vaker gezien heb, in principe voloet Microsoft daarmee dus niet aan de RFC.

Probleem is echter dat een grote partij als Microsoft lastig / niet te bewegen is tot aanpassingen. Vandaar dat ik toch een ticket zou aanmaken bij TransIP om te kijken of zij kunnen zorgen dat ze alleen de velden noemen in de h= tag die ook daadwerkelijk in de mail zitten en gebruikt worden voor het genereren van de signature. Want het is weliswaar strict volgens de RFC genomen niet hun fout maar ik neem aan dat ze zelf ook graag willen dat hun DKIM validatie niet faalt bij Microsoft wat zich niet aan de RFC houdt.

[Poenzkie]

ik222 schreef op maandag 2 juli 2018 @ 10:28:
Dat h= veld in de DKIM signing headers geeft aan welke header velden meegenomen worden in het aanmaken van de DKIM signature. Als je de RFC's er op na slaat zegt deze het volgende daarover:


[...]


Samengevat voor wat hier relevant is:
- Alle velden gebruikt voor het berekenen van de signature moeten op volgorde genoemd worden in de "h=" tag -> Dat gaat ook goed bij jou anders zou elke DKIM validator falen.

- Velden niet gebruikt in de signature (in dit geval omdat ze helemaal niet in de mailheaders zitten) mogen ook genoemd worden -> Ook op dit punt voldoet de TransIP implementatie dus in principe gewoon aan de RFC, want er zitten inderdaad ongebruikte velden in maar dat is ook toegestaan volgens de RFC. Echter Mircrosoft laat hier de DKIM validatie dus toch op falen wat ik al vaker gezien heb, in principe voloet Microsoft daarmee dus niet aan de RFC.

Probleem is echter dat een grote partij als Microsoft lastig / niet te bewegen is tot aanpassingen. Vandaar dat ik toch een ticket zou aanmaken bij TransIP om te kijken of zij kunnen zorgen dat ze alleen de velden noemen in de h= tag die ook daadwerkelijk in de mail zitten en gebruikt worden voor het genereren van de signature. Want het is weliswaar strict volgens de RFC genomen niet hun fout maar ik neem aan dat ze zelf ook graag willen dat hun DKIM validatie niet faalt bij Microsoft wat zich niet aan de RFC houdt.

Dankjewel voor het uitgebreide antwoord! Ik ga is aan de bel trekken bij TransIP om te zien of zij iets kunnen betekenen. Mocht er nog een update zijn laat ik het hier weer weten.

TransIP heeft ondertussen laten weten dat ze ook inzien dat het lastig is om Microsoft van mening te laten veranderen wat betreft de RFC en ze gaan dus aan een oplossing werken. Hij staat op de To-Do lijst, ze konden alleen nog geen termijn geven wanneer ze het aangepast hebben.

[ Voor 7% gewijzigd door Poenzkie op 03-07-2018 13:41 ]