List-Id : un champ structuré et un espace de nom pour l'identification de listes de diffusion

Statut du présent Mémo

La présente RFC spécifie un protocole de normalisation pour la communauté Internet et appelle à des discussions et suggestions pour son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est soumise à aucune restriction.

Déclaration de Copyright

Copyright (C) The Internet Society (2001). Tous droits réservés.

Résumé

Les logiciels qui traitent les messages des listes de diffusion de messagerie électronique (les serveurs et les agents d'utilisateur) ont besoin d'un moyen pour identifier de façon fiable les messages qui appartiennent à une liste de diffusion particulière. Avec l'avénement des en-têtes de gestion de liste, il est devenu encore plus important de fournir un identifiant unique pour une liste de diffusion sans considération de l'hôte particulier qui sert de processeur de liste à un moment donné.

L'en-tête List-Id donne une localisation standard pour un tel identifiant. De plus, on décrit un espace de noms pour les identifiants de liste fondés sur les noms de domaine pleinement qualifiés. Cet espace de noms est destiné à garantir l'unicité pour les propriétaires de liste qui l'exigent, tout en permettant un espace de noms moins rigoureux pour les utilisations expérimentales et personnelles.

En incluant le champ List-Id, les serveurs de listes peuvent rendre plus facile la fourniture par les clients de messagerie des outils automatiques pour que les usagers effectuent les fonctions de listes. L'identifiant de liste peut servir de clé pour rendre plus faciles de nombreuses tâches de traitement automatisées, et donc les rendre plus largement disponibles.

1. Introduction

Les listes de diffusion de l'Internet ont évolué en des formes très sophistiquées pour les communications et la collaboration de groupe ; cependant, les changements correspondants dans les infrastructures sous-jacentes sont restés à la traîne. De récentes propositions comme la [RFC2369] ont étendu les fonctionnalités que peut fournir l'agent d’utilisateur de messagerie (MUA, mail user agent) en permettant plus d'informations dans chaque message envoyé par le logiciel de distribution de la liste de diffusion.

La mise en œuvre réelle de telles fonctionnalités dans l'agent d’utilisateur de messagerie dépend de la capacité à identifier précisément les messages comme appartenant à une liste de diffusion particulière. Le problème devient alors de savoir quel attribut ou propriété utiliser pour identifier une liste de diffusion. Le candidat le plus vraisemblable est l'adresse de soumission de la liste de diffusion elle-même. Malheureusement, lorsque l'hôte serveur de la liste, le logiciel de traitement de la liste, ou la politique de soumission de la liste change, l'adresse de soumission elle-même peut changer. Cela cause de grande difficultés au traitement et au filtrage automatique.

Afin de poursuivre l'automatisation du traitement (et le rendre plus précis) qu'un agent logiciel peut effectuer, il faut qu'il y ait un identifiant unique pour la liste de diffusion. Cet identifiant peut être simplement utilisé pour une correspondance de chaîne dans un filtre, ou il peut être utilisé dans des systèmes plus sophistiqués pour identifier les messages de façon univoque comme appartenant à une liste de diffusion particulière indépendamment de l'hôte particulier qui livre les messages réels. Cet identifiant peut aussi agir comme une clé dans une base de données de listes de diffusion.

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans la RFC2119.

2. Syntaxe d'identifiant de liste

L'identifiant de liste va, dans la plupart des cas, apparaître comme un nom d'hôte dans un domaine du propriétaire de la liste. En d'autres termes, le système de nom de domaine est utilisé pour déléguer l'autorité de l'espace de nom pour les identifiants de liste tout comme si il était utilisé pour répartir cette autorité pour d'autres ressources de l'Internet.

L'utilisation du système des noms de domaine comme base de l'espace de nom des identifiants de liste est destinée à faire passer une structure d'autorité dans un nouveau domaine d'application. En utilisant le système de noms de domaines pour déléguer l'autorité de l'espace de nom d'identifiant de liste, on voit instantanément clairement qui a le droit de créer un identifiant de liste particulier, et cela sépare l'identifiant de liste de tout hôte ou mécanisme de livraison particulier. Seul le détenteur des droits d'un domaine ou sous-domaine a l'autorité pour créer des identifiants de liste dans l'espace de noms de ce domaine. Par exemple, seul le détenteur des droits du domaine "acm.org" a l'autorité pour créer des identifiants de liste dans le domaine "acm.org".

Bien qu'il soit parfaitement acceptable qu'un identifiant de liste soit complètement indépendant du nom de domaine de la machine hôte qui dessert la liste de diffusion, le propriétaire d'une liste de diffusion NE DOIT PAS générer d'identifiants de liste dans tout espace de nom de domaine pour lequel il n'a pas autorité. Par exemple, un service d'hébergement de liste de diffusion peut choisir d'allouer des identifiants de liste dans leur propre espace de nom fondé sur le domaine, ou il peut permettre à ses clients (les propriétaires de liste) de fournir des identifiants de liste dans un espace de noms pour lequel le propriétaire a autorité.

Si le propriétaire de la liste n'a pas l'autorité pour créer un identifiant de liste dans un espace de nom fondé sur le domaine, il peut créer des identifiants de liste non gérés dans le domaine spécial non géré "localhost". Cela s'appliquerait aux utilisateurs personnels, ou aux usagers incapablee de s'offrir les frais d'enregistrement d'un nom de domaine.

La syntaxe d'un identifiant de liste en ABNF [RFC2234] est la suivante :

list-id = list-label "." list-id-namespace

list-label = dot-atom-text

list-id-namespace = domain-name / unmanaged-list-id-namespace

unmanaged-list-id-namespace = "localhost"

domain-name = dot-atom-text

Où :

dot-atom-text est défini dans la [RFC0822]

"localhost" est un nom de domaine réservé qui est défini dans la [RFC2606]

De plus, un identifiant de liste (list-id) NE DOIT PAS faire plus de 255 octets, pour la compatibilité future. Il devrait être noté que "localhost" n'est pas valide pour la règle domain-name.

3. Champ d'en-tête List-Id

Le présent document présente un champ d'en-tête qui va fournir un identifiant pour une liste de distribution de messagerie électronique. Cet en-tête DEVRAIT être inclus dans tous les messages distribués par la liste (y compris les réponses de commande aux utilisateurs individuels) et dans les autres messages qui s'appliquent clairement à cette liste distincte particulière. Il DOIT n'y avoir pas plus d'un de chaque champ présent dans un message donné.

Ce champ DOIT être généré uniquement par le logiciel de liste de diffusion, et pas pas l'utilisateur final.

Le contenu de l'en-tête Liste-Id consiste essentiellement en un identifiant inclus entre des crochets angulaires ('<', '>'), les espaces blanches internes étant ignorées. Les MTA NE DOIVENT PAS insérer d'espaces blanches au sein des crochets, mais les applications client devraient traiter de telles espaces blanches, qui pourraient être insérées par des MTA au mauvais comportement, comme des caractères à ignorer.

Les champs d'en-tête de liste sont soumis aux restrictions de codage et de caractères des en-têtes de messagerie décrites dans la [RFC0822].

L'en-tête Liste-Id PEUT facultativement inclure une description en l'incluant comme une "phrase" [RFC0822] avant l'identifiant de liste entre crochets angulaires. Le MUA PEUT choisir d'utiliser cette description dans son interface d'utilisateur ; cependant, tout MUA qui a l'intention de faire usage de la description devrait être prêt à analyser et décoder correctement toutes les chaînes codées ou autres composants de phrase légaux. Pour de nombreux MUA, l'analyse de l'en-tête Liste-Id va simplement consister à extraire l'identifiant de liste entre les crochets angulaires de délimitation.

La syntaxe de l'en-tête Liste-Id est la suivante :

list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF

où phrase et CRLF sont définis dans la [RFC0822]. À la différence de la plupart des en-têtes de la [RFC0822], l'en-tête Liste-Id ne permet pas la libre insertion d'espaces et de commentaires autour de jetons. Tout texte descriptif doit être présenté dans le composant de phrase facultaif de l'en-tête.

Exemples :

List-Id: Liste de diffusion d'en-tête de liste <list-header.nisto.com>

List-Id: <commonspace-users.list-id.within.com>

List-Id: "Liste des blagues personnelles de Lena" <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>

List-Id: "Liste CMU interne" <0Jks9449.list-id.cmu.edu>

List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>

4. Persistance des identifiants de liste

Bien que l'identifiant de liste PUISSE être changé par l'administrateur de la liste de diffusion, cela n'est pas souhaitable. (Noter qu'il n'y a pas d'inconvénient à changer la portion description de l'en-tête Liste-Id.) Un MUA peut ne pas reconnaître le changement de l'identifiant de liste parce que le MUA DEVRAIT traiter un identifiant de liste différent comme une liste différente. À ce titre, l'administrateur de la liste de diffusion DEVRAIT éviter de changer l'identifiant de liste même lorsque change l'hôte qui dessert la liste. D'autre part, la transition d'un espace de nom d'identifiant de liste non géré informel à un espace de nom de domaine est une raison acceptable de changer l'identifiant de liste. Également, si l'objet de la liste change suffisamment, l'administrateur peut souhaiter retirer la liste précédente et son identifiant associé pour commencer une nouvelle liste reflétant le nouvel objectif.

5. Unicité des identifiants de liste

La présente proposition cherche à niveler le processus administratif existant en place pour l'allocation de nom de domaine. En particulier, on exploite le fait que la propriété d'un nom de domaine crée un espace de nom qui, par définition, peut être utilisé pour créer des identifiants univoques au sein du domaine.

De plus, il doit y avoir un mécanisme pour l'identification des listes de diffusion qui sont administrées par une entité sans accès administratif à un domaine. Dans ce cas, une heuristique générale peut être donnée pour réduire les chances de collision, mais cela ne peut être garanti. Si un propriétaire de liste exige une garantie, il est libre d'enregistrer un nom de domaine sous son contrôle.

Il est suggéré, mais pas exigé, que les identifiants de liste soient créés dans un sous-domaine de "list-id" au sein d'un domaine donné. Cela peut aider à réduire les conflits internes entre les administrateurs des sous-domaines de grosses organisations. Par exemple, des identifiants de liste à "within.com" sont générés dans le sous-domaine de "list-id.within.com".

Les List-ID qui ne se terminent pas par ".localhost" DOIVENT être uniques au monde en référence à toutes les autres listes de diffusion.

Les propriétaires de liste qui souhaitent utilise l'espace de nom "localhost" spécial pour leur identifiant de liste DEVRAIENT utiliser le mois et l'année (sous la forme MMAAAA) auquel ils créent l'identifiant de liste comme "sous-domaine" de l'espace de nom "localhost". De plus, une portion de l'identifiant de liste DOIT être une chaîne générée de façon aléatoire. Les propriétaires de liste qui génèrent de tels identifiants devraient se référer à [MSGID] pou d'autres suggestions sur la génération d'un identifiant univoque, et à la [RFC1750] pour des suggestions sur la génération de nombres aléatoires. En particulier, les identifiants de liste qui ont un composant aléatoire DEVRAIENT contenir un codage hexadécimal de 128 bits d'aléa (résultant en 32 caractères hexadécimaux) au titre de l'identifiant de liste

Et donc, des identifiants de liste tels que <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> et <da39efc25c530ad145d41b86f7420c3b.051998.localhost> se conforment à ces lignes directrices, alors que <lenas-jokes.021999.localhost> et <mylist.localhost> ne le font pas. Un propriétaire de liste particulier qui a plusieurs listes PEUT choisir d'utiliser le même numéro aléatoire de sous-domaine pour générer les identifiants de liste pour chacune des listes.

Les List-ID qui se terminent par ".localhost" n'ont pas la garantie d'être uniques au monde.

6. Opérations sur les identifiants de liste

Une seule opération est définie pour les identifiants de liste, celle d'égalité insensible à la casse (voir le paragraphe 3.4.7. de la [RFC0822]). La seule utilisation d'un identifiant de liste est pour identifier une liste de diffusion, et la seule utilisation de l'en-tête Liste-Id est pour marquer un message particulier comme appartenant à cette liste. L'opération de comparaison DOIT ignorer toute partie de l'en-tête Liste-Id en dehors des crochets angulaires. Le MUA PEUT choisir d'informer l'usager si le nom descriptif d'une liste de diffusion change.

7. Prise en charge des listes incorporées

Une liste qui est une sous-liste d'une autre liste dans une hiérarchie de listes de diffusion incorporées NE DOIT PAS modifier le champ d'en-tête Liste-Id ; cependant, cela ne sera possible que lorsque la liste de diffusion incorporée connaît la relation entre elle et ses listes de diffusion "parentes". Si un processeur de liste de diffusion rencontre un champ d'en-tête Liste-Id provenant de toute source inattendue, il NE DEVRAIT PAS le passer à la liste Cela implique que les processeurs de listes de diffusion puissent être mis à jour pour prendre correctement en charge les List-Id pour les listes incorporées.

8. Considérations pour la sécurité

Il y a très peu de nouveaux problèmes de sécurité générés par la présente proposition. Les en-têtes de message sont une norme existante, conçue pour s'accommoder facilement de nouveaux types. Il peur y avoir des problèmes avec des en-têtes falsifiés, mais ce problème est inhérent à la messagerie Internet, et non spécifique de l'en-tête décrit dans le présent document. De plus, ses implications sont relativement sans dommage.

Comme mentionné plus haut, les processeurs de liste de diffusion NE DEVRAIENT PAS permettre à des champs générés par quelque utilisateur que ce soit de passer par leurs listes, au risque de plonger les utilisateurs dans la confusion et avec une création potentielle de problèmes de sécurité.

Du côté client, un identifiant de liste falsifié peut casser le traitement automatisé. L'identifiant de liste (sous sa forme actuelle) NE DEVRAIT PAS être utilisé comme indication de l'authenticité du message.

9. Remerciements

Les nombreux participants aux listes de diffusion List-Header [LISTHEADER] et ListMom-Talk [LISTMOM] ont beaucoup contribué à la formation et à la structure de ce document.

Grant Neufeld <grant@acm.org> été au centre des premières discussions, et a donc été essentiel dans la création de ce document.

Références

[LISTHEADER] Liste de diffusion "List-Header" à list-header@list.nisto.com <http://www.nisto.com/listspec/mail/> <http://www.nisto.com/listspec/>

[LISTMOM] Liste de diffusion "ListMom-Talk" à listmom-talk@skyweyr.com <http://cgi.skyweyr.com/ListMom.Home>

[MSGID] J. Zawinski, M. Curtin, "Recommendations for generating Message IDs", Travail en cours.

[RFC0822] D. Crocker, "Norme pour le format des messages de texte de l'ARPA-Internet", STD 11, août 1982. (Obsolète, remplacée par la RFC5322)

[RFC1750] D. Eastlake, 3^rd et autres, "Recommandations d'aléa pour la sécurité", décembre 1994. (Info., remplacée par la RFC4086)

[RFC2234] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

[RFC2369] G. Neufeld, J. Baer, "Utilisation des URL comme méta syntaxe pour les commandes centrales de liste de messagerie et leur transport à travers les champs d'en-tête de message", juillet 1998. (P.S.)

[RFC2606] D. Eastlake 3^rd et A. Panitz, "Noms réservés de niveau supérieur du DNS", BCP 32, juin 1999.

[RFC2822] P. Resnick,éditeur, "Format de message Internet", avril 2001. (Remplace la RFC0822, STD 11, Remplacée par RFC5322)

Adresse des auteurs

Déclaration de droits de reproduction

Copyright (C) The Internet Society (2001). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.