8. Modifications de messages
Les sites PEUVENT modifier les soumissions pour assurer la conformité aux normes et à la politique du site. Cette section décrit un certain nombre de ces modifications qui sont souvent considérées comme utiles.
NOTE : En guise de guide pour les décisions locales de mettre en œuvre la modification des messages, une règle primordiale est de limiter ces actions aux remèdes pour des problèmes spécifiques qui ont des solutions claires. C'est particulièrement vrai avec les éléments d'adresse. Par exemple, l'ajout aveugle d'un domaine à une adresse ou à un élément qui en manque entraîne généralement des adresses plus brisées. Une adresse non qualifiée doit être vérifiée comme étant une partie locale valide dans le domaine avant que le domaine puisse être ajouté en toute sécurité.
Tout message transféré ou livré par le MSA DOIT être conforme aux exigences de [SMTP-MTA] et [MESSAGE-FORMAT].
8.1. Ajouter 'Sender'
Le MSA PEUT ajouter ou remplacer le champ 'Sender', si l'identité de l'expéditeur est connue et que cela n'est pas donné dans le champ 'From'.
Le MSA DOIT s'assurer que toute adresse qu'il place dans un champ 'Sender' est en fait une adresse mail valide.
8.2. Ajouter 'Date'
Le MSA PEUT ajouter un champ 'Date' au message soumis, s'il en manque, ou corriger le champ 'Date' s'il n'est pas conforme à la syntaxe [MESSAGE-FORMAT].
8.3. Ajouter 'Message-ID'
Le MSA DEVRAIT ajouter ou remplacer le champ 'Message-ID', s'il en manque, ou s'il n'a pas une syntaxe valide (telle que définie par [MESSAGE-FORMAT]). Notez qu'un certain nombre de clients ne génèrent toujours pas de champs Message-ID.
8.4. Encodage de transfert
Le MSA PEUT appliquer un encodage de transfert au message selon les conventions MIME, si nécessaire et non nuisible au type MIME.
8.5. Signer le message
Le MSA PEUT signer (numériquement) ou ajouter autrement des informations d'authentification au message.
8.6. Chiffrer le message
Le MSA PEUT chiffrer le message pour le transport afin de refléter les politiques organisationnelles.
NOTE : Pour être utile, l'ajout d'une signature et/ou d'un chiffrement par le MSA implique généralement que la connexion entre le MUA et le MSA doit elle-même être sécurisée d'une autre manière, par exemple, en fonctionnant à l'intérieur d'un environnement sécurisé, en sécurisant la connexion de soumission au niveau de la couche transport, ou en utilisant un mécanisme [SMTP-AUTH] qui assure l'intégrité de la session.
8.7. Résoudre les alias
Le MSA PEUT résoudre les alias (enregistrements CNAME) pour les noms de domaine, dans l'enveloppe SMTP et éventuellement dans les champs d'adresse de l'en-tête, sous réserve de la politique locale.
NOTE : La résolution inconditionnelle des alias pourrait être nuisible. Par exemple, si www.example.net et ftp.example.net sont tous deux des alias pour mail.example.net, les réécrire pourrait faire perdre des informations utiles.
8.8. Réécriture d'en-tête
Le MSA PEUT réécrire les parties locales et/ou les domaines dans l'enveloppe SMTP, et éventuellement dans les champs d'adresse de l'en-tête, selon la politique locale. Par exemple, un site peut préférer réécrire 'JRU' en 'J.Random.User' afin de masquer les noms de connexion, et/ou réécrire 'squeaky.sales.example.net' en 'zyx.example.net' pour masquer les noms de machines et faciliter le déplacement des utilisateurs.
Cependant, seules les adresses, les parties locales ou les domaines qui correspondent aux paramètres de configuration locaux spécifiques du MSA doivent être modifiés. Il serait très dangereux pour le MSA d'appliquer des règles de réécriture indépendantes des données, telles que la suppression systématique du premier élément d'un nom de domaine. Ainsi, par exemple, une règle qui supprime l'élément le plus à gauche du domaine, si le domaine complet correspond à '*.foo.example.net', serait acceptable.
Le MSA NE DOIT PAS réécrire une adresse pointant vers l'avant (destination) d'une manière qui viole les contraintes de [SMTP-MTA] sur les modifications des parties locales.