Aller au contenu
Wikipédia l'encyclopédie libre

MARID

Un article de Wikipédia, l'encyclopédie libre.
Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.
Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.

La mise en forme de cet article est à améliorer ().

La mise en forme du texte ne suit pas les recommandations de Wikipédia : il faut le « wikifier ».

Comment faire ?

Les points d'amélioration suivants sont les cas les plus fréquents :

  • Les titres sont pré-formatés par le logiciel. Ils ne sont ni en capitales, ni en gras.
  • Le texte ne doit pas être écrit en capitales (les noms de famille non plus), ni en gras, ni en italique, ni en « petit »...
  • Le gras n'est utilisé que pour surligner le titre de l'article dans l'introduction, une seule fois.
  • L'italique est rarement utilisé : mots en langue étrangère, titres d'œuvres, noms de bateaux, etc.
  • Les citations ne sont pas en italique mais en corps de texte normal. Elles sont entourées par des guillemets français : « et ».
  • Les listes à puces sont à éviter, des paragraphes rédigés étant largement préférés. Les tableaux sont à réserver à la présentation de données structurées (résultats, etc.).
  • Les appels de note de bas de page (petits chiffres en exposant, introduits par l'outil «  Source ») sont à placer entre la fin de phrase et le point final[comme ça].
  • Les liens internes (vers d'autres articles de Wikipédia) sont à choisir avec parcimonie. Créez des liens vers des articles approfondissant le sujet. Les termes génériques sans rapport avec le sujet sont à éviter, ainsi que les répétitions de liens vers un même terme.
  • Les liens externes sont à placer uniquement dans une section « Liens externes », à la fin de l'article. Ces liens sont à choisir avec parcimonie suivant les règles définies. Si un lien sert de source à l'article, son insertion dans le texte est à faire par les notes de bas de page.
  • La présentation des références doit suivre les conventions bibliographiques. Il est recommandé d'utiliser les modèles {{Ouvrage}}, {{Chapitre}}, {{Article}}, {{Lien web}} et/ou {{Bibliographie}}. Le mode d'édition visuel peut mettre en forme automatiquement les références.
  • Insérer une infobox (cadre d'informations à droite) n'est pas obligatoire pour parachever la mise en page.

Pour une aide détaillée, merci de consulter Aide:Wikification.

Si vous pensez que ces points ont été résolus, vous pouvez retirer ce bandeau et améliorer la mise en forme d'un autre article.

MARID est 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 .

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 , 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[2] .

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[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] .

Activités de MARID

[modifier | modifier le code ]

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.

Références

[modifier | modifier le code ]

Liens externes

[modifier | modifier le code ]

AltStyle によって変換されたページ (->オリジナル) /