Groupe de travail Réseau

Extension de service Pas de démarchage du protocole simple de transfert de messagerie (SMTP)

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document propose une extension au protocole simple de transfert de messagerie (SMTP, Simple Mail Transfer Protocol) pour un équivalent dans la messagerie électronique du signe "Pas de démarchage" du monde réel. En plus de l'extension de service, sont décrits un nouvel en tête de message et des extensions à l'en-tête de message "reçu" existant.

Table des Matières

1. Introduction

1.1 La pandémie du pourriel

1.2 Pas de démarchage dans la réalité

1.3 Pas de démarchage et messagerie électronique

2. Extension de service SMTP No-Soliciting

2.1 Échange EHLO

2.2 Mots-clés de classe de sollicitation

2.3 La commande MAIL FROM

2.4 Rapport d'erreur et codes d'état de messagerie améliorée

2.5 En-tête de messagerie Solicitation

2.6 Insertion des mots-clés de sollicitation dans les camps de Trace

2.7 Relais des messages

2.8 Pas de classe de sollicitation par défaut

3. Considérations pour la sécurité

4. Considérations relatives à l'IANA

4.1 Le registre des paramètres de messagerie

4.2 Champs Trace

4.3 L'en-tête de messagerie Sollcitation

5. Remerciements de l'auteur

6. Références

6.1 Références normatives

6.2 Références informatives

Appendice A Recueil des descriptions en ABNF (normative)

La messagerie en vrac non sollicitée (UBE, Unsolicited Bulk Email) plus connue sous le nom de pourriel (spam), est devenue une des questions les plus urgentes de l'Internet. Une étude souvent citée estimait que les pourriels ont coûté 13 milliards de $ aux opérateurs en 2003 [Ferris]. En avril 2003, AOL a révélé qu'il avait bloqué 2,37 milliards de UBE en un seul jour [CNET]. Et, signe sûr que l'UBE est devenue une question urgente, de nombreux politiciens ont commencé à faire des déclarations et des prescriptions pour combattre cette épidémie [Schumer], [FTC].

Divers mécanismes ont été proposés par la communauté technique et/ou mis en œuvre pour combattre l'UBE:

o Les listes blanches sont des listes de non diffuseurs de pourriels connus. Par exemple, Habeas, Inc. entretient une liste des utilisateur d'Habeas (HUM, Habeas User List) de personnes qui se sont engagées à ne pas diffuser de pourriels. En incluant un haïku dans les en-têtes de messagerie et en appliquant un droit de copie sur ce poème, ils mettent en application leur engagement anti pourriel [Habeas].

o Les listes noires sont des listes de diffuseurs de pourriels connus ou de FAI qui permettent les pourriels [ROKSO].

o Les filtres à pourriels fonctionnement du côté client ou du côté serveur pour filtrer les pourriels sur la base des listes blanches, des listes noires, et d'une analyse du texte et de l'en-tête [Assassin].

o Un grand nombre de documents traitent des considérations techniques globales pour le contrôle de l'UBE [crocker-spam-techconsider], des considérations de fonctionnement pour les agents SMTP [RFC2505], et de diverses extensions aux protocoles pour prendre en charge l'identification et le filtrage des UBE [danisch-dns-rr-smtp], [RFC3685], [crouzet-amtp].

o Diverses propositions ont été avancées pour des listes de "pas de pourriel", du genre de la liste "Ne pas appeler" de la Commission fédérale du commerce pour le démarchage par téléphone [FTC.TSR].

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT" et "FACULTATIF" dans ce document sont à interpréter comme décrit dans le BCP 14 [RFC2119].

Il est fréquent que des municipalités exigent des démarcheurs qu'ils se fassent enregistrer auprès des services municipaux. Et dans de nombreux cas, les municipalités interdisent le démarchage dans les résidences où les occupants ont affiché un signe à cet égard. Par exemple, la ville de West Newbury, Massachusetts, exige :

"C'est une infraction pour tout démarcheur ou solliciteur d'entrer dans des locaux professionnels ou d'habitation portant un signe ou affiche "Défense d'entrer" ou "Pas de démarchage". C'est de plus une infraction pour un démarcheur ou solliciteur d'ignorer l'injonction d'un résident ou d'un employé de ne pas faire de démarchage, ou de rester dans une propriété privée après que son propriétaire ait indiqué que le démarcheur ou solliciteur n'est pas le bienvenu" [Newbury].

Les exigences d'enregistrement des démarcheurs, en particulier ceux qui démarchent pour des raisons politiques ou religieuses, ont fait l'objet d'une longue série d'affaires judiciaires. Cependant, les tribunaux ont généralement reconnu que les individus peuvent afficher "Pas de démarchage" et que les autorités peuvent mettre en application le souhait des citoyens. Dans une affaire récente ou des témoins de Jehova contestaient une exigence d'enregistrement dans la ville de Stratton, Connecticut, en disant qu'ils recevaient leur autorité des Écritures, et pas de la cité. Cependant, la cour a noté :

"Une section de l'ordonnance que ne contestent pas les requérants établit une procédure par laquelle un résident peut interdire le démarchage même aux détenteurs de permis. Si le résident remplit un formulaire d'enregistrement d'interdiction du démarchage à la mairie, et affiche aussi un signe 'pas de démarchage' sur sa propriété, aucun démarcheur non invité ne peut entrer dans sa propriété... " [Watchtower].

Même le gouvernement, qui a un devoir de protection de la libre expression, peut interdire l'utilisation du démarchage sur les propriétés de l'État. Dans un cas, par exemple, il a été admis qu'un district scolaire donne accès à son système interne de messagerie électronique au syndicat des enseignants, mais qu'il n'était pas tenu de le faire pour un syndicat rival qui tentait de s'implanter parmi les enseignants. La cour a estimé que lorsque l'endroit n'est pas un forum public traditionnel "et que les autorités n'ont pas dédié ces locaux à une activité relevant du Premier Amendement, c'est seulement le caractère raisonnable d'une telle réglementation qui est examiné" [Perry].

Les tribunaux ont constamment admis que l'État a des motifs irrésistibles de sécurité publique pour réglementer le démarchage. Dans Cantwell contre l'État du Connecticut, la Cour Suprême a décidé que "un État peut protéger ses citoyens contre le démarchage frauduleux en exigeant d'un étranger à la communauté, avant de lui permettre de solliciter publiquement des fonds quelqu'en soit l'objet, qu'il établisse son identité et son autorité à agir pour la cause qu'il prétend représenter" [Cantwell]. Et dans Martin contre Ville de Struthers, la cour note que "des cambrioleurs se font fréquemment passer pour des démarcheurs, soit afin d'avoir un prétexte pour découvrir si une maison est vide et donc propice à un cambriolage, soit afin de se renseigner sur la disposition des lieux afin de pouvoir y retourner plus tard" [Martin]. La question de la sécurité publique s'applique très bien à la messagerie électronique, où des virus peuvent facilement être introduits, par opposition aux sollicitations téléphoniques où la sécurité publique est beaucoup moins en cause.

Cette analyse est centrée sur les USA, ce qui est en partie dû aux origines de l'auteur. Cependant, le concept d'interdiction des sollicitation non désirées s'étend aux autres pays :

o À Hong Kong, les bureaux affichent fréquemment les mots "Pas de démarchage".

o Au Royaume-Uni, où le porte à porte est très courant, les mentions "Pas de démarchage" le sont tout autant.

o En Australie, où le porte à porte ne paraît pas être un problème social pressant, la pratique de glisser des publicités sous les essuie glaces des voitures en stationnement est devenue une infraction.

o En France, où existe une longue tradition de sollicitations de porte à porte, les immeubles résidentiels utilisent souvent les lois sur la défense d'entrer pour mettre en application des politiques d'interdiction du démarchage.

o Aux Pays-Bas, où le démarchage en porte à porte n'est pas un problème pressent, il est une pratique de distribuer des journaux gratuits dans les boîtes aux lettres. L'équivalent postal des signes "Pas de pub" est assez répandu et sert à faire savoir que ces publications ne sont pas souhaitées.

Beaucoup des propositions anti-pourriel qui ont été avancées ont de grands mérites, cependant aucune d'entre elles ne fait remarquer à l'agent SMTP dans le processus de livraison de la messagerie que le receveur ne souhaite pas recevoir de sollicitations. Un tel signe virtuel servirait à deux fins :

o Il permettrait au système receveur de "faire remarquer" qu'une certaine classe de messagerie électronique n'est pas désirée.

o Si un message est correctement identifié comme appartenant à une certaine classe et si cette classe de messages n'est pas désirée, le transfert du message peut être éliminé. Plutôt que de filtrer après la livraison, l'élimination du transfert du message peut économiser la bande passante du réseau, de l'espace disque, et de la puissance de traitement.

Le présent mémoire précise une série d'extensions à SMTP qui ont les caractéristiques suivantes :

o Une extension de service est décrite pour permettre à un agent de transport de messagerie (MTA, Mail Transport Agent) receveur de signaler au MTA d'envoi que "Pas de démarchage" est appliqué.

o Un champ d'en-tête est défini pour l'envoyeur du message qui lui permet de mettre au message un fanion qui le signale comme conforme à une certaine classe.

o Les champs Trace pour les MTA intermédiaires sont étendus pour permettre au MTA intermédiaire de signaler qu'un message est dans une certaine classe.

Permettre que l'envoyeur d'u message étiquette un message comme étant, par exemple, de la messagerie commerciale non sollicitée avec un contenu réservé aux adultes, permet aux "bons" émetteurs de pourriels de se conformer aux exigences légales d'étiquetage du contenu des autorités gouvernementales, aux accords de licence avec les fournisseurs de service, ou aux conventions imposées par les services de "liste blanche". Pour les émetteurs de messages qui choisissent de ne pas s'en tenir à ces conventions, les champs de trace intermédiaire définis ici permettent aux MTA de destination de prendre les dispositions appropriées sur le message reçu.

La présente extension donne un moyen simple aux envoyeurs, aux MTA, et aux receveurs d'affirmer des mots clés. Cette extension ne traite d'aucune question d'authentification ou de consentement.

Conformément à la [RFC2821], une extension de service SMTP "NO-SOLICITING" est définie. L'extension de service est déclarée durant l'échange initial "EHLO" SMTP. L'extension a un paramètre facultatif, consistant en zéro un ou plusieurs mots-clés de classe de sollicitation. En utilisant la notation décrite dans le format BNF augmenté [RFC2234], la syntaxe est :

Comme on va le décrire plus en détails ci-dessous, la construction "Mots-Clés-de-Sollicitation" est utilisée pour indiquer quelles classes de messages ne sont pas désirées. Un mot-clé qui est présenté durant l'échange "EHLO" initial s'applique à tous les messages échangés dans cette session. Comme il sera aussi décrit plus en détails ci-dessous, des mots-clés supplémentaires peuvent être spécifiés receveur par receveur au titre de la réponse à une commande "RCPT TO".

Les mots-clés présentés durant l'échange initial indiquent qu'aucun démarchage dans les classes désignées n'est effectué pour tous les messages livrés à ce système. C'est équivalent au signe sur la porte d'un immeuble de bureaux qui annonce une politique pour l'ensemble de la compagnie. Par exemple :

Le paramètre "net.example:ADV" à l'extension "NO-SOLICITING" est un exemple de mot-clé de classe de sollicitation, dont la syntaxe est décrite au paragraphe suivant.

Note d'historique : Une proposition similaire avait été avancée en 1999 par John Levine et Paul Hoffman. Cette proposition utilisait la bannière d'accueil de SMTP pour spécifier que la messagerie en vrac non sollicitée était interdite sur un système particulier à travers l'utilisation du mot-clé "NO UCE" [Levine]. Comme le notent les auteurs, leur proposition avait un potentiel de surcharge de la sémantique de la bannière d'accueil, qui peut aussi être utilisée pour d'autres propos (voir par exemple, [Malamud]).

L'extension de service "NO-SOLICITING" utilise des mots-clés de classe de sollicitation pour signifier les classes de sollicitations qui ne sont pas acceptées. Les mots-clés de classes de sollicitation sont séparés par des virgules.

Il n'y a pas de mot-clé de classe de sollicitation par défaut pour le service. En d'autres termes, l'exemple suivant est un "no-op" :

Bien que l'exemple ci-dessus soit un "no-op", il est utile à un MTA qui souhaite passer tous les messages, mais voudrait aussi passer les paramètres "SOLICIT=" message par message. L'exemple ci-dessus invoque l'utilisation de l'extension mais ne signale aucune restriction par classe de message.

L'ensemble initial de mots-clés de classe de sollicitation commence par un nom de domaine avec les étiquettes inversées, suivies par deux points. Par exemple, le nom de domaine "example.com" pourrait être utilisé pour former le commencement d'un mot-clé de classe de sollicitation de "com.example:". Le mot-clé de classe de sollicitation est alors suivi par un ensemble arbitraire de caractères tirés de la construction suivante :

Un mot-clé de classe de sollicitation DOIT faire moins de 1000 caractères. Noter cependant qu'un ensemble de mots-clés utilisé dans les opérations définies dans le présent document doit aussi faire moins de 1000 caractères. Il est donc conseillé aux mises en œuvre de s'en tenir à des mots-clés de classe de sollicitation brefs.

Tout déposant d'un nom de domaine peut définir un mot-clé de classe de sollicitation. La découverte des mots-clés de classe de sollicitation sort du domaine d'application du présent document. Cependant, il est recommandé aux déposants qui définissent des mots-clés de placer la définition de leurs mots-clés de classe de sollicitation sur une URL importante sous leur contrôle afin que les moteurs de recherche et autres mécanismes de découverte puissent les trouver.

Bien que le présent document définisse les mots-clés de classe de sollicitation comme commençant par un nom de domaine inversé suivi par deux points (":"), de futures RFC pourront définir des mécanismes supplémentaires qui ne soient pas en conflit avec ce schéma de dénomination.

Le présent document ne spécifie pas quels mots-clés de classe de sollicitation doivent ou non être utilisés dans un message particulier. L'exigence d'utiliser un mot-clé particulier est une décision de politique qui sort du domaine d'application de ce document. Il est prévu que les organismes de politique pertinents (par exemple, gouvernements, FAI, développeurs, ou autres) spécifient les mots-clés appropriés, la définition de la signification de ces mots-clés, et autres exigences de politique, telles qu'une exigence d'utiliser ou non cette extension dans des circonstances particulières.

Durant les discussions sur la présente proposition, il y a plusieurs suggestions d'abandonner tous les mots-clés de classe de sollicitation et de les remplacer par un mécanisme booléen simple (par exemple, "NO-SOLICITING YES" ou "ADV" ou "UBE"). Avec un tel mécanisme booléen, la présente extension aurait à adopter une définition unique de ce que "YES" ou une autre étiquette signifie. En utilisant l'approche des mots-clés de classe de sollicitation, l'infrastructure de messagerie reste un mécanisme neutre, permettant à différentes définitions de coexister.

"SOLICIT" est défini comme paramètre pour la commande "MAIL FROM". Le paramètre "SOLICIT" est suivi par un signe égal et une liste de mots-clés de classe de sollicitation séparés par des virgules. La syntaxe de ce paramètre est :

; mots-clés-de-sollicitation, utilisé dans la commande MAIL FROM DOIT être identique à ceux de l'en-tête Sollicitation:.

Comme message d'information, les répliques "550" ou "250" à la commande "RCPT TO" peuvent aussi contenir le paramètre "SOLICIT". Si un message est rejeté du fait d'une correspondance de mot-clé de classe de sollicitation, la mise en œuvre DEVRAIT faire écho aux classes de sollicitation qui sont activées. Voir au paragraphe 2.4 des précisons sur les rapports d'erreur.

Le système receveur peut décider message par message de la disposition appropriée des messages :

Dans l'exemple précédant, le MTA receveur retournait un code d'état "550", indiquant que l'un des messages était rejeté. La mise en œuvre fait aussi écho aux mots-clés actuellement établis pour cet utilisateur sur le message d'état "550". Le mot-clé de classe de sollicitation dont il est fait écho est "org.example:ADV:ADLT" qui illustre comment ce mot-clé de classe de sollicitation du receveur a complété la classe de base "net.example:ADV" déclarée dans l'échange "EHLO".

Il est de la responsabilité du MTA de réception de conserver une politique cohérente. Si le MTA de réception rejette un message à cause des mots-clés de classe de sollicitation, le MTA DEVRAIT déclarer ces mots-clés soit dans l'échange "EHLO" initial soit receveur par receveur. De même, un MTA receveur NE DEVRAIT PAS délivrer un message où le "Solicitation:" correspond à un mot-clé de classe de sollicitation qui avait été présenté durant l'échange initial de "EHLO" ou receveur par receveur.

Les développeurs devraient aussi noter que la source des mots-clés de classe de sollicitation utilisés dans la commande "MAIL FROM" DOIT être l'en-tête "Solicitation:" décrit au paragraphe 2.5 et NE DOIT PAS être complétée par des mots-clés de classe de sollicitation supplémentaires déduits des champs de trace de l'en-tête "Received:" qui sont décrits au paragraphe 2.6.

Si une session entre deux MTA utilise les deux extensions "NO-SOLICITING" et les codes d'état de messagerie améliorée définis dans la [RFC3463] et qu'un message est rejeté sur la base de la présence d'un paramètre "SOLICIT", le message d'erreur correct à retourner sera normalement "5.7.1", défini comme "l'envoyeur n'est pas autorisé à envoyer à la destination... (à cause) d'un filtrage par hôte ou par receveur."

D'autres codes, y compris des codes d'état temporaires, peuvent être plus appropriés dans certaines circonstances et les développeurs devraient consulter la [RFC3463] sur ce sujet. Un exemple d'une telle situation pourrait être l'utilisation de quotas ou de restrictions de la taille des messages par classe. Une mise en œuvre PEUT imposer des limites telles que des restrictions de la taille de message sur la base des classes de sollicitation et quand de telles limites sont dépassées elles DEVRAIENT être rapportées en utilisant tout code d'état approprié pour cette limite.

Dans tous les cas, une mise en œuvre DEVRAIT inclure un "Mail-From-Solicit-Parameter" dans une réponse "550" ou autre qui rejette une livraison de message. Le paramètre DEVRAIT inclure le ou les mots-clés de classe de sollicitation qui correspondaient. En plus du ou des mots-clés de classe de sollicitation qui correspondaient, une mise en œuvre PEUT inclure des mots-clés de classe de sollicitation supplémentaires qui sont activés.

Conformément à la [RFC2822], un nouveau champ d'en-tête "Solicitation:" est défini qui contient un ou plusieurs mots-clés de classe de sollicitation.

Plusieurs propositions, en particulier de légistes, ont suggéré d'exiger l'utilisation de mots-clés dans l'en-tête "Subject:". Bien que l'incorporation d'informations dans l'en-tête "Subject:" puisse fournir des indices visuels aux usagers finaux, elle ne donne pas un ensemble d'indices directs aux programmes informatiques tels que les agents de transfert de messagerie. Comme avec l'incorporation d'un message "Pas de démarchage" dans une bannière d'accueil, cela surcharge la sémantique de l'en-tête "Subject:". Bien sûr, il n'y a pas de raison pour que les deux mécanismes ne puissent être utilisés, et dans tous les cas, l'en-tête "Solicitation:" pourrait être inséré automatiquement par l'agent d'utilisateur de messagerie (MUA, Mail User Agent) de l'envoyeur sur la base du contenu de la ligne de sujet.

L'en-tête de message "Solicitation:" n'est disponible que pour le client d'envoi. Les RFC 2821 et 2822 disent assez précisément que les MTA intermédiaires ne doivent pas changer les en-têtes de message, à la seule exception du champ de trace "Received:". Comme de nombreux systèmes actuels utilisent un relais intermédiaire pour détecter la messagerie non sollicitée, on décrit un ajout à l'en-tête "Received:".

La [RFC2821] expose les productions suivantes pour l'en-tête "Received:" dans un message électronique :

Le paramètre "Mail-From-Solicit-Parameter" défini au paragraphe 2.3 ci-dessus est une forme restreinte de ctext, donnant la production suivante :

On devrait noter que les mots-clés présentés dans les champs trace peuvent n'être pas en accord avec ceux qui se trouvent dans l'en-tête "Solicitation:" et les champs trace peuvent exister même si l'en-tête n'est pas présent. Pour déterminer quels mots-clés sont applicables à un échange de messages particulier, les mises en œuvre DEVRAIENT examiner tous les mots-clés qui se trouvent dans l'en-tête "Solicitation:". Les mises en œuvre PEUVENT examiner les autres mots-clés trouvés dans les champs trace.

L'extension de service "NO-SOLICITING", si elle est présente, s'applique à tous les messages traités par l'agent de transfert de message (MTA), y compris les messages destinés à être relayés à un autre système.

Les mots-clés de classe de sollicitation fournis par un client dans un paramètre "SOLICIT" sur une commande "MAIL FROM" DEVRAIENT être obtenus du champ "Solicitation:" dans l'en-tête de message. Un client SMTP DEVRAIT cependant vérifier que la liste des mots-clés de classe de sollicitation obtenue du champ "Solicitation:" utilise une syntaxe valide avant de transporter son contenu. Un serveur SMTP DEVRAIT établir ce paramètre après avoir détecté la présence du champ d'en-tête "Solicitation:" lors de la réception d'un message provenant d'un MTA non conforme.

Les mises en œuvre de l'extension de service "NO-SOLICITING" NE DEVRAIENT PAS activer de mots-clés de classe de sollicitation spécifiques par défaut dans leur logiciel. Il semble que certaines politiques envisagent un logiciel de filtrage par défaut comme première restriction à l'égard du discours commercial. En d'autres termes, parce que la personne qui installe et utilise le logiciel n'a pas fait un choix explicite d'activer un certain type de filtrage, certains pourraient en tirer argument pour dire qu'un tel filtrage n'était pas souhaité.

De même, il est recommandé qu'un administrateur de système qui installe un logiciel NE DEVRAIT PAS activer de filtrage par défaut supplémentaire selon le receveur pour un utilisateur. Encore une fois, les utilisateurs individuels devraient demander spécifiquement tous mots-clés de classe de sollicitation supplémentaires.

Le mécanisme d'un utilisateur individuel pour communiquer son désir d'activer certains types de filtrage sort du domaine d'application du présent document.

La présente extension ne fournit pas d'authentification des envoyeurs ni d'autres mesures destinées à promouvoir des mesures de sécurité durant le processus d'échange de message.

En particulier, le présent document ne traite pas des circonstances dans lesquelles un envoyeur de messagerie électronique devrait ou ne devrait pas utiliser cette extension et ne traite pas du problème de savoir si le consentement a été donné aux messages envoyés.

Cela pourrait conduire à un scénario dans lequel un envoyeur de messagerie électronique commence à utiliser cette extension bien avant que la majorité des utilisateurs terminaux n'aient commencé à l'utiliser. Dans ce scénario, l'envoyeur peut souhaiter utiliser l'absence de l'extension sur le MTA de réception comme impliquant le consentement à la réception des messages. La non utilisation de l'extension "Pas de démarchage" par un MTA de réception NE DEVRA PAS indiquer le consentement.

1. Ajout de l'extension de service "Pas de démarchage" au registre des paramètres de messagerie.

Le registre des paramètres de messagerie de l'IANA tient la documentation des extensions de service de SMTP. L'extension de service "Pas de démarchage" a été ajoutée à ce registre de la façon suivante :

La longueur maximum des mots-clés de sollicitation est de 1000 caractères. Le paramètre "SOLICIT=" est défini pour une utilisation sur la commande MAIL FROM. La longueur potentielle de la commande MAIL FROM est donc portée à 1007 caractères.

Le registre des paramètres de messagerie devra être modifié pour noter l'utilisation de la possibilité de commentaires dans les champs Trace pour indiquer les mots clés de classe de sollicitation.

Selon la [RFC3864], le champ d'en-tête "Solicitation:" est ajouté au registre permanent de champ d'en-tête de message de l'IANA. Le gabarit d'enregistrement est le suivant :

L'auteur tient à remercier Rebecca Malamud pour les nombreuses discussions et idées qui ont conduit à cette proposition, ainsi que C. Klensin et Marshall T. Rose pour leurs nombreux apports sur la façon dont elle pourrait être mise en œuvre dans SMTP. Eric Allman, Harald Alvestrand, Steven M. Bellovin, Doug Barton, Kent Crispin, Dave Crocker, Ned Freed, Curtis Generous, Arnt Gulbrandsen, John Levine, Keith Moore, Hector Santos, Ted Hardie, Paul Vixie et Pindar Wong ont gentiment accepté de relire ce document et/ou ont fait des suggestions pour son amélioration. Les informations sur le système juridique hors des USA ont été collectées par Rob Blokzijl, Jon Crowcroft, Christian Huitema, Geoff Huston et Pindar Wong. John Levine a souligné le contraste entre cette proposition et les listes "pas de pourriel". Comme toujours, toute erreur et omission est de la seule faute de l'auteur.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

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

[crocker-spam-techconsider] Crocker, D., "Technical Considerations for Spam Control Mechanisms", Travail en cours, février 2004.

[crouzet-amtp] Crouzet, B., "Authenticated Mail Transfer Protocol", Travail en cours, mai 2004.

[danisch-dns-rr-smtp] Danisch, H., "The RMX DNS RR and method for lightweight SMTP sender authorization", Travail en cours, août 2004.

[RFC2505] G. Lindberg, "Recommandations contre les pourriels dans les MTA de SMTP", février 1999. (BCP0030)

[RFC3685] C. Daboo, "Filtrage de messagerie SIEVE : Extensions Spamtest et VirusTest", février 2004. (Obsolète, voir RFC5235) (P.S.)

[Watchtower] U.S. Supreme Court, "Watchtower Bible & Tract Society of New York, Inc., et al. v. Village of Stratton et al.", 122 S.Ct. 2080 (2002), juin 2002, <http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=000&invol=00-1737>

; mots-clés-de-sollicitation, utilisé dans la commande MAIL FROM ; DOIT être identique à celui de l'en-tête Solicitation:.

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs 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, le IETF TRUST 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.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Le financement de la fonction d'édition des RFC est actuellement assuré par la Internet Society.

Groupe de travail Réseau	C. Malamud, Memory Palace Press
Request for Comments: 3865	septembre 2004
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle

Mots-clés	Description	Référence
NO-SOLICITING	Notification de non sollicitation.	RFC3865

Extension de service	Mot-clé de EHLO	Paramètres	Référence
No Soliciting	NO-SOLICITING	mots-clés de sollicitation	RFC3865