Как избежать полного адреса электронной почты для SMTP в заголовках, если адрес электронной почты содержит символы, отличные от ascii - PullRequest
0 голосов
/ 09 апреля 2020

Речь идет об отправке электронных писем с не-ASCII-символами в адресе электронной почты.

Когда я использую отправку содержимого TO / RCPT на SMTP-сервер, я знаю, что мне нужно здесь использовать punycode.

А как насчет заголовка To: и From: Опять же, я знаю, что если дружественная к пользователю часть содержит не ascii char, я могу использовать стандартную кодировку заголовка, которую я также использую для этой темы. Но эта кодировка используется только для удобной части.

Но что, если адрес электронной почты содержит не ascii char? Как должен быть отформатирован заголовок To.

Так как кодировать "Tüst"?

Насколько я знаю, это кодировка.

"=?iso-8859-1?Q?T=FCst?="<tüst@domain.de>

Но что с адрес электронной почты.

На самом деле: я не понимаю RF C. Я очень старался, но потерпел неудачу.

1 Ответ

0 голосов
/ 22 апреля 2020

Ответ таков: UTF-8 - это правильный способ кодирования заголовка.

После еще одного исследования я нашел ответ, скрытый внутри этой статьи:

https://en.wikipedia.org/wiki/International_email

Хотя традиционный формат раздела заголовка сообщения электронной почты позволяет включать не-ASCII-символы в часть значения некоторых полей заголовка, используя слова в кодировке MIME (например, в отображаемых именах или в поле заголовка субъекта), MIME-кодирование не должно использоваться для кодирования другой информации в заголовке, например адреса электронной почты, или полей заголовка, таких как Message-ID или Received. Кроме того, MIME-кодирование требует дополнительной обработки заголовка для преобразования данных в представление слова MIME и из него и ухудшает читаемость раздела заголовка.

Стандарты 2012 RF C 6532 и RF C 6531 допускает включение символов Unicode в содержимое заголовка с использованием кодировки UTF-8 и их передачу по SMTP - но на практике поддержка развивается медленно. [5]

...