MARID

MARID est un groupe de travail de l'IETF dans le domaine des applications, chargé de proposer des normes d'authentification des courriels en 2004. Le nom est un acronyme de MTA Authorization Records In DNS.

Le protocole d'authentification léger MTA (LMAP)^[1] était un nom générique pour un ensemble de propositions « d'expéditeur désigné » qui ont fait l'objet de discussions à l'automne 2003 au sein de l'ASRG, incluant notamment :

• Protocole des expéditeurs désignés (Designated Mailers Protocol – DMP)
• Protocole d'interrogation sur les relais désignés (Designated Relays Inquiry Protocol – DRIP)
• Validation flexible de l'expéditeur (Flexible Sender Validation – FSV)
• MTAMARK
• Reverse MX (RMX)
• Framework de politique d'expéditeur (Sender Policy Framework – SPF)

Ces méthodes servent à tenter de répertorier les adresses IP valides qui peuvent envoyer du courrier pour un domaine. Le « léger » dans LMAP signifie globalement « pas de cryptographie », par opposition à DomainKeys et à son successeur, DKIM. En mars 2004, l'IETF a organisé un BoF (Birds of a Feather) pour discuter de ces propositions. À la suite de cette réunion, l'IETF a fini par créer le groupe de travail MARID^[2].

La proposition Caller‑ID de Microsoft fut un ajout tardif et très controversé. Elle incluait les fonctionnalités suivantes :

• Utilisation de politiques XML avec DNS – réduites à ce qui est désormais connu sous le nom d'ID de l'expéditeur.
• Portage et extension de la SPF existante.
• Utilisation des champs d'en-tête de courrier RFC 2822^[3] comme par DomainKeys (tous les autres brouillons LMAP ont utilisé l'enveloppe SMTP).
• Questions particulières sur les brevets et les licences^{[réf. nécessaire]}.

Le groupe de travail a décidé de différer la question des identités SMTP RFC 2821^[4] – c'est-à-dire MAIL FROM géré par SPF, ou HELO géré par CSV et SPF – en faveur des identités RFC 2822^[3] couvertes par Caller‑ID et plus tard Sender‑ID par la « Purported Responsible Address » (Adresse Prétendue Responsable – PRA).

Le groupe de travail est arrivé à un point où les politiques d'expéditeur pouvaient être divisées en différents « scopes », comme le 2821 MAIL FROM ou le 2822 PRA. La syntaxe MARID spf2.0 permettait également de joindre différents scopes dans un seul registre de gestion des stratégies, à condition que les ensembles d'adresses IP autorisées soient identiques, ce qui est souvent le cas.

Moins d'une semaine après la publication d'un premier brouillon pour mfrom ou MAIL FROM, le groupe de travail a été dissous unilatéralement par sa propre direction. Aucune RFC n'aura été publiée durant les sept mois d'existence du MARID^[5],[6].

En 2005, le directeur régional de l'IETF en charge a accepté de parrainer la publication de certaines des discussions inachevées de MARID comme « expériences de l'IETF » ; ainsi, le SPF pré‑MARID^[7] et l'ID de l'expéditeur^[8] ont été approuvés en tant que RFC expérimentales. Cette dernière est dans une certaine mesure le résultat de MARID, progressivement élaboré sur la base de la proposition Caller‑ID.

La persistance de conflits relatifs à des problèmes techniques et des incompatibilités dans Sender ID a par la suite donné lieu à des réclamations en appel^[9] auprès de l'IESG et de l'IAB.

• « Projet historique ASRG – LMAP », sur IETF, 2004.
• « Page d'état MARID », sur IETF, 2004 et archive de liste mxcomp.
• « Direction DEA (dissoute) » [archive du 15 juillet 2006], sur IETF.
• « Évaluation IESG de Sender-ID », sur IETF Datatracker, 2005.
• « Appel de l'IAB », sur IAB, 2006 – avec des liens vers d'autres sources.
• « Historique des appels SenderID », sur purl.net, 2006.

• Portail de la sécurité des systèmes d'information