Le problème est que cela: J'utilise un service de livraison par courrier électronique tiers qui n'accepte pas les adresses postales avec des caractères non-ASCII dans la partie Nom, comme Müller@example.com.
encoder une telle adresse avec punycode:
http://fr.wikipedia.org/wiki/punycode
donne cette adresse:
xn--mller-kva@example.com
et l'envoi de courrier à celui-ci via le service semble fonctionner.
Cependant, je ne suis pas sûr si quelqu'un ne pouvait pas enregistrer "xn-mller-kva@example.com" directement, recevant ainsi des courriels destinés à "müller@example.com".
Cet affrontement est-il possible? Y a-t-il d'autres solutions pour ce problème?
Merci pour les réponses. Voici un résumé de ce que nous avons appris:
5 Réponses :
Quelques tests ont fait quelques tests. Les UMLAUTS de la partie locale semblent fonctionner dans certaines configurations. Ni mes mua (griffes) ni le relais sortant (EXIM) ni le MTA récepteur (Postfix) ne se sont plaints ou que toute conversion de punycode. Des fournisseurs comme Gmail et Hotmail ne permettent pas de ne pas autoriser les UMLAUTS du tout (Webmail testé et SMTP entrant et sortant). Je n'ai trouvé aucune documentation sur cette affaire qui suggère un punycodage de pièces locales.So, car il n'est pas documenté et que personne ne le fait, il n'y a pas de problème d'affichage: -)
Conclusion: Vous ne devriez probablement pas accepter les UMLAUTS dans la partie locale en premier lieu et même essayer d'envoyer un courrier électronique à ces adresses. (Si les grands joueurs ne le font pas et que ce n'est pas documenté / supporté par RFC, pourquoi devriez-vous?)
Vous pouvez encoder des sections des champs d'en-tête de courrier dans différents codages de caractères à l'aide d'un format, comme les suivants: =? UTF-8? B? W6HDQ8O0? = Cela vous permet d'intégrer des objets comme des UMLAUTS, mais je suis sûr que ça ne veut pas t Travailler pour la partie d'adresse réelle.
Il n'y a pas de raison pour laquelle vous ne pouvez pas utiliser ces caractères pour former votre adresse. RFC5322 Définit les caractères pouvant apparaître dans la partie d'adresse de la section 3.4 et tous les Les caractères que vous utilisez ci-dessus sont valides. Cependant, comme l'ajout de l'autre commentaire, il est tout un peu infructueux si les clients de messagerie que vous envoyez pour ne peuvent pas analyser ce format.
Certains serveurs SMTP peuvent "accidentellement" permettre des UMLAUTS, mais comme ils ne sont pas dans les gammes de caractères supportés, je ne risquerais pas.
Les caractères non-ASCII ne sont pas autorisés dans la partie locale des adresses électroniques. Période. Le punycode n'est que pour les domaines, pas pour des parties locales d'adresses électroniques.
Cependant, il est très probable que l'IETF adopte une norme qui rend possible les parties locales internationalisées. Cette norme ne sera toutefois pas basée sur le punycode.
"Les caractères non-ASCII ne sont pas autorisés dans la partie locale des adresses électroniques", car cette réponse a été écrite, la situation a changé, voir outils.ietf.org/html/rfc6531
Oui. Et à moins d'une façon standard d'approcher cela, il n'y a pas encore de moyen approprié de l'approcher!
Je me suis ennuyé et je suis en train de rechercher ce soir, et apparemment ceci est désormais codifié dans la norme SMTP étendue, notamment SMTPTPUTF8 selon RFC 6531. Voir http://fr.wikipedia.org/wiki/extenced_smtp#smttputf8
Ma brève expérience à l'aide des noms de boîte aux lettres Emoji renvoyé l'erreur suivante lors de l'envoi via Gmail:
Une partie locale de l'enveloppe contient UTF8 mais le serveur distant n'a pas offert à SMTPUTF8
Ceci est le même, que j'ai utilisé la version Emoji ou Punycode de l'adresse.
Le seul moyen standard d'envoyer des caractères non US-ASCII dans la partie locale d'une adresse électronique est via RFC6532 (en-têtes de messagerie internationalisée) et RFC6531 (extension SMTP pour SMTPTPUF8).
Autant que je sache, il n'existe pas de moyen standard d'encoder des caractères non-ASCII dans une partie locale d'une adresse email notablement:
Le code Puny est réservé aux noms de domaine uniquement, pas la partie locale. Mais vous pouvez avoir une partie locale qui arrive à ressembler au codage puny de certaines chaînes, mais il doit être affiché à son formulaire codé Puny. Si un programme de messagerie décide de l'afficher après le décodage puny, il est un comportement non standard.
le mécanisme de codage de mot codé mentionné dans l'une des réponses (le à la fin, cela signifie que théoriquement, vous pouvez espérer qu'aujourd'hui (2019) tous les serveurs de messagerie
Smttputf8 et tous les courriers internationalisés de soutien du client, mais malheureusement je voudrais
pas compter sur elle si c'est important.
BTW. Il arrive que la partie locale d'une adresse électronique soit la seule chose dans
la ou les normes de courrier où vous voudrez peut-être avoir des caractères non ascii et là
n'est pas un moyen de le coder (autant que je sache). Toutes les autres pièces ont codé mot, puny, pourcentage, base64, coté-imprimable ou une autre forme de mécanisme de codage. =? uf-8? q? foobar? = chose) est pas applicable à La partie locale d'une adresse de messagerie, uniquement au nom d'affichage d'une boîte aux lettres (qui est quelque chose de différent, mais associée à coire, c'est-à-dire que votre programme de messagerie peut afficher au lieu de l'adresse de messagerie).
müler@example.com et xn-mler-0ra@example.com
sont deux adresses électroniques complètement non liées qui auraient juste
la même signification s'ils seraient des domaines (mais ils ne sont pas
afin qu'ils puissent entrer en collision).
Cela ne serait-il pas vrai pour quoi que ce soit punycodé? Si quelqu'un voulait vraiment le domaine xn-stjrt-ira.xxx , par exemple, il serait "affrontement" avec la version punydecodée du nom. Quel est le problème réel que vous percevez?
Eh bien, j'espère que les bureaux d'enregistrement enrartiraient-ils et combineront automatiquement les versions codées et non codées d'un domaine, sans égoïsme (intentionnellement ou non) n'est possible. J'aimerais savoir si cela est vrai et si cela s'applique également aux fournisseurs de courrier électronique.
Comment voyez-vous que l'entrepoiffage vient à cela? Vous voulez dire le cas où vous vous inscrivez xn-mller-kva @ avec l'intention malveillante de recevoir des e-mails destinés à Müller , qui n'a pas cette adresse? Les clients e-mail sont-ils même des adresses de punycode?
Je l'ai testé avec une adresse mailinator.com et j'ai reçu un courrier envoyé à l'adresse codée. Et oui, c'est ce que j'essaie de savoir si ce problème est un. "Spoofing" peut aussi être involontaire, je suppose que si quelqu'un aime les adresses cryptiques avec beaucoup de tirets ...
Vous voulez dire qu'il a envoyé un courrier à xn - mller-kva @ avec succès? Pourquoi n'est-ce pas? :) Mais avez-vous trouvé un client de messagerie qui punycodes adresse e-mail? Parce que c'est la seule façon du problème peut survenir, non?
Selon RFC 5322, vous ne pouvez pas avoir de UMLAUTS dans la partie locale d'une adresse électronique de toute façon, l'adresse aurait donc toujours besoin d'être "punchyed" pour fonctionner correctement, n'est-ce pas? en.wikipedia.org/wiki/email_address#Syntax
@bzlm: Cela n'a pas vraiment d'importance pour mon cas d'utilisation, car je n'envoie que des mails (bulletins d'information et tels).
@Gryphius: Eh bien, certains utilisateurs ont essayé de s'inscrire à une lettre d'information avec une Umlaut dans leur pièce locale par courrier électronique, alors je suppose que au moins certains fournisseurs permettent aux UMLAUTS. Peut-être que tout est manipulé codé par eux sous les couvertures ...
... Mais probablement pas par punycode. :)