6. Considérations

6.1. Considérations de Sécurité

Ce document décrit l'architecture de messagerie Internet existante. Il n'introduit aucune nouvelle fonctionnalité. Les considérations de sécurité de cette architecture déployée sont documentées de manière exhaustive dans les spécifications techniques référencées par ce document. Ces spécifications couvrent des sujets de sécurité classiques, tels que l'authentification et la confidentialité. Par exemple, les protocoles de transfert d'e-mails peuvent utiliser des mécanismes standardisés pour fonctionner sur des liens authentifiés et/ou chiffrés, et le contenu des messages dispose de normes de protection similaires. Des exemples de tels mécanismes incluent SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880], et S/MIME [RFC3851].

Le cœur de l'architecture de messagerie Internet n'impose aucune exigence ou fonction de sécurité aux composants de bout en bout ou saut par saut. Par exemple, il ne nécessite pas d'authentification des participants et ne tente pas d'empêcher la divulgation de données.

Des attributs de message particuliers peuvent exposer des considérations de sécurité spécifiques. Par exemple, la fonctionnalité de copie carbone invisible de l'architecture invite à des problèmes de divulgation, comme discuté dans la Section 7.2 de [RFC5321] et la Section 5 de [RFC5322]. Le transport de contenu texte ou non texte dans cette architecture a des considérations de sécurité qui sont discutées dans [RFC5322], [RFC2045], [RFC2046], et [RFC4288] ; aussi, des considérations de sécurité sont présentes pour certains des types de médias enregistrés auprès de l'IANA.

Les agents qui répondent automatiquement aux e-mails soulèvent des considérations de sécurité importantes, comme discuté dans [RFC3834]. Les comportements de passerelle affectent les services de sécurité de bout en bout, comme discuté dans [RFC2480]. Les considérations de sécurité pour les filtres de frontière sont discutées dans [RFC5228].

Voir la Section 7.1 de [RFC5321] pour une discussion sur le sujet de la validation de l'origine. Comme mentionné dans la Section 4.1.4, il est courant que les composants de cette architecture utilisent le RFC0791.SourceAddr pour prendre des décisions politiques [RFC2505], bien que l'adresse puisse être « usurpée ». Il est possible de l'utiliser sans autorisation. L'authentification SMTP et soumission ([RFC4409], [RFC4954]) fournit des alternatives plus sûres.

La discussion sur les limites de confiance, les ADMD, les Acteurs, les rôles et les responsabilités dans ce document met en évidence la pertinence et la complexité potentielle des facteurs de sécurité pour le fonctionnement d'un service de messagerie Internet. La conception de base de la messagerie Internet pour encourager l'échange ouvert et occasionnel de messages a rencontré des défis de mise à l'échelle, car la population de participants à la messagerie a augmenté pour inclure ceux qui ont des pratiques problématiques. Par exemple, le spam, tel que défini dans [RFC2505], est un sous-produit de cette architecture. Un certain nombre de documents Standards Track ou BCP sur le sujet ont été publiés (voir [RFC2505], [RFC5068], et [RFC5235]).

6.2. Internationalisation

Les normes de base de la messagerie Internet reposent sur l'utilisation de l'US-ASCII -- c'est-à-dire SMTP [RFC5321] et IMF [RFC5322], ainsi que leurs prédécesseurs. Ils décrivent le transport et la composition des messages comme étant composés strictement de caractères encodés en 7 bits US-ASCII. Les normes ont été progressivement améliorées pour permettre des caractères en dehors de cet ensemble limité, tout en conservant des mécanismes de rétrocompatibilité. Plus précisément :

• Les spécifications MIME ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) permettent l'utilisation de jeux de caractères codés et de schémas de codage de caractères (« charsets » dans la terminologie MIME) autres que l'US-ASCII. Le [RFC2046] de MIME permet au contenu textuel d'un message d'avoir une étiquette apposée qui spécifie le jeu de caractères utilisé dans ce contenu. De même, le [RFC2047] de MIME permet au contenu textuel de certains champs d'en-tête d'un message d'être étiqueté de la même manière. Cependant, étant donné que les messages peuvent être transportés sur des implémentations SMTP capables uniquement de transporter des caractères encodés en 7 bits, le [RFC2045] de MIME prévoit également un « encodage de transfert de contenu » (content transfer encoding) afin que les caractères d'autres jeux de caractères puissent être ré-encodés comme une superposition à l'US-ASCII.

• Le [RFC2045] de MIME permet au contenu textuel d'un message d'être dans un schéma de codage de caractères 8 bits. Afin de les transporter sans les ré-encoder, la spécification SMTP prend en charge une option [RFC1652] qui permet le transport d'un tel contenu textuel. Cependant, l'option [RFC1652] ne traite pas de l'utilisation de contenu 8 bits dans les champs d'en-tête de message, et par conséquent, l'encodage [RFC2047] est toujours requis pour ceux-ci.

• Une série de protocoles expérimentaux sur l'internationalisation des adresses e-mail (EAI) ont été publiés, étendant SMTP et IMF pour permettre aux caractères encodés en 8 bits d'apparaître dans les adresses et autres informations tout au long des champs d'en-tête des messages. [RFC5335] spécifie le format de ces champs d'en-tête de message (qui encodent les caractères en UTF-8), et [RFC5336] spécifie une option SMTP pour le transport de ces messages.

• Les [RFC2045] et [RFC2046] de MIME permettent le transport de véritable matériel multimédia ; un tel matériel permet l'internationalisation car il n'est restreint à aucune langue ou région particulière.

• Les formats des Notifications d'État de Livraison (DSN -- [RFC3462], [RFC3463], [RFC3464]) et des Notifications de Disposition de Message (MDN -- [RFC3798]) incluent à la fois une représentation structurée et non structurée de la notification. Dans le cas où la représentation non structurée est dans la mauvaise langue ou est autrement inappropriée à l'utilisation, cela permet à un MUA de construire sa propre représentation de notification localisée de manière appropriée pour l'affichage à l'Utilisateur.

• POP et IMAP n'ont aucune difficulté à gérer les messages MIME, y compris ceux contenant du 8 bits, et ne sont donc pas une source de problèmes d'internationalisation.

Par conséquent, l'utilisation de l'UTF-8 est pleinement établie dans la messagerie Internet existante. Cependant, la prise en charge des formes d'encodage de longue date est conservée et est toujours utilisée.