Discussion :

[BenjGe]

Bonjour

J'ai un utilisateur disposant d'une boîte exchange qui préfère travailler depuis son gmail. L'ensemble de ses mails envoyés dans sa boîte exchange sont donc redirigés vers sa boîte gmail (via les paramètres de flux de la boîte).
Depuis quelques temps lorsqu'un utilisateur du domaine exchange transfère une discussion à cet utilisateur (sur sa boîte exchange) gmail le classe en spam en raison de la stratégie dmarc.

Je précise qu'exchange fonctionne en mode Hôte actif (c'est à dire que nous nous appuyons sur le smtp du prestataire du nom de domaine pour la réception d'email et non sur le smtp d'exchange). les boîtes exchange correspondent à des boîtes mail pop3 hébergées sur le prestataire et un connecteur pop 3 va régulièrement relever le courrier des comptes pop3 pour les déposer dans les boîtes exchange correspondent.

A noter que dans cette configuration là les utilisateurs internes ont un mail en domaine.tld (domaine approuvé exchange) et que leurs boîtes POP3 externes ont le même suffixe (ce qui ne pose pas de souci car les internes voient leur courrier relayé par exchange tandis que les externes n'ont à faire qu'au compte pop3 externes relevé par exchange)

Je ne connaissais pas dmarc. J'ai commencé à regarder sur le net, mais c'est encore fouillis dans ma tête. Toute aide sera la bienvenue.

Merci

[BenjGe]

je repost car je pense avoir réglé en partie mon problème.

J'ai donc configuré SPF et DKIM pour mon domaine, ce qui a réglé certains problèmes (gmail fait davantage confiance aux mails de mon réseau). Cependant il reste un scénario qui m'a fortement embêté: utilisateur AOL envoie un mail à un utilisateur interne et pour lequel le serveur exchange relaie vers une boîte gmail.

Dans ce cas précis l'authentification DKIM échoue car exchange dans sa moulinette modifie quelques headers du mail (le champ to et le champ content-type) rendant l'authentification impossible. Après de nombreuses recherches sur le net j'ai découvert que ce problème frappait de nombreux MTA sous toute plateformes et les utilsiateurs d'Exchange Online notamment. Je n'ai pas encore repotassé la RFC822 mais je pense que celle-ci n'établit pas clairement que les MTA ne doivent pas modifier les headers initiaux d'un mail, d'où les implémentations actuelles qui ne peuvent relayer des mails avec authentification DKIM.

J'ai fini par trouver une déclaration de bug de MS pour exchange 2013 et une mise à jour corrigeant le problème. Mais rien pour 2010 malheureusement pour moi.

Le bug reconnu par MS:
http://support.microsoft.com/kb/2993556

la maj pour Exchange 2013 qui corrige le problème si d'autre rencontre le problème:
http://support.microsoft.com/kb/2961810

Donc nouvelle question si MS ne publie pas de correctif j'aimerai tenter le développement d'un agent de transport corrigeant le problème (au risque de casser certaines fonctionnalités d'Exchange comme la réécriture d'adresse pour messages sortants). Mais pour y parvenir j'aurai besoin d'accéder au mails bruts reçus en entrée du système et destiné à être relayés. Donc voici ma question:

Est il possible d'accéder au mails bruts entrant dans une organisation Exchange (avant toute modif d'exchange)? Si oui pouvez vous m'indiquer une classe et une méthode?

PS: je trouve que cette authentification DKIM segmente le net et casse la confiance dans la délivrabilité d'un mail. En imposant ce standard et en envoyant des NDR en cas d'échec d'authentification, GMAIL Yahoo et AOL ont détruit la confiance que l'on peut avoir en un composant mail d'être capable d'envoyer des mails sur l'ensemble de la planète à cause de cette histoire de champs retraités. En gros pour être sûr de dialoguer avec des utilisateurs de ces systèmes il faut une boîte mail chez eux.
En l'existence de DKIM empêche même d'utiliser des fonctionnalités de serveurs mails d'entreprise. J'espère qu'ils reviendront à une gestion plus douce des échecs d'authentification DKIM.

Autre question : quel est le lien de déclarationd ebug auprès de microsoft pour le produit Exchange 2010? J'aimerai pointer le fait que le bug qu'ils ont repéré en 2013 existe aussi en 2010 (vérifié par mes soins avec preuve à l'appui)?

[BenjGe]

Toujours sur la même lancée j'ai vu sur ExchangeDictionary que l'équipe Exchange a publié une Cumulative Update pour Exchange 2010 et 2007 en parallèle de la 2013. (source: http://www.exchangedictionary.com/ne...ge-server-2013)

Je l'ai donc testé sur un serveur 2007 (bientôt sur un 2010). Elle résout partiellement le problème mais pas complètement.

L'update dont il est question: http://www.microsoft.com/en-us/downl....aspx?id=44024

Je précise le problème. Lorsqu'un serveur émet un mail et qu'il l'authentifie avec DKIM, il utilise différents champs de l'email. Idéalement il va utiliser: FROM,REPLY-TO,TO,CONTENT-TYPE,MIME-VERSION,SUBJECT,DATE,MESSAGE-ID.
Ces champs seront canonisés selon une méthode standardisée, puis le résultat sera chiffré à l'aide d'une clé privée de chiffrement. la valeur obtenue est ajoutée dans l'email ainsi que la liste des champs utilisés,la méthode de chiffrement et de canonisation.

Un serveur qui voudra authentifier l'email ira requêter la zone DNS de l'expéditeur pour obtenir la clé publique de chiffrement, et la stratégie à adopter en cas d'échec d'authentification. Le serveur en réception canonise à son tour les champs et compare le résultat avec le résultat du déchiffrement de la signature par la clé publique. Si les valeurs sont identiques c'est donc que le serveur initial qui a ajouté la siganture DKIM possède la clé privée de chiffrement (et devrait donc être de confiance).

Donc tout fonctionne à condition qu'aucun serveur ayant servi à faire le relais n'aie modifié les champs utilisés.

Dans le cas d'un mail envoyé depuis gmail par exemple vers un utilisateur exchange qui relaie vers une autre boîte gmail. La signature qu'a ajouté GMAIL au message original n'est plus reconnue authentique dans la boîte mail final. En effet exchange modifie les headers des mails entrants: il ajoute des chevrons autour de l'adresse email du destinataire, et il ajoute des guillemets au parapètre boundary de content-type.
Résultat le déchiffrement ne renvoie plus le résultat attendu.

La maj que j'ai testé (Update Rollup 14 pour Exchange 2007 sp3) corrige le problème autour du champ TO (exchange n'ajoute plus de chevron) par contre il continue à ajouter des guillemets autour de boundary. Donc le problème n'est pas réglé

En tout cas l'équipe exchange a l'air d'aller doucement vers le support de dkim. J'espère que ce sera pour la sp4.

la semaine prochaine je testerai sur la version 2010.

En attendant qui peut m'indiquer la procédure (lien, mail, telephone) pour ouvrir un ticket de support auprès de microsoft? Je voudrai si c'est possible tenter de pointer du doigt que l'update ne résout pas encore tout (et je pense qu'ils le savent déjà).


Deuxième question quelqu'un a t il un exchange 2013 sous la main avec le même problème que moi (échec d'authentification DKIM dans les systèmes distants dans le cas d'un mail relayé vers une boîte externe vérifiant DKIM)?