# MARID

MARID était un groupe de travail de l'IETF dans le domaine des applications chargé de proposer des normes d'authentification des e-mails en 2004. Le nom est un acronyme de M TA Authorization Records In D NS.

## Contexte

Le protocole d'authentification léger MTA (LMAP) é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 (Internet Engineering Task Force) a organisé un BoF pour discuter de ces propositions. À la suite de cette réunion, l'IETF a fini par créer le groupe de travail MARID.
La proposition d'identification de l'appelant 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 comme par DomainKeys (Tous les autres brouillons LMAP ont utilisé l'enveloppe SMTP.)
* Questions particulières sur les brevets et les licences.

## Activités de MARID

Le groupe de travail a décidé de différer la question des identités SMTP RFC 2821 - c'est-à-dire MAIL FROM géré par SPF, ou HELO géré par CSV et SPF - en faveur des identités RFC 2822 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$^,$.
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 et l'ID de l'expéditeur 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 auprès de l'IESG et de l'IAB.