J'ai voulu signaler leur problème DNS à la Banque Populaire et à la Caisse d'Épargne, mais impossible de leur envoyer un email.
Le serveur emails pour tous les domaines dont font partie les adresses emails techniques trouvées dans les bases de données publiques accessibles avec le protocole whois (et bientôt RDAP ?) est mail-in.bpce-it.fr.
Celui-ci refuse mes emails pour le motif suivant : « 550 #5.7.5 DKIM unauthenticated mail is prohibited. If you believe that this failure is in error, please refer to https://tools.ietf.org/html/rfc6376 or contact postmaster [à] bpce-it.fr for more information via alternate means. »
J'ai bien envoyé mon courriel via le seul serveur emails autorisé pour mon domaine.
Étrangement, un email envoyé par Stéphane depuis un domaine qui n'implémente pas DKIM passe très bien. Cela illustre que DKIM n'est pas obligatoire pour communiquer avec BPCE. Peut-être qu'une signature DKIM devient obligatoire quand la réputation de l'adresse IP ou du réseau du serveur emails émetteur est questionnable ? Mon serveur est hébergé chez OVH, émetteur de spam malgré lui, alors que celui de Stéphane est dans un réseau IP de bonne réputation.
Encore plus étrange : mes emails sont bien signés en suivant la norme DKIM. Peut-être y a-t-il un problème technique de mon côté ?
Je m'envoie un email à une autre adresse que je gère et qui met en œuvre la validation DKIM : à l'arrivée, les entêtes de l'email confirment qu'il comporte bien une signature DKIM et que celle-ci est valide : « Authentication-Results: viki.guiguishow.info; dkim=pass (3072-bit key; secure) header.d=[CENSURE] header.i=@[CENSURE] header.b="PGTxFJuT"; dkim-atps=neutral ».
Il existe des testeurs de serveur emails. J'en ai utilisé trois (plus que ça en vrai, mais certains ne fonctionnent plus) : https://www.mail-tester.com/ , auth-results [à] verifier.port25.com , et ping [à] stamper.itconsult.co.uk . Tous les trois confirment la présence et la validité d'une signature DKIM dans mes emails sortant. Il semble donc que le problème est du côté de BPCE.
De plus, j'ai configuré une politique ADSP souple, « dkim=all » qui signifie "normalement, tout courriel émanant de ce domaine sera signé, mais si ce n'est pas le cas, ne le jete pas à la corbeille, stp". Évidemment, elle a la valeur d'un conseil : le récepteur fait bien ce qu'il veut.
Pour signer les entêtes de mes emails sortants, mon serveur emails utilise une clé RSA 3072 bits. C'est la taille recommandée par l'ANSSI (document B1) pour mettre sérieusement en pratique de la cryptographie au long terme. Mais, c'est vrai que, pour signer des emails dans le cadre de la lutte anti-spam (c'est l'objet de DKIM), une clé de taille inférieure serait suffisante. Néanmoins, début 2018, le RFC 8301 a mis à jour le RFC de DKIM (6376) : « Signers SHOULD use RSA keys of at least 2048 bits. Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys. ».
Je conçois bien un problème à ce niveau-là : ma clé est rejetée en raison de sa taille, donc mon email est considéré comme étant non signé, donc, soit la réputation du réseau de mon serveur emails joue contre lui, soit BPCE-IT est intransigeant avec les domaines qui ont une politique ADSP fut-elle souple. Cette hypothèse a été confirmée par BPCE-IT : « […] en raison d’une limitation de notre produit actuel, nous ne pouvons pas vérifier de signature au-dessus de 2048 bits et il ne connait pas la notion de politique ADSP. Ainsi la signature 3072 bits est traitée en erreur […] ».
A priori, ce souci a été signalé à BPCE-IT par Stéphane, merci. :)