IDN и почтовые клиенты

Как известно, почтовые сервера (MTA) ожидают от почтовых клиентов (MUA) IDN адрес получателя (да и отправителя тоже) в нормализованном виде (т.е. @домен.dp.ua должно быть преобразовано самим почтовым клиентом в @xn—d1acufc.dp.ua до того, как будет передано на сторону сервера). Многие администраторы (и я в том числе) привыкли считать, что большинство клиентов этого не умеют. Но так ли это на самом деле ? Подробную статистику, насколько мне известно, так ни кто и не собрал…

В связи с тем, что сам я не имею возможности установить у себя все имеющиеся почтовые клиенты и их различные версии, и тем более не могу протестировать все существующие почтовые сервисы, прошу помощи читателей. Желающие поучаствовать в тестах должны:

  1. Отправить e-mail на info@идн-тест.dp.ua с любого своего адреса.
  2. Подставить адрес info@идн-тест.dp.ua в своей почтовой программе в качестве адреса отправителя и отправить e-mail на vladimir@kiyan.dp.ua (естественно, если используется не какой-либо веб-сервис).

В теле сообщения необходимо указать наименование и версию своего почтового клиента, а так же операционную систему, под которой он был запущен (если, конечно, это был не web-клиент). В теме сообщения желательно указать «IDN-TEST».

Если отправить не удалось — просьба оставить подробный комментарий на каком этапе случился облом. Если удалось — тоже пишите :-)

UPD: Таки да, пользователя очень многих почтовых клиентов столкнутся с проблемами при попытке отправить почту владельцу IDN-домена. Не говоря уже о том, сколько проблем будет у самого владельца. Так что я бы пока не рекомендовал с этим связываться, разве что забить домен на будущее… на не слишком близкое будущее… Но несомненный прогресс имеет место, я даже не ожидал.

IDN и почтовые клиенты: 34 комментария

  1. Thunderbird 2.0.0.24, Windows XP

    Корежит IDN адрес при заведении его в качестве дополнительного адреса электронной почты моего аккаунта (после сохранения получается «info@84=-B5AB.dp.ua»).

    Если заводить в нормализованном (пунифицированном) виде — тогда все ОК. Ессно адрес отправителя при этом будет @xn—…. Впрочем он в любом случае таким будет, т.к. на сервер мы в любом случае передадим адрес в нормализованном виде и адресат в результате получит письмо с xn—… в поле from.

    Отправить сообщение на адрес в нормализованном виде удается, а в не перекодированном виде — нет :-(

  2. Thunderbird 3.0.6, Windows XP

    Та же картина. Единственное исключение — 2.0.0.24 IDN-имя серверу вообще непонятно в каком виде передавал (все после нахождения первого не латинского символа откусывал, насколько я понял), а 3.0.6 передает как есть. Но нам от этого не легче…

  3. 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

  4. А гугль сожрал
    * Соединение с 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

  5. 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 ничего специально не собирала

    • Маш, логи сервера интересны только постольку, поскольку можно посмотреть клиент пытался просто передать домен без PUNY-кодирования, или отбросил не латинские символы в адресе и передал что осталось.

      От севера не ожидается, что он будет принимать почтовый адрес с доменным именем, не верным по RFC, а лично я пока что не видел стандарта, который допускал бы в имени поддомена символы, отличные от латинницы, цифр и девиса.

  6. OpenWebMail 2.52 — info@идн-тест.dp.ua не был перекодирован ни при отправке на него, ни попытке использовать его в поле from… и в последней 2.53 ничего такого не добавили, насколько я посмотрел…

  7. mail.ru, hotmail.com, meta.ua, i.ua, rambler.ru — не умеют самостоятельно пунифицировать IDN-адреса

    yandex.ru, yahoo.com — пунифицируют самостоятельно и отправляют !

    У кого есть аккаунты на других почтовых серверах из более-менее распространенных ? А то лениво для тестов регистрироваться ;-)

  8. Домен идн-тест.dp.ua в тестовых целях перенесен на Яндекс. Из того, что я успел проверить — все работает. Есть некоторые не критические замечания (отправлены саппорту Яндекса), но в целом сервис реально можно использовать для работы с IDN-доменами, у кого они уже есть.

  9. The Bat! 4.2.36.4

    При отправке преобразование в punycode не производит, указать не пунифицированный адрес в качестве адреса отправителя так же нельзя.

    • > Более того, успешно интерпретирует служебные поля в заголовке
      >
      > Вот как в файле письма
      > From: =?koi8-r?B?68nRziD3zMHEyc3J0g==?= <info@xn—-gtbej0a0afc.dp.ua>
      >
      > Вот как показывает на экране
      > From: Киян Владимир

      даже так вот…

    • 1. При чем тут «IDN и почтовые клиенты» ?
      2. Откуда вообще взято это «задним числом» ?

      Попрошу больше в блоге не спамить (вопрос, не имеющий отношения к теме поста трудно назвать иначе), комментарии буду удалять. Если хотите пообщаться на данную тему — и здесь и на http://nic.dp.ua достаточно моей контактной информации, а если Вы — регистратор, так и мобильный знать должны, я его несколько раз в рассылке публиковал…

  10. Lotus Notes 8.5.1 FP5
    При отправке производит преобразование не в punycode, а во что-то другое вида info@0xL5E8E4EDz-0xL5F2E5F1F2z.dp.ua.
    С указанием в качестве адреса отправителя не пунифицированного адреса неожиданно возникла проблема иного рода: клиент не позволяет даже сохранить Location (Место вызова) с кириллическим адресом — пишет Invalid or missing domain, так что собственно отправку проверить не получается.

  11. Начиная с версии 6.0, The Bat! поддерживает работу с IDN — доменными именами. IDN — от английского Internationalized Domain Names — интернационализованные доменные имена, которые содержат символы национальных алфавитов, например, президент.рф, почта.рф и тд. К таким доменным именам относятся имена, составленные из букв не латинских алфавитов планеты: кириллица, арабский , китайский алфавит и др. А также можно использовать имена с символами латинского алфавита с диакритическими знаками (немецкий, французский и т.д.)

    Таким образом The Bat! может работать с любыми адресами, состоящими из символов национального алфавита, например премьер-министр@правительство.рф.

    http://www.ritlabs.com/ru/news/index.php?ELEMENT_ID=4738

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>