Подключаемся к любому узлу сети Интернет на 25 порт через условно порядочного федерального провайдера:
220 smtp27.mail.ru ESMTP ready
Подключаемся через регионала, сильно выделяющегося низким качеством, видим приветствие какого-то левого сервера
220 smtp2.omkc.ru SMTP
Т.е. 25 порт редиректится на SMTP Proxy (притом не прозрачно).
Очевидно, что для борьбы со спамом такой метод едва ли годится, поможет только в редких случаях (скажем, если ботнет пытается слать письмо с одинаковым хэшем с нескольких узлов за короткий интервал времени, либо Байес, но он опять же не эффективен и обратная связь здесь отсутствует). Экономия трафика или балансировка? Опять же инструмент выбран слишком сомнительный (понятно, что можно собрать почту и отправлять её в наиболее выгодное время, пользователь дополнительную задержку доставки в 15-20 сек не ощутит, но для классификации для последующего QoS это опять таки какой-то слишком ущербный метод, для оптимизации маршрутов тоже малопригоден). Да и доля трафика, приходящаяся на открытые подключения к smtp, ничтожно мала.
Остается только такой вариант: провайдер тупо собирает базу адресов (получателей, отправителей) и/или паролей (стоит только сообщить клиенту соответствующий метод аутентификации, никто же не смотрит в логи), пришедших через незащищенное соединение с кучи гаджетов под Android (если пользователь не позаботился о кастомизации дефолтных конфигураций, созданных клиентом на основе mx данных сервера и не включил защищенное соединение) и т.п. не сконфигурированных узлов. Однако хранение и обработка таких данных на стороне провайдера в рамках сбора адресов электронной почты без согласия пользователя — это нарушение целого ряда законов.
Впрочем следовало бы проверить эту гипотезу, воспользовавшись спам-трапом, дабы не быть голословным (что и постараюсь сделать в будущем).
Но это ещё не все последствия: такая политика ISP приводит к тому, что порт 25 отныне жестко привязан к SMTP, ни для чего другого его использовать нельзя (впрочем это такой же маргинал, как один из местных корпоративных (работает только с юр.лицами) провайдеров, который допускает подключение только к портам удаленного узла, относящимся к белому списку — таких стараются избегать при наличии возможности). Да и для SMTP ряд опций становится не доступен (как, впрочем, и сам SMTP сервер при некоторых специфических условиях).
PS. Следовало бы таким же образом проверить pop3 и ещё ряд протоколов.
В случае с pop3 ещё вырисовывается занятный факт:
Пользователь рассчитывает на APOP, а его поддерживают далеко не все POP3 серверы*. В итоге пароль уйдет на proxy как plain text. И даже если сам провайдер не задавался целью собрать пароли от пользовательских учеток, то способствовал злоумышленникам, производящим сниффинг пользовательского канала (благо речь не о Ростелекоме, у которого хваленые ВОЛС дублируют весь трафик всему сегменту, аналогично тому, как это было в 90-е при использовании хабов, что, кстати, тоже довольно абсурдно**).
Впрочем pop3 не успел проверить (косячный провайдер-рукоблуд у меня дома, а домой я только вечером попаду).
PPS. Имя провайдера пока называть не стану, т.к. ещё не проверил некоторые гипотезы (см.выше). Однако в любом случае, ISP, копающийся в вашей почте (и не столь важно, заботитесь ли вы о безопасности, никто не обязывает использовать TLS), заслуживает огласки. Благо большинство почтовых серверов открытое соединение уже не поддерживают.
UPD. Провайдер ОКС
*И даже если сервер и поддерживает, то посредник не может использовать APOP, т.к. транзакция происходит не онлайн, а сервер адресат в итоге пришлет соль, которую посредник заранее знать не может (ну и извлечь пароль из хэша не представляется возможным, само-собой, а кроме хэша APOP ничего не даст). Клиент с правильной конфигурацией забьет тревогу, когда метод авторизации без видимой причины изменится (явный признак атаки man-in-the-middle), но речь о дефолтных конфигах (полученных в 2 клика после указания адреса на Android устройствах, например) и о неосведомленном пользователе (договор совершенно невменяем, кроме обилия сомнительных с юридической т.з. фрагментов, он практически ничего и не содержит, в т.ч. и технической части совсем не содержит).
**Некоторые технологические особенности СКС, разворачиваемой Ростелекомом в рамках внедрения GPON. В простейшем представлении — объединение физической среды для нескольких оптических каналов (коллизии проблем не вызывают, а пропускная способность канала имеет большой запас, впрочем заявленная перспективная пропускная способность канала физически недостижима в т.ч. и из-за таких вот особенностей топологии, так что клиент вполне обоснованно может считать себя обутым в очередной раз, что, впрочем, несколько лучше, нежели ситуация с провайдерами, которые продают тарифы, превосходящие по скорости технические возможности текущей сети (по 15/23 абонента на одном FE коммутаторе при заявленной скорости по 10-15 Mbps каждому абоненту)).
