RFC2532 Télécopie étendue avec la messagerie Internet Masinter & Wing

Groupe de travail Réseau

L. Masinter, Xerox Corporation

Request for Comments : 2532

D. Wing, Cisco Systems

Catégorie : En cours de normalisation

mars 1999

Traduction Claude Brière de L’Isle




Télécopie étendue utilisant la messagerie Internet



Statut de ce mémoire

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.


Notice de copyright

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


Résumé

Le présent document décrit des extensions au "mode simple de télécopie utilisant la messagerie Internet" [RFC2305] et décrit des caractéristiques supplémentaires, incluant la transmission de caractéristiques de document améliorées (meilleure résolution, couleur) et la confirmation de la livraison et du traitement.


Ces caractéristiques supplémentaires sont conçues pour fournir le meilleur niveau d’interopérabilité avec l’infrastructure et les agents d’utilisateur existants et futurs de messagerie électronique conformes aux normes, tout en fournissant un niveau de service qui approche du niveau dont jouissent actuellement les utilisateurs de la télécopie.


L’IETF a été informé de droits de propriété intellectuelle revendiqués à l’égard de tout ou partie de la spécification contenue dans le présent document. Pour plus d’informations, consulter la liste en ligne des revendications de droits à <http://www.ietf.org/ipr.html>.


1. Introduction


Le présent document note un certain nombre d’améliorations au "mode simple de télécopie utilisant la messagerie Internet" de la [RFC2305] qui peuvent être combinées pour créer un mode de télécopie étendu utilisant la messagerie Internet.


Les nouvelles caractéristiques sont conçues pour être interopérables avec la base existante d’agents de transfert de messagerie (MTA, mail transfer agent) et d’agents d’utilisateur de messagerie (MUA, mail user agent) et tirer parti des normes existantes pour des fonctions évoluées telles que la confirmation positive de livraison et la notification de disposition. Les améliorations décrites dans le présent document utilisent l’infrastructure de messagerie, lorsque possible, plutôt que de créer des dispositifs spécifiques de la télécopie qui auraient peu de chances d’être mis en œuvre dans un logiciel de messagerie non tourné vers la télécopie.


Le présent document normalise les deux caractéristiques suivantes.

* Confirmation de livraison (Section 2) (exigé)

* Caractéristiques supplémentaires du document (Section 3) (facultatif)


Ces caractéristiques sont pleinement décrites dans un autre document intitulé "Terminologie et objectifs pour la télécopie Internet" [RFC2542].


1.1 Définition des termes


Le terme "traitement" indique l’action de rendre ou de transmettre le contenu du message à une imprimante, un appareil d’affichage, ou un télécopieur.


Le terme "confirmation de traitement" est l’indication donnée par le receveur d’un message qu’il est capable de traiter le contenu de ce message.


Le terme "receveur" indique l’appareil qui effectue la fonction de traitement. Par exemple, un receveur pourrait être mis en œuvre comme agent d’utilisateur de messagerie (MUA) traditionnel sur un ordinateur personnel, un appareil autonome qui restitue les messages en utilisant POP3 ou IMAP, un serveur SMTP qui imprime les messages entrants (similaire à un serveur LPR).


Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans la [RFC 2119].


1.2 Passerelle de télécopie GSTN ("entrée"/"sortie")


Le comportement d’une passerelle de télécopie GSTN à SMTP ("entrée") et de SMTP à la télécopie GSTN ("sortie") n’est pas décrit dans le présent document. Cependant, de telles passerelles DEVRAIENT avoir les caractéristiques de comportement des envoyeurs et des receveurs décrites dans le présent document.


2. Confirmation de livraison et de traitement


Dans la télécopie traditionnelle en temps réel fondée sur GSTN, le terminal receveur accuse réception de chaque page [T.30].


Dans la messagerie Internet, les opérations de livraison (à la boîte aux lettres) et de disposition (sur le papier ou sur un écran) peuvent être séparées dans le temps (à cause de la séparation entre la mémorisation et la transmission des messages) et dans la localisation (à cause de la séparation entre l’agent de livraison (MTA) et l’agent d’utilisateur (MUA)). La confirmation de ces deux opérations est fournie par deux mécanismes différents en cours de normalisation : la notification d’état de livraison (DSN, Delivery Status Notification) [RFC1891], [RFC1894], et la notification de disposition de message (MDN, Message Disposition Notification) [RFC2298], respectivement.


La présente section définit les exigences pour les appareils ou services qui sont à considérer comme conformes au présent document.


2.1 Exigences pour l’envoyeur


Parce qu’un échec de livraison peut survenir (dépassement d’un quota de disque, utilisateur disparu, mauvaise configuration du messageur) un message d’échec de livraison (dans le format décrit par la [RFC1894] ou autrement) peut être envoyé à l’adresse "envelope-from" spécifiée par l’envoyeur. Donc, l’adresse "envelope-from" fournie par l’envoyeur DOIT être capable de traiter correctement de tels messages d’échec de livraison.


2.1.1 Confirmation de livraison

Si l’envoyeur désire une confirmation de livraison, il DOIT demander une notification d’état de livraison en incluant le mot clé esmtp NOTIFY avec la valeur esmtp SUCCESS (paragraphe 5.1 de la [RFC1891]).


2.1.2 Confirmation de traitement

Si l’envoyeur désire une confirmation du traitement, il DOIT demander une notification de disposition de message (section 2 de la [RFC2298]) lors de l’envoi du message lui-même.


Parce qu’un receveur peut ignore en silence une demande de MDN (paragraphe 2.1 de la [RFC2298]) à tout moment :

* les MDN NE DOIVENT PAS être utilisées pour la confirmation de livraison, mais ne sont utiles que pour la notification de disposition ("traitement").

* l’envoyeur NE DOIT PAS supposer que le receveur va répondre à une demande de MDN dans un message suivant, même si le receveur l’a fait dans le passé.


L’adresse fournie par l’envoyeur sur le champ Disposition-Notification-To DOIT être capable de recevoir des messages MDN de la [RFC2298] et DEVRAIT être capable de recevoir des messages qui ne sont pas dans le format de notification de disposition de message (à cause de l’existence de systèmes traditionnels qui génèrent des réponses non conformes à la RFC2298 au champ Disposition-Notification-To). L’adresse Disposition-Notification-To et l’adresse envelope-from DEVRAIENT correspondre pour permettre des réponses automatiques aux demandes MDN (paragraphe 2.1 de la [RFC2298]).


2.2 Exigences pour le receveur


Les receveurs DEVRAIENT mettre en œuvre les notifications de disposition de message [RFC2298] et DEVRAIENT indiquer les caractéristiques de support qu’ils prennent en charge dans les messages DSN et MDN selon la [RFC2530].


Si le receveur est un serveur SMTP, il se comporte comme partie de l’infrastructure receveuse et est donc soumis aux exigences de "l’infrastructure de receveur" du présent document.


Voir aussi les "recommandations au receveur" à la section 5.


2.2.1 Exigences pour le receveur de MDN

Les receveurs DOIVENT être configurables à ignorer en silence une demande de MDN (paragraphe 2.1 de la [RFC2298]).


Si le receveur est un traitement automatique de message qui n’est pas associé à une personne, l’appareil PEUT être configurable à toujours répondre aux demandes de MDN, mais dans tous les cas DOIT être configurable à ne jamais générer de MDN.


Un receveur NE DOIT PAS générer une MDN non sollicitée pour indiquer la réussite d’un traitement. Un receveur PEUT générer une MDN non sollicitée (envoyée à l’adresse envelope-from (Return-Path:)) pour indiquer l’échec du traitement, mais sous réserve de l’exigence de la [RFC2298] qu’il DOIT toujours être possible à un opérateur de désactiver la génération de MDN non sollicitées.


2.2.2 Receveur qui utilise un protocole d’accès de boîte aux lettres

Un receveur qui utilise POP3 [RFC1939] ou IMAP4 [RFC2060] pour récupérer ses messages NE DOIT PAS générer un message Notification d’état de livraison [RFC1894] parce qu’une telle notification, si elle était demandée, aurait déjà été faite par le MTA à la livraison par POP3 ou IMAP4 du message mémorisé.


Le receveur NE DOITPAS utiliser les champs de la RFC822 "To:", "Cc:", "Bcc:", ou tous autres champs d’en-tête contenant des informations sur le receveur pour déterminer la boîte aux lettres ou l’adresse de destination ultime, et NE DEVRAIT PAS utiliser d’autres champs de la RFC822 ou MIME pour effectuer une telle détermination.


2.3 Exigences de l’infrastructure de messagerie


Ce paragraphe explique les exigences de l’infrastructure de messagerie SMTP utilisée par l’envoyeur et le receveur. Cette infrastructure est normalement fournie par le FAI ou des messageurs internes à une compagnie mais peut en fait être fournie par une autre organisation avec des contrats de service appropriés.


2.3.1 Infrastructure d’envoyeur

La prise en charge de DSN [RFC1891] DOIT être fournie par le serveur de soumission de messagerie [RFC2476] utilisé par l’envoyeur et DOIT être mise à la disposition du messageur chargé de communiquer avec les messageurs externes (Internet).


Voir aussi le paragraphe 5.1 du présent document.


2.3.2 Infrastructure de receveur

La prise en charge de la DSN [RFC1891] DOIT être fournie par le messageur externe (accessible par l’Internet) et DOIT être fourni par chaque messageur entre le messageur externe et le receveur. Si le receveur est mis en œuvre comme serveur SMTP, il DOIT aussi prendre en charge la DSN [RFC1891].


3. Capacités supplémentaires du document


La Section 4 de "Mode simple de télécopie utilisant la messagerie Internet" [RFC2305] permet de n’envoyer que le sous-ensemble minimum de format de fichier d'image étiquetée (TIFF, Tag Image File Format) pour une télécopie "sauf si l’envoyeur connaît a priori d’autres champs ou valeurs de TIFF pris en charge par le receveur".


Un receveur PEUT prendre en charge tout ou partie (ou toute combinaison) des profils de TIFF définis dans la [RFC2301], en plus du profil S. Un receveur qui accepte des profils supplémentaires DEVRAIT indiquer cette prise en charge selon les paragraphes 3.2 ou 3.3 du présent document. Par conséquent, un envoyeur PEUT utiliser ces profils TIFF supplémentaires lors de l’envoi à un receveur qui a les capacités correspondantes.


Un envoyeur DEVRAIT être capable de reconnaître et traiter les étiquettes de caractéristiques comme défini dans la [RFC2531] lorsque il passe en revue les capacités présentées par un receveur potentiel. Les règles de correspondance de capacités qui y sont indiquées (par référence à la [RFC2533]) permettent l’introduction de nouvelles caractéristiques qui peuvent n’être pas reconnues par des mises en œuvre plus anciennes.


Un envoyeur PEUT envoyer un message contenant à la fois le sous-ensemble minimum de TIFF pour la télécopie (comme spécifié dans la [RFC2305]) et un TIFF de meilleure qualité utilisant multipart/alternative.


Trois méthodes sont décrites pour que l’envoyeur acquière une telle connaissance :

1. la configuration manuelle de l’envoyeur

2. des capacités de répertoire

3. des capacités retournées dans une MDN ou DSN.


La méthode 3. DEVRAIT être utilisée.


Une mise en œuvre peut mettre localement en antémémoire les capacités et perdre la synchronisation avec les capacités réelles du receveur. Un mécanisme DEVRAIT être fourni pour permettre à l’envoyeur d’outrepasser les capacités mémorisées dans l’antémémoire locale. Noter aussi le paragraphe 4.1 du présent document.


3.1 Configuration manuelle de l’envoyeur


Une façon par laquelle un envoyeur peut envoyer un document qui excède le sous-ensemble minimum permis par la [RFC2305] est que l’usager qui contrôle l’envoyeur outrepasse manuellement les réglages par défaut, normalement receveur par receveur. Par exemple, durant la transmission, un usager pourrait indiquer que le receveur est capable de recevoir des images à haute résolution ou des images en couleur.


Bien qu’étrange et non automatique, ce mécanisme reflète l’état actuel du déploiement de configuration pour les capacités étendues pour les utilisateurs ordinaires de la messagerie Internet.


3.2 Capacités en répertoire


Une direction future pour les caractéristiques améliorées de document est de créer une structure de répertoire des capacités de receveur, déployée, par exemple, à travers LDAP ou le DNS. Le répertoire fournirait un mécanisme par lequel un envoyeur pourrait déterminer les capacités d’un receveur avant la construction ou transmission de message, en utilisant une recherche dans le répertoire. De tels mécanismes ne sont pas définis dans le présent document.


Il y a des recherches actives au sein de l’IETF pour développer une solution à ce problème, qui résoudrait une large gamme de questions posées par la messagerie en différé.


3.3 Capacités retournées dans une MDN ou DSN


Comme précisé à la section 2 du présent document, un envoyeur peut demander une DSN ou MDN positive.


Si le receveur met en œuvre la [RFC2530], la DSN ou MDN qui est retournée peut contenir des informations qui décrivent les capacités du receveur. L’envoyeur peut utiliser ces informations pour une communication ultérieure avec ce receveur.


L’avantage de cette approche est qu’aucune infrastructure supplémentaire n’est requise (à la différence du paragraphe 3.2) et que les informations sont acquises automatiquement (à la différence du paragraphe 3.1).


3.3.1 Restrictions et recommandations

Un envoyeur NE DOIT PAS envoyer un message avec un contenu non traitable pour tenter de provoquer une réponse de capacité MDN/DSN. Faire cela avec un message sans contenu traitable (comme un message contenant seulement une demande de capacités ou un message blanc) va créer la plus grande confusion chez un receveur qui n’est pas déjà conçu pour comprendre la sémantique d’un tel message.


Un receveur DEVRAIT indiquer les profils et caractéristiques prises en charge, même si le receveur ne prend en charge que le profil S de TIFF (l’ensemble minimum pour la télécopie comme défini par la [RFC2305]) de la [RFC2531]. Cela permet à un envoyeur de déterminer que le receveur est conforme à la spécification de télécopie étendue utilisant la messagerie Internet.


4. Considérations sur la sécurité


Comme le présent document est une extension à la [RFC2305], la section des considérations de sécurité de la [RFC2305] s’applique à ce document.


Les considérations de sécurité supplémentaires suivantes sont introduites pour les nouvelles caractéristiques décrites dans le présent document.


4.1 Informations de capacités imprécises


Des informations de capacité imprécises (section 3) pourraient causer un déni de service. Les informations de capacité pourraient être imprécises pour de nombreuses raisons, y compris un serveur de répertoire compromis ou incorrectement configuré, une configuration manuelle inappropriée de l’envoyeur, un DNS compromis, ou une MDN falsifiée. Si un envoyeur utilise des informations de capacité tirées d’une antémémoire, il DEVRAIT y avoir un mécanisme pour permettre que les informations en antémémoire soient ignorées ou outrepassées si nécessaire.


4.2 MDN ou DSN falsifiées


Des DSN ou MDN falsifiées, comme décrit dans les [RFC1892], [RFC1894], [RFC2298] peuvent fournir des informations incorrectes à un envoyeur.


5. Notes de mise en œuvre


La présente section contient des notes pour les mises en œuvre.


5.1 Le messageur de soumission ne prend pas en charge les DSN


Dans certaines installations, le serveur de soumission généralement disponible peut ne pas accepter les DSN. Dans ces circonstances, il peut être utile que l’envoyeur mette en œuvre l’acheminement de messagerie de la [RFC974] ainsi que des fonctions supplémentaires de serveur de soumission de la [RFC2476] afin que l’installation ne soit pas contrainte par les limitations du serveur de soumission en charge.


5.2 Recommandations au receveur


Pour fournir un haut degré de fiabilité, il est souhaitable que l’envoyeur sache qu’un receveur n’a pas pu traiter un message. L’incapacité à réussir à traiter un message peut être détectable par le MTA ou MUA du receveur.


Si le MTA du receveur détermine que le message ne peut pas être traité, il est vivement encouragé à rejeter le message avec un code d’état de 5.6.1. de la [RFC1893]. Ce code d’état peut être retourné en réponse à l’indicateur de données de fin de message si le MTA prend en charge le rapport des codes d’erreur améliorés de la [RFC2034], ou après réception du message en générant un DSN Échec de livraison ("rejet").


Note : Fournir cette fonctionnalité dans le MTA, via l’un ou l’autre des mécanismes décrits ici, est supérieur à fournir la fonction avec des MDN parce que celles-ci doivent généralement être demandées par l’envoyeur (et la demande peut, à tout moment, être ignorée par le receveur). Le rejet de message effectué par le MTA peut toujours survenir sans que l’envoyeur demande un tel comportement et sans que le receveur puisse circonvenir ce comportement.


Si le message contient une demande MDN et que le MUA du receveur détermine que le message ne peut être traité, le MUA du receveur est fortement invité à répondre à une demande MDN et à indiquer l’échec du traitement avec le type de disposition "traité" ou "affiché" et le modificateur de disposition "erreur" ou "avertissement" [RFC2298].


6. Remerciements


Les auteurs tiennent à remercier les membres du groupe de travail Télécopie Internet de l’IETF, et en particulier les contributeurs suivants qui ont fourni leur assistance et leurs apports durant le développement du présent document : Vivian Cancio, Richard Coles, David Crocker, Ned Freed, Graham Klyne, MAEDA Toru, Geoff Marshall, Lloyd McIntyre, Keith Moore, George Pajari, James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford, et Greg Vaudreuil.


7. Références


[RFC0974] C. Partridge, "L’acheminement de la messagerie et le système des domaines", janvier 1986. (Obsolète, voir la RFC 2821)


[RFC1891] K. Moore, "Extension de service SMTP pour les notifications d'état de livraison", janvier 1996. (Obsolète, voir RFC3461) (P.S.)


[RFC1893] G. Vaudreuil, "Codes d'état du système de messagerie améliorée", janvier 1996. (Obsolète, voir RFC3463) (P.S.)


[RFC1894] K. Moore, G. Vaudreuil, "Format de message extensible pour les notifications d'état de livraison", janvier 1996. (Obsolète, voir RFC3464) (MàJ par RFC2852) (P.S.)


[RFC1939] J. Myers, M. Rose, "Protocole Post Office - version 3", mai 1996. (MàJ par RFC1957, RFC2449) (STD0053)


[RFC2034] N. Freed, "Extension de service SMTP pour le retour de codes d'erreur améliorés", octobre 1996. (P.S.)


[RFC2060] M. Crispin, "Protocole d'accès au message Internet - version 4rev1", décembre 1996. (Remplace RFC1730) (Obsolète, voir RFC3501) (P.S.)


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


[RFC2298] R. Fajman, "Format de message extensible pour les notifications de disposition de message", mars 1998. (Obsolète, voir RFC3798) (P.S.)


[RFC2301] L. McIntyre et autres, "Format de fichier pour la télécopie Internet", mars 1998. (Obsolète, voir RFC3949) (P.S.)


[RFC2305] K. Toyoda, H. Ohno, J. Murai, D. Wing, "Mode simple de télécopie utilisant la messagerie Internet", mars 1998. (Obsolète, voir RFC3965) (P.S.)


[RFC2476] R. Gellens, J. Klensin, "Soumission de message", décembre 1998. (Obsolète, voir RFC4409) (P.S.)


[RFC2530] D. Wing, "Indication des caractéristiques de support acceptées en utilisant les extensions de DSN et de MDN", mars 1999. (P.S.)


[RFC2531] G. Klyne, L. McIntyre, "Schéma de caractéristiques de contenu pour la télécopie sur Internet", mars 1999. (Obsolète, voir RFC2879) (P.S.)


[RFC2533] G. Klyne, "Syntaxe de description des ensembles de caractéristiques des supports", mars 1999. (MàJ par RFC2738, RFC2938) (P.S.)


[RFC2542] L. Masinter, "Terminologie et objectifs de la télécopie Internet", mars 1999. (Information)


[T.30] Recommendation UIT-T T.30, "Procédures pour la transmission de facsimile de document dans le réseau téléphonique commuté général", juillet 1996.


8. Adresses des auteurs


Larry Masinter

Dan Wing

Xerox Palo Alto Research Center

Cisco Systems, Inc.

3333 Coyote Hill Road

101 Cooper Street

Palo Alto, CA 94304

Santa Cruz, CA 95060

USA

USA

fax : +1 650 812 4333

téléphone : +1 831 457 5200

mél : masinter@parc.xerox.com

fax : +1 831 457 5208


mél : dwing@cisco.com


9. Déclaration complète de droits de reproduction


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


Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.


Remerciement

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

page - 7 -