• RFC 7960 : Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows

    Le mécanisme #DMARC permet d’indiquer dans le #DNS la politique d’un domaine concernant l’authentification du courrier. Si je reçois un message prétendant venir de ma-banque.example, et qu’il n’est pas authentifié (ni #SPF, ni #DKIM, ni autre chose), comment savoir si c’est parce que ma banque est nulle en sécurité du courrier, ou bien parce que le message est un faux ? DMARC permet de répondre à cette question en publiant un enregistrement qui indique si le courrier est censé être authentifié ou pas. Comme toutes les techniques de sécurité, ce mécanisme est imparfait et il pose notamment des problèmes avec les messages indirects. Par exemple, si vous avez une adresse à votre ancienne université, alice@univ.example et que le courrier qui lui est adressé est automatiquement transmis à votre adresse professionnelle, alice@evilcorp.example, comment DMARC va-t-il réagir avec cette indirection ? C’est ce qu’explore ce #RFC.

    http://www.bortzmeyer.org/7960.html

    #sécurité_courrier_électronique

    • Et, en parlant des ré-expéditeurs, les listes de diffusion, pas vraiment prévues par DKIM , que faire pour elles ? Le RFC 6377 a déjà traité leur cas. Une technique courante est de modifier le champ From : pour mettre l’adresse de la liste, réduisant l’auteur original à un commentaire dans cet en-tête (avis personnel : je déteste ça). Comme cela rend difficile de répondre en privé au vrai auteur d’un message, l’ajout d’un Reply-To : peut aider. Une autre solution est d’emballer le message original dans une partie MIME message/rfc822. Cette partie resterait intact et le message emballant aurait comme expéditeur la liste. Mais peu de MUA savent afficher proprement ce genre de messages (spécialement dans le monde des mobiles).

      #sympa #infini