| Index | Documentation | Accueil |
|
Traduction approximative de la RFC 822 en français. |
|
Rends
13 août 1982
revue et corrigé par David H. Crocker
Dept. of Electrical Engineering University of Delaware, Newark, DE 19711
Réseau: DCrocker@UDel-Relay
Ce document modifie les spécifications de la RFC numéro 733, au lieu de servir les besoins de l'Internet ARPA qui deviennent plus important et plus complexes. Quelques caractéristiques de la RFC 733 sont supprimées afin d'obtenir un niveau d'acceptation suffisant. Au lieu de simplifier le standard et les logiciels qui y adhèrent, ces caractéristiques ont été supprimés. Un schéma d'adressage différent est utilisé, pour manipuler le courrier inter réseau ; et le concept de retransmission a été introduit.
Cette spécification a pour but quelle soit utilisée dans l'Internet ARPA. Cependant, une attention particulière a été donnée pour la rendre libre de n'importe quelle dépendance vis a vis de son environnement, ainsi elle peut s'appliquer à d'autres systèmes de messageries en mode textes situé sur d'autres réseaux.
La spécification de la RFC nº733 a pris plus d'un an, utilisant l'environnement de courrier ARPANET, lui-même, afin de fournir un forum permanent, pour discuter du contenu a y inclure. Plus d'une vingtaine d'individus, répartis au travers du pays, participèrent aux discussions originelles. Le développement de cette spécification révisée, a utilisé, de la même manière, les discussions de groupe s'appuyant sur le courrier. La plupart des efforts de spécification ont fortement bénéficié des commentaires et idées des participants.
La syntaxe du standard, de la RFC numéro 733, était à l'origine spécifie dans le meta-language de Forme Backus-Naur (BNF). Ken L. Harrenstien, de SRI International, a été responsable du réencodage de la BNF vers une BNF étendue qui crée une représentation plus petite et plus simple à comprendre.
Ce standard spécifie la syntaxe pour des messages de type texte qui sont envoyés à des utilisateurs d'ordinateurs, au travers du système de "courrier électronique". Ce standard remplace celui qui était spécifié dans la Request for Comments numéro 733 ARPANET, "Standard for the Format of ARPA Network Text Messages".
Dans ce contexte, les messages sont examinés comme ayant une enveloppe et un contenu. L'enveloppe contient les informations nécessaires pour effectuer la transmission et la distribution. Le contenu contient l'objet à livrer au destinataire. Ce standard s'applique seulement au format et parfois à la sémantique du contenu des messages. Il ne contient aucune spécification sur les informations contenues dans l'enveloppe.
Cependant, quelques systèmes de message peuvent utiliser une partie de l'information qui est situé dans le contenu pour créer une enveloppe. Ce standard a pour intention de faciliter l'acquisition de telles informations par programmes.
Certains systèmes de messagerie peuvent enregistrer les messages dans des formats qui diffèrent de celui définit par ce standard. Ici, cette spécification est à prendre uniquement comme la définition du format du contenu à passer ENTRE serveurs hôtes.
| Remarque: | Ce standard N'a PAS l'intention de dicter, le format interne utilisé par les sites, ni même les caractéristiques des systèmes de message qu'ils sont censés supporter ou n'importe quelle caractéristique des programmes de l'interface qui crée ou lit les messages. |
Une distinction doit être faite entre les spécifications REQUISE et celles qui sont AUTORISEE. Les messages peuvent être construit de façon complexe et de façon riche avec des composants ayant des formes structurées d'information ou alors peut garder une forme simple et petite avec un minimum d'information complexe. Bien sur, le standard simplifie l'interprétation des différents formats visuels dans les messages ; Seul l'aspect visuel des messages est modifié et pas l'interprétation de l'information à l'intérieur de celui-ci. Les implémentations peuvent choisir de garder de telles distinctions visuelles.
La définition formelle est divisée en quatre niveaux. Le bas niveau décrit la meta-notation utilisé dans ce document. Le second niveau décrit les analyseurs lexicaux de base qui créent les balises (feeds token) pour les analyseurs syntaxiques de haut niveau. A coté de cela, il y a une spécification au-dessus des précédentes pour les messages ; Elle permet la distinction des champs individuels. En fin de compte, il y a une définition des contenus des différents champs structurés.
Un cadre général de mémo est utilisé. Cela veut dire qu'un message consiste en de l'information sous forme rigide, suivi par la partie principale du message, dans un format qui n'est pas spécifie dans ce document. La syntaxe de plusieurs champs de la section formatée avec rigidité ("en-têtes") est définie dans cette spécification. Quelques-unes de ces zones doivent être présentes dans tous les messages.
La syntaxe qui fait la distinction entre les champs d'en-têtes est spécifié séparément de la syntaxe interne des champs particuliers. Cette séparation permet a de simples analyseurs de s'exécuter sur la structure générale des messages sans être concerné par la structure détaillée des champs d'en-tête pris en détail. L'annexe B est fournie pour faciliter la construction de ces analyseurs.
En plus des champs spécifiés dans ce document, on s'attend a ce que d'autres champs soient d'une utilisation commune. Si cela est nécessaire, les spécifications pour ces champs nouveaux seront publiées par le même mécanisme utilisé pour publier ce document. Les utilisateurs peuvent vouloir aussi étendre le jeu de champs qu'ils utilisent à titre personnel. Les "champs définis" par l'utilisateur sont autorisés
Le système réduit considérablement les nuances du document et son apparence, et c'est particulièrement utile pour la plupart des communications intra organisationnelle et pour la communication correctement structurée inter-organisationnelle. Ce peut être aussi utilisé par certains de communication interprocessus, tel que le transfert de simple fichier ou d'entrée de job à distance (remote job entry). Une structure plus robuste pourrait permettre le codage de l'information avec des fontes multiples, multicolores et multidimensionnelles. Une structure moins robuste, comme celle la, présente dans la plupart des machines restreindrait, avec plus de sévérité, le potentiel à ajouter des champs et de décider d'inclure des champs spécifiques. Contrairement à la communication basée sur le papier, il est intéressant de noter que le DESTINATAIRE d'un message peut exercer une quantité extraordinaire de contrôle sur l'apparence du message. La quantité de contrôle réellement disponible est actuellement contingenté par la capacité de leurs systèmes individuels de messagerie.
Cette spécification utilise une notation étendue de la Forme Backus-Naur (BNF). Les différences par rapport à la BNF se situent dans les règles de nommage, leurs indications de répétition et les options d'alternatives "locales".
En général les signes de supériorité ("<", ">") ne sont pas utilisés. Le nom d'une règle est simplement le nom lui-même plutôt que "<nom>". Les guillemets entourent le texte (qui peut être en minuscule ou majuscule). Certaines règles de base sont en majuscules, tel que SPACE, TAB, CRLF, DIGIT, ALPHA, etc. . Les signes de supériorité (<>) sont utilisés dans les définitions de règle et dans le reste de ce document, toutes les fois où cela facilitera l'utilisation des noms de règle.
Les éléments séparés par des slash
("/")
sont des alternatives. Ainsi avec
Les éléments compris entre parenthèse sont
traités
comme un élément unique. Ainsi,
Le caractère "*" précédant un élément indique la répétition.
qui indique au moins <l> et au plus <m> occurrences de
l'élément. Les valeurs par défaut sont 0 et
l'infini ainsi
Les crochets entourent les éléments facultatifs ;
Il existe une structure "#", similaire a "*", comme
qui indique qu'il existe au moins <l> et au plus <m> éléments, chacun séparé par une ou plusieurs virgule (","). Cela rend la forme habituelle très facile a utiliser ; Une règle telle que
Un point virgule, mis a une certaine distance à la droite d'un texte d'une règle, montre le début d'un commentaire qui continue jusqu'à la fin de la ligne. C'est une façon simple d'y inclure des annotations pratiques avec les spécifications.
Un message comprends des champs d'en-tête et, facultativement un corps. Le corps est une simple séquence de lignes contenant des caractères ASCII. Il est séparé des en-têtes par une ligne nulle (c'est à dire une ligne avec rien qui ne précède le CRLF).
Chaque champ d'en-tête peut être vu comme une
simple ligne logique de caractères ASCII, comprenant un nom de
champs
et un corps de champs. Par commodité, la portion du corps de
champ
de cette entité conceptuelle peut être
découpée
en une représentation multi-ligne. On appelle cela le "plissage"
(folding). La règle générale est que, partout
où
il peut y avoir un retour à la ligne avec des espaces blancs
|
To: "Joe & J. Harvey" <ddd @ Org>, |
|
To:"Joe & |
Une fois que le champ a été "déplissé", la structure peut être vue comme étant composé par un nom de champ suivie par un double point (:) suivie par un corps de champ terminé par un retour chariot à la ligne (CRLF). Le nom du champ doit se composer de caractère ASCII imprimable (c'est à dire des caractères ayant pour une valeur comprise entre 33 et 126, des décimaux, exception faites du double point (traduction de colon)). Le corps de champ peut être composé par n'importe quel caractère ASCII excepté par CR ou LF (bien que CR/LF soient présent vraiment dans les textes, ils sont enlevés par l'action de déplissage de champ).
Certains corps de champ d'en-tête peuvent être
interprétés
suivant une syntaxe interne que certains systèmes pourrait
analyser.
Ces champs sont appelés "champs structurés".
Exemple: les champs contenant des dates et des adresses.
D'autres
champs tel que "sujet" ou "commentaire " sont vues comme les
chaînes
de caractère d'un texte.
Pour quelques champs, tel que Sujet et Commentaire, aucune structure n'est supporté et ils sont traités simplement comme <textes> faisant partie du corps du messages. Les règles de plissages s'appliquent à ces champs, ainsi, de tel corps de champs qui occupent plusieurs lignes doivent par conséquent avoir la seconde ligne et les lignes successives indentée par un caractère LWSP (line white Space)
Pour aider à la création et à la lecture des champs structurés, l'insertion libre de ligne d'espace blanc (qui permet le plissage par inclusions de CRLF) est autorisé entre les marqueurs de champs lexicaux. Plutôt que d'obscurcir les spécifications syntaxiques pour ces champs structurés avec la syntaxe explicite de ces lignes espaces blancs, l'existence d'un autre analyseur lexical est supposé exister. Cette analyseur ne s'applique pas au corps de champ non structuré qui sont de simple chaîne de texte, comme c'est décrit précédemment. L'analyseur fournit la traduction du texte non plissé composant le corps d'un champ sous la forme d'une séquence de symbole lexicaux.
Ces symboles sont :
|
Ainsi, par exemple, le corps plissé du champ
":sysmail"@ Some-Group. Some-Org, |
:sysmail chaîne entre guillemets |
":sysmail"@Some-Group.Some-Org |
Muhammed.Ali@Vegas.WBA |
Ces règles indiquent une meta-syntaxe de champ, sans chercher dans la syntaxe interne ou les types particuliers. Leur objectif est de permettre la détection des champs ; Ainsi, elles donnent, au travers d'une analyse syntaxique de haut niveau, une image de chaque champ sur une seule ligne.
Les règles suivantes sont utilisées pour définir des analyseurs lexicaux sous-jacent, qui fournissent des marqueurs aux analyseurs de haut niveaux. Voir les références ANSI, dans la bibliographie.
Des caractères spéciaux sont réservés pour des interprétations spéciales, en tant que marqueurs lexicaux (terminaison) de délimitation. Pour permettre l'utilisation de ces caractères en tant que donnée non interprétée, le mécanisme de mise entre "double cote" est fourni. Pour mettre un caractère entrecôte le faire précéder par un antislash ("\").
Ce mécanisme n'est pas à caractère général. Les caractères peuvent être mis entre guillemets seulement s'ils font partie d'une sous partie d'une construction lexicale. En particulier, la mise entre guillemets est limitée a être utilisé à l'intérieur des :
| - chaînes entre guillemets |
| - littérals de domaine (domain-literal) |
| - commentaires |
| Remarque: | Dans le corps d'un champ structuré,les multiples caractères ASCII d'espace blanc de ligne (appelé HTAB et SPACE) sont traités comme de simples espaces et peuvent être librement entouré par n'importe quel symbole. Dans tous les champs d'en-têtes, le seul emplacement où au moins seul caractère LWSP est NECCESSAIRE est le début d'une ligne de continuation dans un champ plissé. |
Quand on passe du texte, à des processus qui n'interprète pas le texte en suivant ce standard (comme par exemple les serveurs de protocoles courrier), alors AUCUN caractère de ligne d'espace blanc ne devra être après un point (".") ou un signe at (@) et un mot (<word>). Exactement UN ESPACE devra être utilisé à l'endroit où il y aurait un caractère linéaire blanc et des séries de commentaire.
| Remarque: | Dans les systèmes se conformant à ce standard, partout où un membre d'une liste de délimiteur est autorisé, les caractères LWSP peuvent être aussi utilisé avant et/ou après eux. |
Les logiciels d'écriture de mail (c'est à dire les
générateurs
d'en-têtes) devraient réaliser qu'il n'y a aucune
définition,
dans les réseaux étendue, des effets du caractère
Un commentaire est une série de caractère ASCII, qui est entourée par des parenthèses ouvrantes et fermantes et où il n'y a pas de guillemets à l'intérieur. La notion de commentaire permet au créateur de message d'ajouter du texte qui sera utile pour le lecteur humain, mais qui sera ignoré par les sémantiques de formes. Les commentaires devront être gardé quand le message est sujet à interprétation vis a vis du standard. Cependant, les commentaires NE doivent PAS être inclus dans les autres cas, tel que pendant les échanges de protocoles avec les serveurs de courriers.
Pour les commentaires imbriqués, de telle façon que si une parenthèse gauche non mise entre guillemets apparaît dans une chaîne commentarisé, on doit avoir une correspondance qui devra se faire par une parenthèse droite fermante. Quand un commentaire agit comme un délimiteur entre une séquence de deux symboles lexicaux, tel que deux atomes, cela est équivalant lexicalement à un simple ESPACE, pour ce qui est de la reconstruction de séquence, tel que cela se passerait sur un serveur de protocole de courrier. Les commentaires sont détectés comme étant seulement la partie intérieure d'un corps de champ pour les champs structurés.
Si un commentaire est dans un plissage sur de multiple lignes, alors la syntaxe pour le pliage doit s'y conformer (voir la section sur "l'analyse lexicale des messages" sur les "zones d'en-tête longue plié" au-dessous et la section sur "l'indépendance de la case" au-dessus).
Notez que la sémantique officielle ne "voit" pas par conséquent les CRLF non mis entre guillemets qui font partie d'un commentaire, bien que certains programmes d'analyse grammaticale puissent remarquer leur présence. Pour ces programmes, il serait raisonnable d'interpréter un "caractere-LWSP CRLF" comme étant un CRLF faisant partie du commentaire; c'est à dire, que le CRLF est gardé et le caractère LWSP est mis de coté. Les CRLF mis entre guillemets (c'est à dire, un backslash suivi par CR suivi par un LF) doit être suivi par au moins un caractère LWSP.
Les caractères mis entre guillemets (anti-slash) et les caractères qui délimitent les unités syntaxiques ne sont pas, en général, pris en tant que données qui fassent partie d'unité(s) mise entre guillemets ou délimitée. En particulier, les marques de mises entre guillemets, qui définissent les chaînes mise entre guillemets, les parenthèses qui définissent un commentaire et les antislashs qui mettent entre guillemets le caractère suivant, NE font PAS partie de la chaîne mise entre guillemets ou du commentaire ou du caractère mis entre guillemets. Une marque de mise entre guillemets, une parenthèse qui fait partie d'un commentaire et un backslash qui fait partie des deux, doit être chacun précédé par le caractère backslash mise entre guillemets ("\"). Remarquez que la syntaxe autorise que n'importe quel caractère soit mis entre guillemets à l'intérieur d'une chaîne mise entre guillemets ou dans un commentaire; Cependant seul certain caractères DOIVENT être mis entre guillemets pour qu'ils soient pris comme des données. Ces caractères sont ceux qui ne font pas partie du groupe alternatif de texte ( c'est à dire ctext ou qtext).
La seule exception à cette règle est qu'un seul espace (SPACE) est supposé exister entre les mots contiguës dans une phrase, et cette interprétation est indépendante du nombre réel de caractère LWSP que les créateurs placent entre les mots. Pour inclure plus d'un espace (SPACE), le créateur doit rendre le caractère LWSP comme faisant partie d'une chaîne mis entre guillemets.
Les marques de mise entre guillemets qui délimitent les chaînes mise entre guillemets et les backslash qui mettent entre guillemets le caractère suivant NE doit PAS accompagner la chaîne mise entre guillemets quand la chaîne est passée à des processus qui n'interprètent pas les données suivant cette spécification (comme par exemple, les serveurs de protocoles de courrier).
Quand c'est permis (c.a.d., dans les mots de champ structuré) les chaînes sont traitées comme un simple symbole. Cela veut dire qu'une chaîne entre guillemets est équivalante syntaxiquement à un atome. Si une chaîne mise entre guillemets est "plissée" sur de multiples lignes, alors la syntaxe pour le plissage doit s'y conformer (voir la section "analyse lexicale des messages" sur les "champs d'en-têtes long plissés" situé au-dessus et la section sur "l'indépendance de la casse" au-dessous.).Ainsi, la sémantique officielle ne doit pas "voir" n'importe quel CRLF (mise à nu) qui soit dans une chaîne de caractères; Cependant pour certains programmes, il serait raisonnable d'interpréter un caractère "CRLF LWP" comme étant un CRLF qui fait partie d'une chaîne mise en guillemets; c'est à dire, que le caractère sera gardé et le caractère LWSP est abandonné. Les CRLF mis entre guillemets (c.a.d. , un antislash suivi par un CR (retour chariot) LF (nouvelle ligne) sont aussi sujet au règle de plissage, mais la présence de caractère mis entre guillemets (backslash) indique explicitement que les CRLF sont pris comme donnée pour la chaîne mise entre guillemets. Le déplissage du premier caractère suivant le caractère LWSP est aussi approprié quand on analyse la syntaxe des CRLF mis entre guillemets.
Il y a un seul type de cadres qui vont par paire entrant en correspondance l'une par rapport à l'autre et imbriquée l'une avec l'autre:
Il y a trois types de "marque de cadrages" qui sont en correspondance par paire et qui NE doivent PAS être imbriqués:
Exception faite de ce qui mis en remarque ou note, les chaînes alphabétiques peuvent être représentées par n'importe quelle combinaison de majuscules et de minuscules. Les seules entités qui nécessitent la préservation de l'information de la casse sont:
| - le text |
| - le qtext |
| - le dtext |
| - le ctext |
| - les paires mises en guillemets (traduction de "quoted pair") |
| - les parties locales, exception faite de "Postmaster" |
Pour ce qui est de la correspondance avec n'importe quelle autre unité syntaxique, la case doit être ignorée. Par exemple, les noms de champ "From", "FROM", "from", et même "FroM" sont sémantiquement égal et devrait être traité à l'identique.
Quand on génère ses entités, n'importe quel mixage de majuscule et de minuscule pour les caractères alphabétiques peuvent être utilisé. La casse dans ces spécifications est suggérer pour les processus de création de message.
Chaque champ d'en-tête peut être
représenté
sur exactement une seule ligne contenant le nom de champ et son corps
qui est terminé par un CRLF. C'est ce que l'analyseur syntaxique
voit. Pour la lisibilité, la portion de corps de champ des
champs
d'en-têtes long peut être plissé en de multiple
ligne.
"Long" est interprété communément comme signifiant
plus grand que 65 ou 72 caractères.
La taille de l'outils de mise en forme sert de limite quand le message
est fait pour être visualisé sur la plupart des terminaux
simples qui sont utilisés comme logiciel d'affichage; Cependant
la limite n'est pas imposé par ce standard.
Les caractères ASCII BS (Backspace, 8 en décimal) peut être inclus dans les textes et les chaînes cotées pour faire de la surimpression. Cependant, n'importe quelle utilisation des backspaces qui a pour effet de sur-imprimer à gauche du commencement d'un texte ou d'une chaîne mises entre guillemets est prohibé.
Au cours de la transmission au travers de réseau hétérogène, il peut être nécessaire de forcer les donnée pour quelles soient conformes aux conventions locales au réseau. Par exemple, il peut être nécessaire que le CR soit suivi soit par un LF, ce qui fait un CRLF, ou par un <null>, si le CR est isole. De telle transformations, sont remises à leur état initial, quand le message sort de ce type de réseau.
Quand on passe au travers de limitations de réseaux, le message doit être traité comme passant au travers de deux modules. On rentrerait dans le premier module qui contiendrait les transformations spécifiques qui permettrait la migration au travers du réseau courant. Il passerait alors au travers des modules:
Les particularités du réseau actuel sont enlevée et le message est remis dans la forme canonique spécifié dans ce standard.
------------------ |
|
| Remarque: | A cause de l'artefact des conventions de notations,la
syntaxe indique que , quand ils sont présents, certains champs,
doivent être dans un ordre particulier. Il N'est PAS
nécessaire que les champs d'en-tête soient dans un ordre
particulier, excepté
que le corps du message doit ecirc;tre APRES les en-têtes. Il est
recommandé, que s'ils sont présents, les en-têtes
soient envoyées dans l'ordre "Return-Path", "Received",
"Date", "From", "Subject", "Sender", "To", "cc", etc.
Cette spécification permet des occurrences multiples pour la plupart des champs. Exception faite de ce qui est noté, leur interprétation n'est pas spécifié ici, et leur utilisation en est découragé. |
La syntaxe qui suit pour le corps des divers champs doit être pensée en tant que description de chaque champs comme une seule chaîne longue ( ou ligne). La section "Analyse" lexicale du message sur "Champs d'en-tête long", au-dessus, indique comment de telle chaînes longue peuvent être représenté sur plus d'une ligne dans un message réellement transmit.
Certains systèmes permettent aux destinataires des courriers de faire passer le message (forwarding), en s'appropriant l'en-tête d'origine, et en y ajoutant quelques champs nouveaux. Ce standard supporte de tel service, au travers du préfixe "Resent-" mis sur les noms de champs ;
Chaque fois que la chaîne "Resent-" commence un nom de champ, le champ a la même sémantique qu'un champ qui n'aurait pas eu le préfix. Cependant le message est supposé avoir été réexpédié par le destinataire originel qui a attaché le champ "Resent-". Ce nouveau champ est traité comme s'il était plus récent que son équivalent, le champ originel. Par exemple, le "Resent-From", indique la personne qui a re-routé le message, attendu que la zone "from" indique l'auteur originel.
L'utilisation des informations précédentes dépends des besoins de communications des participants. Par exemple, ce standard ne dicte pas quand une adresse "Resent-From:" devrait recevoir des réponses, a la place de leur envoyer l'adresse de "From".
| Remarque: | En général, le champ "Resent-" doit être traité comme contenant un contenu d'information qui est indépendant du jeu de contenu originels. L'information pour un contenu ne devrait pas été mis à partir d'un autre automatiquement. L'interprétation de multiple champs "Resent-", du même type, n'est pas défini. |
Dans le reste de cette spécification, l'occurrence des champs légaux "Resent-" est traité de manière identique à l'occurrence de champs qui ne contient pas ce préfixe.
L'information trace est utilisé pour fournir un audit de suivi de manipulation de message. En plus, il indique une route de retour vers l'expéditeur du message.
La liste des valeurs connues de "via" et "with" est enregistrée par le Network Information Center, SRI International, Menlo Park, California.
Ce champ est ajouté par le système de transport final qui délivre le message a son destinataire. Le champ est censé contenir l'information définitive sur l'adresse et la route de retour vers l'origine du message.
| Remarque: | Champs "Reply-To" est ajouté par l'origine et sert à une réponse directe, alors que le champ de "Return-Path" est utilisé pour identifier le chemin de retour vers l'origine. |
Quand la syntaxe indique qu'une spécification de route est optionnelle, pour chaque tentative, on devra essayer de fournir l'information à ce champ.
Une copie de ce champ est ajoutée par le service de transport qui relaye le message. Cette information peut être assez utile pour suivre les problèmes de transport.
Les noms d'hôtes d'expédition et de réceptions et de date-temps de réception peuvent être spécifié. Le paramètre "via" peut être utilisé, pour indiquer par quel mécanisme physique le message est envoyé tel que comme Arpanet ou Phonenet, et le paramètre "with" peut être utilisé pour indiquer quel protocole de niveau courrier ou de connexion doit être utilisé, tel que comme le protocole de courrier SMTP ou le protocole de transport X.25.
| Remarque: | Plusieurs paramètres "with" peuvent être inclus pour qualifier pleinement le jeu de protocole qui ont été utilisé. |
Certains services transports mettent en file d'attente les courriers ; l'identifieur de message interne qui est assigné au message peut être noté en utilisant le paramètre "id". Quand le serveur hôte d'expédition utilise la spécification d'une adresse de destination que l'hôte receveur re-interprètent, au travers d'extension ou de transformation, le serveur receveur pourrait enregistrer la spécification originelle, en utilisant le paramètre "for". Par exemple, quand une copie de courrier est envoyé a un membre d'une liste de télédistribution, ce paramètre peut être utilisé pour enregistrer les adresses originelles qui sont utilisé pour définir la liste.
Le standard permet seulement un sous jeu de combinaison possible avec les champs From, Sender, Reply-To, resent-from, Resent-Sender, et resent-reply-to. Cette limitation est voulue.
Ce champ contient l'identité de la ou des personnes qui ont voulu que ce message soit envoyé. Le processus de création de message devrait mettre par défaut une seule adresse de machine authentifiée , indiquant l'AGENT (personne, système ou processus) qui a entré le message. Si cela n'est pas fait, le champ expéditeur (sender) DOIT être présent. Si le champ "from" EST mis par défaut, le champ "expéditeur" ("sender") est optionnel et est redondant avec le champ "From". Dans tous les cas, les adresses dans le champ "From" doivent être utilisable par la machine (machine-usable) (spécif d'adresses) et ne doit pas contenir (may not) des listes nommées (groupes).
Ce champ contient l'identité authentifié de l'AGENT (personne, système ou processus) qui envoie le message. Cela a pour but d'être utilisé quand l'expéditeur n'est pas l'auteur du message ou pour indiquer qui parmi un groupe d'auteur expéditeur a réellement expédié le message. Si le contenu du champ "sender" est entièrement redondant avec le champ "From", alors le champ "Sender" n'a pas besoin d'être présent et son utilisation est découragée (bien que légale). En particulier, le champ "sender" DOIT être présent si ce N'est PAS le même que le champ "From".
La spécification de la boite à lettre de l'expéditeur comprends une série de mots doit correspondre a un agent spécifique (c.a.d., un utilisateur humain ou un programme d'ordinateur) plutôt qu'une adresse standard. Cela indique que l'on s'attend a ce que le champ identifiera un simple AGENT (une personne, un système ou un processus) responsable pour l'envoie du courrier et n'inclue pas si simplement le nom d'une boite à lettre d'où le courrier est envoyé. Par exemple dans le cas, où un nom de login est partagé, le nom, par lui-même, ne sera pas en adéquation. L'unité d'adresse locale, qui fait référence a cet agent, s'attend a être un terme de système d'ordinateur, et non (par exemple) faisant appel à la référence de la personne qui peut être utilisé hors du contexte réseau d message de type texte u texte du message réseau.
Puisque la fonction critique qu'utilise le champ "Sender" est l'identification de l'agent responsables de l'envoie des courriers et que les programmes d'ordinateurs ne peuvent pas être tenir responsable de leur comportement, il est fortement recommandé que quand un programme d'ordinateur génère un message, l'HUMAIN qui est responsable de ce programme soit référencé en tant que partie de la spécification de boite à lettres de champ "sender".
Ce champ fournit un mécanisme global pour indiquer n'importe quelle boite aux lettres vers laquelle la réponse doit être envoyé. Trois utilisations classiques pour cette caractéristiques peuvent être distingué. Dans le premier cas, le(s) auteur(s) peuvent ne pas avoir de boite à lettre régulièrement basée sur un ordinateur, et des lors, veulent indiquer une adresse de machine alternative ; Dans le second cas, un auteur peut vouloir que des personnes supplémentaires en soient averties, ou en soient responsable, ou répondent. Une utilisation quelque peu différente peut en être fait pour l'aide aux groupes de téléconférence en mode texte équipé avec des services de télédistribution automatique : incluant l'adresse de ce service dans le champ "Reply-To" pour tous les messages soumis à la téléconférence ; Alors les participants peuvent "répondre" aux soumissions fait pendant la conférence pour garantir la distribution correcte de n'importe quelle soumission de leur part.
Pour les systèmes qui génèrent des listes d'adresses pour les réponses aux messages, les recommandations suivantes sont faites :
Parfois, un destinataire peut vouloir réellement communiquer avec le ou les personnes qui ont initiées le transfert de message. Dans de tels cas, il est raisonnable d'utiliser l'adresse "Sender".
Cette recommandation est uniquement destinée à l'utilisation automatisée des champs d'origines et n'a pas été faite pour suggérer que les réponses peuvent ne pas être envoyées à d'autres destinataires de messages. On laisse aux programmes de manipulations de courrier, de décider quelles capacités additionnelles seront a fournir.
Des exemples sont donnés dans l'annexe A.
Ce champ contient l'identité des destinataires principaux du message.
Ce champ contient l'identité des destinataires secondaires (ou à titre d'information) du message.
Ce champ contient l'identité des destinataires supplémentaire du message. Les contenues de ce champ ne sont pas inclus dans les copies des messages envoyées aux destinataires principaux et secondaires. Des systèmes peuvent choisir d'inclure le texte de cette zone "Bcc" seulement dans la copie de l'auteur, alors que d'autres peuvent aussi l'inclure dans le texte envoyé à tous ce qui sont indiqué dans la liste "Bcc"
Ce champ contient un identifieur unique (l'élément d'adresse de la partie locale) qui référence LA version de CE message. L'unicité de l'identifieur du message est garantie par le système d'hôte qui le génère. Cette identifieur a pour but d'être lisible de la machine et non d'être nécessairement parlant pour les humains. A un identifieur de message corresponds uniquement à d'une seule instance d'un message précis ; Les révisions subséquentes du message devront chacune recevoir de nouveaux identifieur de messages.
Les contenus de ce champ identifient la correspondance précédente à laquelle ce message réponds. Notez que si les identifieurs de messages sont utilisés dans ce champ, ils doivent utiliser le format de spécification d'identification de msg-id.
Le contenu de ces champs identifie les autres correspondances dont ce message fait référence. Notez que si les identifieurs de message sont utilisés, ils doivent utiliser le format de spécification d'identification de msg-id.
Ce champ contient des mots clé ou des phrases séparées par des virgules.
Cela a pour but de fournir un résumé, ou d'indiquer la nature, du message.
Permet d'ajouter des commentaires de texte sur le message sans que cela gêne le contenu du corps du message.
Parfois, la cryptographie est utilisée pour augmenter la confidentialité du contenu du message. Si le corps du message a été crypté, pour garder son contenu privé, le champ "Encrypted" peut être utilisé pour noter le fait, et pour indiquer la nature du cryptage. Le premier paramètre de type <word> indique le logiciel utilisé pour crypter le corps, et le second, optionnel de type <word> a pour intention d'aider le destinataire dans la sélection de la bonne clef dedécryptage. Ce mot de code peut être vu un index vers une table de clé détenu par le destinataire.
| Remarque: | Malheureusement, les en-têtes comprennent aussi bien l'enveloppe, que le contenu et de l'information. Par conséquent, il est nécessaire qu'elles restent non crypté, afin que le service de transport de courrier puisse y accéder. Puisque le contenu des champs de noms, d'adresses, et "Subject" peut contenir de l'information sensible, cela limite la confidentialité totale du message. |
Les Noms des logiciels de cryptage sont enregistrés au Network Information Center, SRI International, Menlo Park, California.
Un nombre limité de champs courants a été défini dans ce document. Comme les exigences du réseau de courrier imposent leur dictature, des champs additionnels peuvent être standardisés. Afin de fournir des champs définis par l'utilisateur avec une certaine part de sécurité, dans la sélection de nom, de telle zone extension ne devront pas avoir des noms qui commencent avec la chaîne "X-". Les noms des champs d'extension sont enregistrés au Network Information Center, SRI International, Menlo Park, California.
Les utilisateurs individuels du réseau de courrier sont libres de définir et d'utiliser des champs d'en-têtes supplémentaires. De tels champs doivent avoir des noms qui ne soient pas déjà utilisé dans la spécification actuelle ou dans n'importe quelle définition d'extension, et l'ensemble de la syntaxe de ces champs définis par l'utilisateur doit se conformer aux règles de la spécification pour ce qui concerne la limitation et le plissage de ces champs. Du fait du processus de publication des champs d'extension, le nom d'un champ défini par l'utilisateur doit être déjà libre (pre-empted)
| Remarque: | La chaîne préformée "X-" ne sera jamais utilisé dans les noms de champ d'extension. Cela permet de donner des champs définis par l'utilisateur avec un jeu protégé de noms. |
La zone temps peut être indiquée de plusieurs façon. "UT" est le temps universel (jadis appelé "Greenwich Mean Time") ; "GMT" est permis si cela référé au Temps Universel. Le standard militaire utilise un seul caractère pour chacune des zones. "Z" est le temps universel. "A" indique une heure plus tôt, et "M" indique 12 Heures plus tôt ; "N" est une heure plus tard, et "Y" est 12 heures plus tard. La lettre "J" n'est pas utilisée. Les 12 autres formes restantes sont prises à partir du standard ANSI X3.51-1975. L'une permet d'expliciter l'indication du nombre de décalages par rapport UT, l'autre utilise communément une chaîne de 3 caractères en indiquant les zones de temps d'Amérique du Nord.
Une boite aux lettres reçoit des courriers. C'est une entité conceptuelle qui n'est pas forcement en rapport avec un stockage de fichier. Par exemple, quelques sites peuvent choisir d'imprimer le courrier sur une imprimante en ligne et remettre la sortie au bureau du destinataire.
Une spécification de boite à lettre comprends une référence à un nom de personne, de système ou de processus, une chaîne dépendant d'un domaine, et une référence à un nom de domaine. La référence au nom est optionnelle et on l'utilise généralement pour indiquer le nom humain de la personne destinataire. La référence au nom de domaine désigne une série de sous-domaines. La chaîne dépendant du domaine n'est pas interprétée, exception faite du sous domaine final ; le reste du service de courrier, la transmet simplement comme une chaîne littérale.
Un nom de domaine est un ensemble de nom (courrier) répertorié. Une définition de nom de domaine décide de la définition de nom de domaine subordonné ou d'une chaîne terminale dépendante d'un domaine. Par conséquent, la définition d'un domaine est extensible, permettant n'importe quels nombres de niveaux d'enregistrement.
Les noms de domaine modélisent le schéma hiérarchique, logique, et global d'adressage. Le modèle est logique, du fait que la définition d'adressage est relatif au nom d'enregistrement et n'est pas obligatoirement liée au chemin de transmission. La hiérarchie du modèle est un graphe orienté, appelé arbre entrant (in-tree), de telle manière qu'il n'y ait qu'un seul chemin de la racine de cet arbre vers n'importe élément de la hiérarchie. Si plus d'un chemin existe réellement, on considère que l'on a affaire à des adresses différentes.
Le nœud racine est commun à toutes les adresses ; Par conséquent, il n'est pas référencé. Ces enfants constituent les noms de domaine de haut niveau. Habituellement, un service a accès à sa définition complète de nom de domaine et a tous les domaines de nom de niveau supérieur.
Le "haut" de la hiérarchie d'adressage de domaine -- un des fils de la racine -- est indiqué par le champ situé le plus à gauche dans la définition d'un domaine. Ses enfants sont situés à gauche, leur fils à gauche, et ainsi de suite.
Certains groupes fournissent des services officiels d'enregistrements ; On constitue des domaines de noms qui sont indépendant logiquement de machines spécifiques. En plus, les machines et les réseaux composent implicitement des domaines de noms, puisque leurs membres sont habituellement enregistrés dans des tables de noms.
Dans le cas d'un enregistrement officiel, une organisation implemente une base de donnée (distribué) qui fournit un service de correspondance adresse-route pour les adresses qui sont de la forme :
person@registry.organization
Notez que "organization" est une entité logique, indépendant d'un quelconque réseau de communication.
Un mécanisme pour accéder à l'"organization" est disponible pour tout le monde. Ce mécanisme, en boucle, cherche une instance de l'enregistrement ; sa localisation n'est pas spécifiée sous forme d'adresse. On suppose que le système qui opère sous le nom "Organization" sait comment trouver un registre subordonné. Le registre utilisera alors la chaîne "person" pour déterminer ou envoyer la spécification du courrier. Le dernier contenant orienté réseau permet une spécification simple et directe d'adresse relative à un attachement, comme:
user@host.network
Une fois que le réseau est atteint, on s'attend a ce que le message ira directement vers l'hôte et que l'hôte résoudra le nom de l'utilisateur, en plaçant le message dans la boite aux lettres de l'utilisateur.
Puisqu'un nombre quelconque de niveau est possible dans la hiérarchie d'un domaine, la spécification d'une adresse pleinement qualifiée, peut devenir un inconvénient. Ce standard permet des définitions de domaine mis sous forme abrégées pour le cas particulier :
|
Pour les adresses de l'expéditeur, on appelle Niveau N le sous domaine le plus à gauche. Dans une adresse d'en-tête, si tous les sous domaines situés au-dessus (c.a.d. à droite) de Niveau N sont les même que celle de l'expéditeur, alors ils n'ont pas à apparaître dans la spécification. Sinon, l'adresse doit être pleinement qualifiée (fully qualified). Cette caractéristique est sujet à approbation par les sous domaines locaux. Les sous domaines individuellement peuvent avoir besoin de leur système membre, qui donne l'origine du courrier, pour uniquement fournir une définition de domaine complète. Quand c'est autorisé, les abrégés peuvent être présents seulement quand le message reste à l'intérieur du sous domaine. L'utilisation de ce mécanisme nécessite que le sous-domaine de l'expéditeur réservent les noms de tous les domaines de niveau supérieur, de cette façon ces complètes définitions peuvent être différenciées des définitions mise sous forme d'abréviations. |
Par exemple, si l'adresse d'un expéditeur est :
| expediteur@registry-A.registry-1.organization-X |
et l'adresse d'un destinataire est :
| destinataire@registry-B.registry-1.organization-X |
et qu'un autre soit :
| destinataire@registry-C.registry-2.organization-X |
alors ".registry-1.organization-X" n'a pas besoin d'être indiqué dans le message, mais "registry-C.registry-2" DOIT être indiqué. C'est à dire, les deux premières adresses peuvent être mises sous forme d'abrégés mais la troisième doit être entièrement définie.
Quand un message traverse une limite de domaine, toutes les adresses doivent être déclarées sous le format complet, en finissant par le nom de domaine de niveau supérieur sur le champ le plus à droite. C'est de la responsabilité du service d'expédition de courrier de s'assurer que les adresses soient en conformité avec cette exigence. Dans le cas des adresses mises sous abréviation le serveur qui fait relais doit faire l'extension nécessaire. On doit noter que c'est souvent difficile pour de tel service de localiser toutes les occurrences des abréviations d'adresse. Par exemple, il sera impossible de trouver ces abréviations à l'intérieur du corps d'un message. Le champ de "retour de chemin" peut aider les destinataires dans la correction de ce type d'erreur.
Une référence de domaine doit être LE nom officiel d'un registre, d'un réseau ou un hôte. C'est une référence symbolique, à l'intérieur d'un nom de sous domaine. A tout moment, il est nécessaire de passer outre les mécanismes du standard pour résoudre de telles références, en usant d'informations plus primaires, tel que les adresses d'hôte de réseau plutôt que leur nom d'hôte associé.
Pour permettre de telles références, ce standard fournit la construction littérale de domaine. Son contenu doit se conformer aux nécessités du sous domaine dans lequel c'est interprété.
Les littéraux de domaines a qui font
référence
les domaines à l'intérieur de l'ARPA Internet
spécifient
Les adresses Internet sur 32 bits, dans des champs de 8 bits note en
décimal
comme ce qui est décrit dans la Request for
[10.0.3.19]
| Remarque: | L'UTILISATION DE LITTERAL DE DOMAINE EST FORTEMENT DECOURAGE. Cela est permit seulement comme un moyen de contourner temporairement les limitations système, tel que les tables de nom qui ne sont pas complètes. |
Les noms de domaines de "haut niveau", et les noms de domaine sous l'Internet ARPA, sont enregistré au Network Information Center, SRI International, Menlo Park, California.
La partie locale d'une spécification d'adresse dans une déclaration d'adresse (c.a.d. le nom d'hôte pour la boite à lettre) est interprétée comme étant ce que le serveur receveur de mail autorise. Par exemple, certains systèmes ne comprennent pas les déclarations de boite à lettre de la forme "P. D. Q. Bach", mais d'autres le font.
Cette norme traite les points (".") en tant que séparateurs lexicaux. En conséquence, leur présence dans les parties locales qui ne sont pas entre des chaînes mise entre guillemets, est détecté. Cependant de telles occurrences n'apportent AUCUNE sémantiques. Cela signifie, que si une partie locale avait des points dans cette partie, un analyseur d'adresse la diviserait en plusieurs marques syntaxiques, mais la séquence de ces marques serait traitée comme une seule unité ininterrompue. La séquence devra être ré-assemblé, quand l'adresse sera passée hors du système comme celui du service de protocole de mail.
Par exemple, l'adresse:
First.Last@Registry.Org
est légale et ne nécessite pas que la de partie locale soit entourée par des guillemets (Cependant, "First Last" ne nécessite de mise entre guillemets) La partie locale de l'adresse, quand elle est passée hors du système mail, à l'intérieur du domaine Registry.Org est "First.Last", de nouveau sans la mise entre guillemets.
Dans certains cas, la frontière entre la partie locale et le domaine peut être flexible. La partie locale peut être une simple chaîne de caractère, qui est utilisé pour déterminer la boite à lettre du destinataire final. Tous les autres niveaux font par conséquent, partie du domaine.
Pour certains systèmes, dans le cas des références mises sous forme d'abréviation pour les sous-domaine-locaux et subordonné, il peut être possible de spécifier seulement une référence à l'intérieur de la partie du domaine et de placer les autres, références de nom de domaine subordonné a l'intérieur de la partie locale. Cela pourrait avoir l'aspect:
mailbox.sub1.sub2@this-domain
Une telle norme serait acceptable pour les analyseurs qui se conforment à la RFC nº733, mais ne supporterait ce nouveau standard Internet. Bien qu'elle contrarie les intentions de cette norme, la forme est légale.
Aussi, certains sous-domaine ont une définition syntaxique qui n'est pas conforme à cette norme. Par exemple
sub-net.mailbox@sub-domain.domain
utilise une séquence d'analyse syntaxique différente pour la partie locale par rapport à celle du domaine.
Un individu peut avoir plusieurs boites à lettre et aimerait recevoir du courrier dans la boite à lettre qui serait le plus pratique d'accès pour l'expéditeur. Ce standard ne donne pas un sens au fait de préciser "n'importe quel membre d'une liste de boite.
Un ensemble d'individu peut vouloir recevoir un courrier comme une seule unité (c.a.d. une liste de distribution). Le constructeur de <group> permet la spécification à la manière d'une liste. Les boites à lettres des destinataires sont spécifié à l'intérieur de partie entouré de parenthèse (bracket) (":" - ":"). Une copie du message est envoyée à chacune des boites à lettres listées. Le standard ne permet pas des spécifications récursives de groupe à l'intérieur de groupes.
Alors qu'une liste doit avoir un nom, il n'est pas nécessaire que le contenu de la liste soit inclus. Dans ce cas, l'<adresse> sert seulement comme indicateur de groupe de distribution et apparaîtra sous la forme :
name:;
Certains services de courrier peuvent fournir un mécanisme de distribution par groupe-liste, acceptant une simple référence de boite a lettre, et en la développant en une liste de distribution complète, et en relayant le courrier au membre de la liste. Ce standard ne fournit aucune syntaxe supplémentaire pour indiquer de tel service. L'utilisation d'adresse alternative <group>, qui contient à l'intérieur, une boites à lettres, peut signifier que, soit la référence de la boite à lettre sera développé en une liste ou soit qu'il y a un groupe avec un seul membre.
Quelquefois, une personne à l'origine d'un message doit pouvoir indiquer quel chemin de transmission, le message doit suivre. On appelle cela le routage à la source. Le schéma normal d'adressage, utilisé dans la spécification d'adresse, est dissocie par prudence de ces informations ; La portion <route> d'un adressage de route à la source est fournie pour de telles occasions. On spécifie la séquence de serveurs hôte et/ou les services de transmission qui sont traversés. A la fois, les références de domaines et les littéraux de domaine peuvent être utilisées.
Il est souvent nécessaire d'envoyer un courrier vers un site, sans connaître aucunes adresses valides. Par exemple, il y a peut être des dysfonctionnements du système de courrier ou un utilisateur veut connaître l'adresse correcte d'une personne sur ce site.
Ce standard spécifie une simple adresse, adresse réservée de boite a lettre (partie locale) qui doit être valide pour chaque site. Le courrier envoyé à cette adresse doit être routé vers une personne responsable pour le système de courrier du courrier. Le nom de l'adresse de la partie locale de l'adresse est :
Postmaster
ainsi on a doit avoir "Postmaster@domain" pour que ce soit valide.
| Remarque: | Cette partie locale réservée doit être établie sans tenir compte de la case alphabétique, ainsi "POSTMASTER", "postmaster", et même "poStmASteR" sont accepté. |
ANSI. "USA Standard Code for Information Interchange," X3.4. American National Standards Institute: New York (1968). Aussi dans: Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104.
ANSI. "Representations of Universal Time, Local Time Differentials, and United States Time Zone References for Information Interchange," X3.51-1975. American National Standards Institute: New York (1975).
Bemer, R.W., "Time and the Computer." dans: Interface Age (Feb. 1979).
Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Rutherford and Appleton Laboratory: Didcot, England.
Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., et White, J.E. "Standardizing Network Mail Headers," ARPANET Request for Comments No. 561, Network Information Center No. 18516; SRI International: Menlo Park (Septembre 1973).
Birrell, A.D., Levin, R., Needham, R.M., et Schroeder, M.D. "Grapevine: An Exercise in Distributed Computing," Communications of the ACM 25, 4 (Avril 1982), 260-274.
Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. "Standard for the Format of ARPA Network Text Message," ARPANET Request for Comments No. 733, Network Information Center No. 41952. SRI International Menlo Park (Novembre 1977).
Feinler, E.J. et Postel, J.B. ARPANET Protocol Handbook, Network Information Center No. 7104 (NTIS AD A003890). SRI International: Menlo Park (Avril 1976).
Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. (1969).
Levin, R. et Schroeder, M. "Transport of Electronic Messages through a Network," TeleInformatics 79, pp. 29-33. North Holland 1979). Aussi dans Xerox Palo Alto Research Center Technical Report CSL-79-4.
Myer, T.H. et Henderson, D.A. "Message Transmission Protocol," ARPANET Request for Comments, No. 680, Network Information Center No. 32116. SRI International: Menlo Park (1975).
NBS. "Specification of Message Format for Computer Based Message Systems, Recommended Federal Information Processing Standard." National Bureau of Standards: Gaithersburg, Maryland (Octobre 1981).
NIC. Internet Protocol Transition Workbook. Network Information Center, SRI-International, Menlo Park, California (Mars 1982). Oppen, D.C. et Dalal, Y.K. "The Clearinghouse: A Decentralized Agent for Locating Named Objects in a Distributed Environment," OPD-T8103. Xerox Office Products Division: Palo Alto, CA. (Octobre 1981).
Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, No. 820. SRI International: Menlo Park (Août 1982).
J.B. "Simple Mail Transfer Protocol," ARPANET Request for Comments, No. 821. SRI International: Menlo Park (Août 1982).
Shoch, J.F. "Internetwork naming, addressing and routing," dans Proc. 17th IEEE Computer Society International Conference, pp. 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
Su, Z. and Postel, J. "The Domain Naming Convention for Internet User Applications,"ARPANET Request for Comments, No. 819. SRI International: Menlo Park (Août 1982).
Ces deux exemples de "Alfred Neuman" ont une sémantique
identique,
puisque que les opérations du programme (de distribution)
d'expédition de courrier situé sur l'hôte local
(aussi appelé son maileur) et les opérations faites par
le serveur de protocole de courrier distant sont sollicitées.
Dans le premier exemple, le "Alfred Neuman" est ignoré par le
maileur, puisque "Neuman@BBN-TENEXA" spécifie
complètement le destinataire. Le second exemple ne contient
aucune information superflue, et de nouveau,
Cette forme doit être utilisée pour indiquer qu'une simple boite à lettre est partagée par plusieurs utilisateurs. La chaîne mise entre guillemets est ignorée par le maileur a qui appartient l'hôte d'origine, du fait que "Shared@Group.Arpanet" spécifie parfaitement la destination de la boite à lettre.
Le "(l'Immobile)" est un commentaire, qui N'est PAS inclut dans l'adresse de la boite à lettre de destination manipulée par le système source d'envoi de courrier. La partie locale de l'adresse est la chaîne "Wilt.Chamberlain", sans AUCUN espace entre le premier et deuxième mots.
Gourmets: Personnes Suffisantes <WhoZiWhatZit@Cordon-Bleu>, |
George Jones est loggué sur son hôte en tant que "Jones". Il envoie un courrier a lui-même.
From: Jones@Group.Org |
George Jones est loggué en tant que Jones sur son hôte. Son secrétariat, qui est loggué en tant que Secy envoie un message pour lui. Les réponses aux courriers devraient aller vers Georges.
From: George Jones <Jones@Group> |
Le secrétariat de George Jones envoie un courrier pour George. Les réponses devront aller à George.
From: George Jones<Shared@Group.Org> |
Remarquez qu'il n'y a pas besoin d'espace entre "Jones" et le "<", mais l'ajout d'un espace augmente la lisibilité (comme c'est le cas pour les autres exemples.
George est un membre d'un comité. Il veut que toutes réponses à son message aillent à tous les membres du Comité.
From: George Jones <Jones@Host.Net> |
George Jones demande a son secrétariat(Secy@Host) d'envoyer un message pour lui avec les possibilités de groupe qu'il a. Il veut que son secrétariat puisse manipuler toutes les réponses.
From: George Jones <Group@Host> |
Une amie de George, Sarah, est en visite. Le secrétariat de George envoie des courriers à l'ami de Sarah situé sur le territoire "des ordinateurs". Les Réponses devront aller à George, dont la boite à lettre est Jones au Registry.
From: Sympatique Sarah <Secy@Registry> |
Le secrétariat de Georges envoie un message dont les auteurs sont conjointement tous les membres du comité. Remarquez que le nom d'un comité ne peut pas être spécifié, puisque les noms de <group> ne sont pas autorisés, dans le champ From
From: Jones@Host, |
Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT |