2008September2008-09-07J. Yao (CNNIC)W. Mao (CNNIC)
Dans la grande série des RFC décrivant les
adresses de courrier internationalisées, ce document
traite des modifications au protocole SMTP. Il a été remplacé quatre ans
après par le et n'est donc plus une
lecture indispensable.
Plusieurs RFC composent la nouvelle norme EAI ou « Email
Addresses Internationalized » (cf. , remplacé depuis par le ). Les deux principaux concernent le format des
messages () et le dialogue entre deux
serveurs de messagerie, suivant le protocole
SMTP. Ce dernier cas est couvert dans notre
.
Les adresses de courrier en Unicode ne sont
pas en effet compatibles avec le SMTP « brut ». Ainsi, la commande
RCPT TO qui permet d'indiquer le destinataire, ne
prend en paramètre que de l'ASCII. Il faut donc
étendre SMTP (actuellement normalisé en ) pour
permettre de l'UTF-8 en paramètre de commandes
comme MAIL FROM et RCPT
TO. Cette extension se signale avec l'option
UTF8SMTP, dont l'usage permet de vérifier que le
MTA situé en face comprend bien la nouvelle
norme (sections 1 et 2 du RFC). Si ce n'est pas le cas, une adresse en
ASCII facultative peut être utilisée.
La section 3 forme le gros du RFC en spécifiant rigoureusement le
nouveau protocole. Voyons d'abord un exemple de dialogue SMTP avec la
nouvelle extension (C est le client - l'appelant - et S le serveur - l'appelé) :
ALT-ADDRESS=bortzmeyer@afnic.fr
S: 250 2.1.0 Ok
C: RCPT TO:
S: 250 2.1.5 Ok
]]>
Notez les deux adresses, chacune comprenant des caractères non-ASCII, à gauche et à droite du @.
Les serveurs qui mettent en œuvre l'extension
UTF8SMTP doivent également accepter la très
ancienne extension 8BITMIME ()
qui permet, depuis belle lurette, de ne pas se limiter à l'ASCII dans
le contenu des messages, sans pour autant nécessiter des encodages
comme Quoted-Printable (en dépit d'une légende tenace).
La section 3.1 présente la nouvelle extension,
UTF8SMTP. Les extensions SMTP sont définies par
le , section 2.2. Un MTA peut annoncer
qu'il accepte UTF8SMTP, permettant à son pair, s'il l'accepte également,
d'utiliser des adresses UTF-8. C'est également cette section qui
définit ce que doit faire un MTA lorsqu'il tente de transmettre un
message internationalisé à un ancien MTA qui ne gère pas cette
extension. Quatre solutions sont possibles, la plus fréquente sera
sans doute d'utiliser le mécanisme de repli
(downgrade).
La section 3.3 décrit la nouvelle syntaxe pour les
adresses. L'ancienne était limitée à ASCII mais très permissive (bien
qu'on trouve, notamment derrière les formulaires Web, énormément de
logiciels de
« vérification » bogués). En gros, la syntaxe est
qu'une adresse est formée de deux parties, la partie locale et le nom
de domaine, tous les deux séparés par l'arobase. La
nouveauté est que les deux parties peuvent désormais être en Unicode,
avec peu de restrictions sur la partie locale (le nom de domaine étant
soumis aux restrictions du ).
Une adresse alternative tout en ASCII peut être fournie par le
paramètre ALT-ADDRESS. C'est l'objet des sections
3.4 et 3.5. Elle doit s'utiliser conjointement à une modification du
message (qui peut contenir des en-têtes en UTF-8) et l'ensemble du
processus s'appelle le repli
(downgrade). Sa spécification est publiée dans le . (Dans l'exemple de dialogue SMTP plus haut, seul l'expéditeur
avait une adresse alternative.)
Il y a plein d'autres détails dans cette section, comme celui
(section 3.7.1) que
le paramètre de la commande EHLO (un nom de
machine) doit être encodé en Punycode puisque,
à ce stade, on ne sait pas encore si UTF8SMTP est accepté ou pas.
Je n'ai pas encore testé avec mes Postfix,
ni vérifié quels étaient les plans des auteurs de ce logiciel
vis-à-vis de cette extension de SMTP.