В contacts.mail.ru есть редактирование/импорт/экспорт контактов, в старой версии адресной книги это тоже было. biz-пользователи не могут редактировать корпративную адресную книгу, но это ожидаемое поведение, она управляется администратором домена. Если есть какие-то пожелания их можно оставить здесь, и они будут учтены при планировании новой функциональности.
S/MIME это клиентская технология, она требует управления ключами на стороне клиента, поэтому полноценно ее возможно реализовать только в десктопном приложении или с помощью браузерного плагина, специальной поддержки на сервере она не требует, поэтому любой клиент поддерживающий S/MIME будет нормально работать с почтой Mail.ru или с коробочным решением.
Если вы имеете ввиду реализацию S/MIME с управлением ключами на сервере, то это противоречит идеологии S/MIME и фактически будет фикцией, т.к. у сервера будет возможность имперсонировать клиента. То же самое касается реализации S/MIME через джаваскрипт с хранением ключа шифрованного паролем клиента, т.к. у сервера или потенциального атакующего с доступом к серверу или возможностью MitM TLS в https (такая вероятность существенно выше, чем MitM S/MIME с привязанным сертификатом) все равно есть возможность получить доступ к переписке и имперсонировать пользвоателя.
На стороне сервера для электронной подписи письма испольуется технология DKIM и она, разумеется, реализована.
Да, совершенно верно, поэтому в стандарте дальше рассматриваются подходы (confusable detection) в т.ч. single-script confusables и рекомендации и то что домен соответствует профилю еще не означает что он будет принят. Но мне не совсем понятно, у меня вы что хотите уточнить? Вы показываете метрики, предлагаете методики и рекомендации. Я предлагаю вам в них учесть требования уже имеющихся стандартов и рекомендаций, потому что предлагать метрики, методики и рекомендации без учета стандартов и BCP странно. Зафиксируйте профиль Unicode, с которым вы тестируете на адекватном уровне, на котором ожидается реальная поддержка Unicode в почте, нет смысла тестировать на мусорных доменах, которые поддерживаться никогда не будут.
Единственной рекомеднацией по домену ascii@idn.ascii может быть не использовать его для почты, т.к. он невалиден для почты, а не ждать когда его станут лучше поддерживать.
At receive time, MAIL FROM, FROM header, REPLY TO, and SENDER fields should be checked for validity and tested under the specifics in the Unicode TR39 Highly Restrictive level, as well as the normal RFC 5322 2 and RFC 53213 syntax and validity checks. Messages with invalid addresses may be rejected or delivered to the spam folder.
highly restrictive level в принципе запрещает mixed script (т.е. смешивание символов с разным написанием, в частности латиницу с кириллицей) с исключением для корейских, японских и китайских алфавитов, которые разрешается смешивать с латиницей.
По TR39 проверка адреса емейл идет для домена в целом, а не для отдельной его части.
Стандарт требует в реализации выбрать (отдельно для локальной части адреса и домена) уровни ограничения (restrictions level).
1. ASCII-Only
2. Single Script
3. Highly Restrictive
4. Moderately Restrictive
5. Minimally Restrictive
6. Unrestricted
даже moderately restrictive профиль запрещает использование одновременно кириллицы и латиницы (т.е. idn.ascii в случае кириллицы пройдет только для Minimally Restrictive или Unrestricted). Очевидно, что большая часть реализаций будет выбирать для адресов почты moderately или highly restrictive. В рекомендациях M3AAWG (организация, в которую входят все крупные интернет компании, в том числе и российские) использовать highly restrictive профиль для адресов + рекомендация не принимать или класть в спам письма, адреса в которых не соответствуют этому профилю.
P.S. mail.ru использует highly restrictive, но проверяет отдельно по каждой доменной зоне, поэтому адреса с доменов типа idn.ascii принимаются. Но ждать нормального функционирования таких доменов не стоит, т.к. работа с ними относится к обработке нестандартных случаев.
К счастью, домены .ru и.рф так же позволяют регистрацию только латиницы и кириллицы соответственно, большая часть регистраторов в доменах типа .com так же начали использовать профили, поэтому надеюсь, что использование таких доменов франкенштейна для не-европейских языков все-таки будет иметь отрицательную динамику.
письма с/на Unicode домены и принимаются и доставляются, отображаются они при этом как unicode (punycode в письмах декодируется), и уже очень давно, практически с момента запуска домена .рф
mail.ru не анонсирует SMTPUTF8, но поддерживает Unicode-домены (для их поддержки SMTPUTF8 не требуется). Но смотрите комментарий ниже — домен xn--lmao-kp63c.com (как и домен из emoji в практически любой зоне) не является валидным Unicode для использования в почте. В лучшем случае он будет показан как punycode, в худшем при вводе как unicode вообще будет восприниматься как неправильный, т.к. тот же SMTPUTF8 использования punycode уже не подразумевает.
ascii@idn.ascii, ascii@chinise.ascii, ascii@arabic.ascii, arabic.arabic@arabic из ваших примеров напрямую нарушают рекомендации UTS 39 www.unicode.org/reports/tr39/#Email_Security_Profiles
Вам стоит выкинуть эти примеры из тестов и учесть в методике, т.к. они не являются валидными по текущим стандартам.
По этой же причине, почту в доменах типа idn.ascii держать нельзя от слова совсем, даже если получается его зарегистрировать.
Вы правы кроме первого пункта. Монстры решили сделать так не потому что проще (вообще не проще, т.к. работать с кешем политик сложней чем ключик из DNS вять) и не чтобы спонсировать продавцов сертификатов, а потому что реалии таковы, что DANE пока не взлетел и скорей всего не взлетит еще как минимум лет 5 именно из-за DNSSEC, а жить как-то надо. Похожий на MTA-STS подход уже достаточно давно применялся некоторыми почтовыми провайдерами «негласно» — кешировалась информация о поддержке STARTTLS для крупных доменов, но такой подход опять же не очень устойчив, даже по сравнению с MTA-STS, т.к. не понятно как реагировать на изменение MX-записи, например. Он защищал от вырезания STARTTLS в EHLO но не защищал от более продвинутых атак.
Если брать статистику за 3-5 лет, то DNSSEC приводит к даунтаймам и проблемам безопасности, которые не позволяют делать почтовый (и не только) сервис с нормальными SLA с достаточным количеством девяток. Например несколько лет из-за неудачного перехода на новый ключ произошел многочасовй даунтайм в .ru (который остался практически незамеченным, даже ссылку дать некуда, это многое говорит о проникновении стандарта). В феврале этого года процедура переподписи корневого домена обошлась без даунтайма, но задержалась на несколько часов и проходила со сверлением сейфа (пикантности придавало то, что церемония должна была транслироваться в прямом эфире). Софтварная поддержка так же оставляет лучшего, более-менее работающая поддержка вайлдкардов и поддержка инлайн сайнинг появилась только в bind 9.9.0 (2018й год), а все это надо для нормальной работы DANE в практически любом крупном домене. Последняя уязвимость связанная с DNSSEC была пофикшена в bind в мае этого года. Все это накладывается на то, что большая часть почтовых и DNS серверов практически не обновляются (а обновления нужны для той же замены ключей), и при активном использовании DANE связанность существенно ухудшится.
P.S. справделивости ради, с сертификатами тоже будут проблемы. MTA-STS публикует всего несколько доменов, но среди них уже есть с просроченными сертификатами и если брать статику по DNSSEC за меньший период, то все не так плохо. Но есть большая разница — в случае MTA-STS почта отвалится у того, кто анонсировал что поддерживает MTA-STS и не справился с этой поддержкой, а в случае DANE может отвалиться у того, кто о DANE ничего не знает.
MTA-STS в процессе запуска в тестовом режиме, прямо сейчас он работает только на письмах отправленых через smtp.mail.ru (т.е. из почтовой программы, а не веб-интерфейса) и не блокирует доставку почты. TLS репортинг еще в процессе разработки.
Увидеть срабатывание MTA-STS пока можно только по тому, откуда пришло письмо (при блокировке политикой оно придет с fallback-сервера).
e2e в почте есть, очередная свежая версия S/MIME была принята буквально на днях. Но почта это федеративный сервис, у него во-первых не такие юзкейсы как в мессенджерах да и любой e2e тоже не панацея, потому что «банальное запоминание» сертификата не такое уж банальное, и не такая уж панацея, приучить всех пользователей мира передавать оттиск сертификата вместе с контактом и проверять глазами вы никогда не сможете, а дальше кроме доверия начинаются проблемы утраты доступа к сертификатам из-за сдохших девайсов и забытых паролей. Любой e2e в массовой среде, например то, как он реализован в мессенджерах обычно превращается в фикцию, которая в лучшем случае защищает старую переписки (а для имперсонифицирования контакта достаточно СМС угнать).
В почте риски при при утрате доступа к архиву переписки могут быть вообще существенно выше рисков от MitM.
Если вопрос про облачную почту, то это бесплатно даже при практически неограниченом объеме ящика. За деньги дополнительные фишки, см. «тарифы» в biz.mail.ru/mail
Фаззер не может знать, что в Location прилетела URI из чужого GET, т.к. он не знает логику приложения. Если у вас фаззер знает какой именно ответ должен быть при каком запросе, то это уже не фаззер, а юнит-тесты.
Если вы имеете ввиду реализацию S/MIME с управлением ключами на сервере, то это противоречит идеологии S/MIME и фактически будет фикцией, т.к. у сервера будет возможность имперсонировать клиента. То же самое касается реализации S/MIME через джаваскрипт с хранением ключа шифрованного паролем клиента, т.к. у сервера или потенциального атакующего с доступом к серверу или возможностью MitM TLS в https (такая вероятность существенно выше, чем MitM S/MIME с привязанным сертификатом) все равно есть возможность получить доступ к переписке и имперсонировать пользвоателя.
На стороне сервера для электронной подписи письма испольуется технология DKIM и она, разумеется, реализована.
Единственной рекомеднацией по домену ascii@idn.ascii может быть не использовать его для почты, т.к. он невалиден для почты, а не ждать когда его станут лучше поддерживать.
1c.comvs1c.com,EBAY.COMvsЕВАУ.COM,HABP.comvsНАВР.com,Habr.comvsНаьг.comи т.д.highly restrictive level в принципе запрещает mixed script (т.е. смешивание символов с разным написанием, в частности латиницу с кириллицей) с исключением для корейских, японских и китайских алфавитов, которые разрешается смешивать с латиницей.
По TR39 проверка адреса емейл идет для домена в целом, а не для отдельной его части.
1. ASCII-Only
2. Single Script
3. Highly Restrictive
4. Moderately Restrictive
5. Minimally Restrictive
6. Unrestricted
даже moderately restrictive профиль запрещает использование одновременно кириллицы и латиницы (т.е. idn.ascii в случае кириллицы пройдет только для Minimally Restrictive или Unrestricted). Очевидно, что большая часть реализаций будет выбирать для адресов почты moderately или highly restrictive. В рекомендациях M3AAWG (организация, в которую входят все крупные интернет компании, в том числе и российские) использовать highly restrictive профиль для адресов + рекомендация не принимать или класть в спам письма, адреса в которых не соответствуют этому профилю.
P.S. mail.ru использует highly restrictive, но проверяет отдельно по каждой доменной зоне, поэтому адреса с доменов типа idn.ascii принимаются. Но ждать нормального функционирования таких доменов не стоит, т.к. работа с ними относится к обработке нестандартных случаев.
К счастью, домены .ru и.рф так же позволяют регистрацию только латиницы и кириллицы соответственно, большая часть регистраторов в доменах типа .com так же начали использовать профили, поэтому надеюсь, что использование таких доменов франкенштейна для не-европейских языков все-таки будет иметь отрицательную динамику.
.рфwww.unicode.org/reports/tr39/#Email_Security_Profiles
Вам стоит выкинуть эти примеры из тестов и учесть в методике, т.к. они не являются валидными по текущим стандартам.
По этой же причине, почту в доменах типа idn.ascii держать нельзя от слова совсем, даже если получается его зарегистрировать.
Если брать статистику за 3-5 лет, то DNSSEC приводит к даунтаймам и проблемам безопасности, которые не позволяют делать почтовый (и не только) сервис с нормальными SLA с достаточным количеством девяток. Например несколько лет из-за неудачного перехода на новый ключ произошел многочасовй даунтайм в .ru (который остался практически незамеченным, даже ссылку дать некуда, это многое говорит о проникновении стандарта). В феврале этого года процедура переподписи корневого домена обошлась без даунтайма, но задержалась на несколько часов и проходила со сверлением сейфа (пикантности придавало то, что церемония должна была транслироваться в прямом эфире). Софтварная поддержка так же оставляет лучшего, более-менее работающая поддержка вайлдкардов и поддержка инлайн сайнинг появилась только в bind 9.9.0 (2018й год), а все это надо для нормальной работы DANE в практически любом крупном домене. Последняя уязвимость связанная с DNSSEC была пофикшена в bind в мае этого года. Все это накладывается на то, что большая часть почтовых и DNS серверов практически не обновляются (а обновления нужны для той же замены ключей), и при активном использовании DANE связанность существенно ухудшится.
P.S. справделивости ради, с сертификатами тоже будут проблемы. MTA-STS публикует всего несколько доменов, но среди них уже есть с просроченными сертификатами и если брать статику по DNSSEC за меньший период, то все не так плохо. Но есть большая разница — в случае MTA-STS почта отвалится у того, кто анонсировал что поддерживает MTA-STS и не справился с этой поддержкой, а в случае DANE может отвалиться у того, кто о DANE ничего не знает.
Увидеть срабатывание MTA-STS пока можно только по тому, откуда пришло письмо (при блокировке политикой оно придет с fallback-сервера).
В почте риски при при утрате доступа к архиву переписки могут быть вообще существенно выше рисков от MitM.