Как известно, почтовые сервера (MTA) ожидают от почтовых клиентов (MUA) IDN адрес получателя (да и отправителя тоже) в нормализованном виде (т.е. @домен.dp.ua должно быть преобразовано самим почтовым клиентом в @xn--d1acufc.dp.ua до того, как будет передано на сторону сервера). Многие администраторы (и я в том числе) привыкли считать, что большинство клиентов этого не умеют. Но так ли это на самом деле ? Подробную статистику, насколько мне известно, так ни кто и не собрал…
В связи с тем, что сам я не имею возможности установить у себя все имеющиеся почтовые клиенты и их различные версии, и тем более не могу протестировать все существующие почтовые сервисы, прошу помощи читателей. Желающие поучаствовать в тестах должны:
- Отправить e-mail на info@идн-тест.dp.ua с любого своего адреса.
- Подставить адрес info@идн-тест.dp.ua в своей почтовой программе в качестве адреса отправителя и отправить e-mail на vladimir@kiyan.dp.ua (естественно, если используется не какой-либо веб-сервис).
В теле сообщения необходимо указать наименование и версию своего почтового клиента, а так же операционную систему, под которой он был запущен (если, конечно, это был не web-клиент). В теме сообщения желательно указать “IDN-TEST”.
Если отправить не удалось – просьба оставить подробный комментарий на каком этапе случился облом. Если удалось – тоже пишите 🙂
UPD: Таки да, пользователя очень многих почтовых клиентов столкнутся с проблемами при попытке отправить почту владельцу IDN-домена. Не говоря уже о том, сколько проблем будет у самого владельца. Так что я бы пока не рекомендовал с этим связываться, разве что забить домен на будущее… на не слишком близкое будущее… Но несомненный прогресс имеет место, я даже не ожидал.
Thunderbird 2.0.0.24, Windows XP
Корежит IDN адрес при заведении его в качестве дополнительного адреса электронной почты моего аккаунта (после сохранения получается “info@84=-B5AB.dp.ua”).
Если заводить в нормализованном (пунифицированном) виде – тогда все ОК. Ессно адрес отправителя при этом будет @xn--…. Впрочем он в любом случае таким будет, т.к. на сервер мы в любом случае передадим адрес в нормализованном виде и адресат в результате получит письмо с xn--… в поле from.
Отправить сообщение на адрес в нормализованном виде удается, а в не перекодированном виде – нет 🙁
Сборка под FreeBSD так же не поддерживает IDN 🙁
Thunderbird 3.0.6, Windows XP
Та же картина. Единственное исключение – 2.0.0.24 IDN-имя серверу вообще непонятно в каком виде передавал (все после нахождения первого не латинского символа откусывал, насколько я понял), а 3.0.6 передает как есть. Но нам от этого не легче…
Thunderbird 3.1.2, Windows XP
Аналогично предыдущим версиям.
exim мой такое не возлюбил 🙂
[13:25:24] ESMTP< 250-SIZE 10485760
[13:25:24] ESMTP< 250-8BITMIME
[13:25:24] ESMTP< 250-PIPELINING
[13:25:24] ESMTP< 250-AUTH PLAIN LOGIN CRAM-MD5
[13:25:24] ESMTP< 250-STARTTLS
[13:25:24] ESMTP MAIL FROM: SIZE=406
[13:25:24] SMTP RCPT TO:
[13:25:24] SMTP< 501 : domain missing or malformed
** ошибка во время SMTP сессии
*** При отправке сообщения возникла ошибка:
501 : domain missing or malformed
Он и не должен. Вся работа по преобразованию должна быть проведена на стороне клиента.
А гугль сожрал
* Соединение с SMTP сервером: smtp.gmail.com …
[13:31:47] SMTP EHLO mari-laptop.******.net.ua
[13:31:48] ESMTP< 250-mx.google.com at your service, [xx.xx.xxx.xx]
[13:31:48] ESMTP< 250-SIZE 35651584
[13:31:48] ESMTP< 250-8BITMIME
[13:31:48] ESMTP< 250-AUTH LOGIN PLAIN XOAUTH
[13:31:48] ESMTP AUTH LOGIN
[13:31:48] ESMTP [USERID]
[13:31:48] ESMTP [PASSWORD]
[13:31:48] ESMTP MAIL FROM: SIZE=400
[13:31:48] SMTP RCPT TO:
[13:31:49] SMTP DATA
[13:31:49] SMTP . (EOM)
[13:31:50] SMTP< 250 2.0.0 OK 1282300310 c20sm1127818fak.9
claws-mail-3.7.6_1 FreeBSD 8.1 Stable
Delivery to the following recipient failed permanently:
info@xn—-gtbej0a0afc.dp.ua
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 Your message does not conform to RFC2822 standard (state 18).
А это уже веселее
Кстати, я с IDN ничего специально не собирала
С gmail-а можно отправить на info@xn—-gtbej0a0afc.dp.ua, но нельзя на info@идн-тест.dp.ua 🙁
Маш, логи сервера интересны только постольку, поскольку можно посмотреть клиент пытался просто передать домен без PUNY-кодирования, или отбросил не латинские символы в адресе и передал что осталось.
От севера не ожидается, что он будет принимать почтовый адрес с доменным именем, не верным по RFC, а лично я пока что не видел стандарта, который допускал бы в имени поддомена символы, отличные от латинницы, цифр и девиса.
Интересны еще и тем, что claws-mail не выполняет преобразование
Отправляет как введено, или вообще не отправляет ?
Если не трудно, обновись и попробуй еще.
OpenWebMail 2.52 – info@идн-тест.dp.ua не был перекодирован ни при отправке на него, ни попытке использовать его в поле from… и в последней 2.53 ничего такого не добавили, насколько я посмотрел…
mail.ru, hotmail.com, meta.ua, i.ua, rambler.ru – не умеют самостоятельно пунифицировать IDN-адреса
yandex.ru, yahoo.com – пунифицируют самостоятельно и отправляют !
У кого есть аккаунты на других почтовых серверах из более-менее распространенных ? А то лениво для тестов регистрироваться 😉
Lotus Notes 6.5
Клиент попытался отправить имя домена как есть, без пунификации. Сервер его ессно послал…
Outlook Express 6, Windows XP
Пытается найти info@идн-тест.dp.ua в адресной книге вместо того, чтобы пунифицировать его и отправить сообщение…
Домен идн-тест.dp.ua в тестовых целях перенесен на Яндекс. Из того, что я успел проверить – все работает. Есть некоторые не критические замечания (отправлены саппорту Яндекса), но в целом сервис реально можно использовать для работы с IDN-доменами, у кого они уже есть.
Opera 10.61, Windows XP
Пунифицирует и отправляет серверу IDN-адреса как в TO, так и в FROM.
KMail 1.12.4
Пунифицирует и отправляет серверу IDN-адреса как в TO, так и в FROM.
Гы, теме и двух недель нет, а товарищи из Нигерии уже успели прислать мне на info@xn—-gtbej0a0afc.dp.ua сообщение о выигранной лотерее 😉
Thunderbird 3.0.8 не справился ((
Thunderbird 3.1.4
Ничего нового 🙁
Thunderbird 3.1.5
не работает 🙁
The Bat! 4.2.36.4
При отправке преобразование в punycode не производит, указать не пунифицированный адрес в качестве адреса отправителя так же нельзя.
Вроде как professional версия пунифицирует. Надо бы проверить наверняка, у кого есть…
Microsoft Office Outlook 12 (Microsoft Outlook 2007)
Отправить получилось.
В качестве адреса отправителя тоже подставляется.
mutt-1.5.20-2
Отправить получилось.
> Более того, успешно интерпретирует служебные поля в заголовке
>
> Вот как в файле письма
> From: =?koi8-r?B?68nRziD3zMHEyc3J0g==?= <info@xn—-gtbej0a0afc.dp.ua>
>
> Вот как показывает на экране
> From: Киян Владимир
даже так вот…
Обоснуйте повышение цен на домены dp.ua задним числом
1. При чем тут “IDN и почтовые клиенты” ?
2. Откуда вообще взято это “задним числом” ?
Попрошу больше в блоге не спамить (вопрос, не имеющий отношения к теме поста трудно назвать иначе), комментарии буду удалять. Если хотите пообщаться на данную тему – и здесь и на http://nic.dp.ua достаточно моей контактной информации, а если Вы – регистратор, так и мобильный знать должны, я его несколько раз в рассылке публиковал…
Lotus Notes 8.5.1 FP5
При отправке производит преобразование не в punycode, а во что-то другое вида info@0xL5E8E4EDz-0xL5F2E5F1F2z.dp.ua.
С указанием в качестве адреса отправителя не пунифицированного адреса неожиданно возникла проблема иного рода: клиент не позволяет даже сохранить Location (Место вызова) с кириллическим адресом – пишет Invalid or missing domain, так что собственно отправку проверить не получается.
В Thunderbird 24.0.1 добавлена возможность отправки сообщений на адреса электронной почты, расположенные в IDN доменах.
Начиная с версии 6.0, The Bat! поддерживает работу с IDN – доменными именами. IDN – от английского Internationalized Domain Names – интернационализованные доменные имена, которые содержат символы национальных алфавитов, например, президент.рф, почта.рф и тд. К таким доменным именам относятся имена, составленные из букв не латинских алфавитов планеты: кириллица, арабский , китайский алфавит и др. А также можно использовать имена с символами латинского алфавита с диакритическими знаками (немецкий, французский и т.д.)
Таким образом The Bat! может работать с любыми адресами, состоящими из символов национального алфавита, например премьер-министр@правительство.рф.
http://www.ritlabs.com/ru/news/index.php?ELEMENT_ID=4738