Всем привет. Долго думал, о чём здесь написать — к сожалению, редко находится на это время и желание. Но недавно случилась одна не очень хорошая история, из которой я сделал выводы и решил, что эта информация может быть кому-то полезна, поэтому хочу рассказать о том, что произошло. История эта связана с электронной почтой, а если быть более точным — с отказом сетевой инфраструктуры РЖД в обслуживании персонального почтового сервера из-за его «недружественности».
Я старался не углубляться сильно в технические моменты, так как посчитал, что для понимания ситуации они не очень важны. Но если кому-то будет интересно, могу попробовать рассказать более подробно о технической стороне вопроса в следующих публикациях.
Введение
Начну издалека. Мне всегда было интересно, как работает электронная почта в интернете, особенно когда я узнал о том, что протокол SMTP очень старый и сохранился в текущем виде до настоящего времени практически без изменений. В конечном итоге я решил попробовать свои силы в настройке собственного почтового сервера. Кто-то скажет, что это не нужно, хотя лично для меня это был весьма интересный и полезный опыт. Но я не буду здесь излагать технические подробности, так как статья вообще не об этом. Могу лишь сказать, что «туториалов» по поднятию своей почтовой системы в интернете сейчас можно найти довольно много, но я бы не рекомендовал считать их абсолютной истиной в последней инстанции, ведь тонкая настройка в конечном итоге вам всё равно потребуется, и понимать, за что именно отвечает тот или иной параметр конфигурации, необходимо.
Следует заметить, что когда я выбирал хостинг-провайдера, я не рассматривал варианты размещения сервера на территории РФ (думаю, причины этого понятны). Изучая различные предложения, в конце концов я остановил свой выбор на небольшом не очень известном провайдере из страны ЕС, географически расположенной недалеко от России (чтобы пинг был поменьше) — здесь без конкретики, чтобы никто не подумал, что я занимаюсь рекламой. Конечно, всё это происходило ещё до начала всем известных событий, поэтому тогда я не мог даже предполагать, что в будущем могут возникнуть проблемы с оплатой. Интересно, что когда всё это началось, провайдер прислал мне уведомление с предложением внести предоплату за как можно больший период времени — и это было ещё до того, как Visa и MasterCard объявили об уходе из РФ. Не знаю, действительно ли они могли предвидеть будущее, но я им очень благодарен — у меня как раз было некоторое количество свободных средств, и я решил воспользоваться ими и продлить аренду сервера на несколько лет вперёд. О прекращении обслуживания российских клиентов, равно как и вообще о своей позиции по отношению к происходящему, провайдер до сих пор не сообщил — поэтому пока можно надеяться, что сервер будет оставаться доступным в ближайшие годы, если только нас не отключат от мирового интернета. А когда наступит время следующей оплаты, ситуация может измениться (хотелось бы, чтобы в лучшую сторону).
Проблема
До недавнего времени никаких серьёзных проблем с отправкой и получением почты я не испытывал — я не осуществляю массовых рассылок, сервер поднимал в первую очередь для личного и семейного пользования. Да, иногда письма у получателей могут попадать в спам, но это общеизвестная проблема для мелких серверов, и со временем она проходит, если всё настроено корректно. Но, как это обычно бывает, беда пришла оттуда, откуда не ждали.
Примерно с начала марта я стал замечать, что мне перестали приходить на почту бланки электронных билетов от РЖД — я люблю ездить по железным дорогам и нередко покупаю билеты онлайн. Само по себе отсутствие бланков не является чем-то катастрофическим, так как все билеты доступны в приложении, а на большинство поездов есть электронная регистрация и при посадке нужно показывать только паспорт. Но сам факт того, что письма раньше приходили, а теперь перестали, насторожил.
Я решил связаться с поддержкой РЖД, отправив письмо по электронному адресу ticket@rzd.ru... и столкнулся с невозможностью это сделать. Сначала в логах почтового сервера начали появляться сообщения об ошибке DNS-резолвинга MX-хостов для домена rzd.ru.
Небольшое отступление по поводу DNS
Для тех, кто не знает, как работает электронная почта: для каждого домена, на который приходят письма, в DNS должны быть прописаны MX-записи, которые содержат имена серверов входящей почты для этого домена. Например, чтобы отправить письмо на адрес test@example.com, следует сначала получить MX-записи для домена example.com и затем соединяться по протоколу SMTP с серверами, на которые эти записи указывают. Если MX-записей нет, вместо них могут использоваться A (или AAAA) записи, но обычно так делать не рекомендуется.
Важный технический момент: одной из мер по предотвращению спама является необходимость обращаться к публичным провайдерам чёрных (и белых) списков доменов и IP-адресов. Эти списки реализованы как DNS-сервера, и их владельцы обычно разрешают использовать их бесплатно в некоммерческих целях, если количество запросов не очень большое. Но при использовании открытых DNS-резолверов (таких как 1.1.1.1 или 8.8.8.8) отследить количество запросов невозможно, потому что этими резолверами пользуется огромное число людей по всему миру. Решением данной проблемы является установка на почтовый сервер локального рекурсивного DNS-резолвера (такого как, например, Unbound), который будет выполнять обращения к DNS-серверам самостоятельно.
Решить проблему с ошибкой резолвинга MX для rzd.ru было просто — Unbound позволяет перенаправлять запросы на другой DNS-сервер для любой зоны. Я добавил в конфигурацию следующие строчки:
forward-zone:
name: "rzd.ru."
forward-addr: 1.1.1.1После этого резолвинг заработал, но письмо на ticket@rzd.ru всё равно не шло. На этот раз причина была в том, что соединение с сервером входящей почты РЖД не устанавливалось из-за таймаута. Сначала я решил, что это какая-то временная проблема, и оставил письмо в очереди. Через 5 дней (да, тогда у меня ещё было терпение) письмо вернулось обратно как недоставленное — соединиться с серверами РЖД так и не удалось.
Переписка с РЖД
Здесь я вспомнил, что в новостях некоторое время назад сообщали о DDoS-атаках на инфраструктуру РЖД, и предположил, что подсеть, где находится мой почтовый сервер, была заблокирована в целях защиты от этих атак. Я не знаю, действительно ли велись из данной подсети какие-то атаки или нет, но мне точно известно, что мой сервер в них не участвовал — наверное, если я напишу об этом в РЖД, его разблокируют? С этими наивными мыслями я решил составить обращение через форму обратной связи РЖД. Ответ они обещали дать в течение 30 дней, но, как ни странно, он пришёл относительно быстро — за 9 дней. Только вот либо я недостаточно подробно изложил суть проблемы, либо сами РЖД решили не заморачиваться, поэтому весь их ответ свёлся к просьбе проверить папку «Спам»:
Интересно, что в контактной форме я указывал обратный адрес, обслуживаемый моим почтовым сервером. И ответ пришёл именно на него, но не с серверов РЖД, а с серверов Google. С серверами РЖД связи всё ещё не было (спойлер: и нет до сих пор). Какое-то время я ждал, надеясь, что проблема всё-таки временная и разрешится через несколько дней — но, конечно же, этого не произошло, поэтому я написал ещё одно письмо уже непосредственно в поддержку на ticket@rzd.ru, где постарался изложить ситуацию как можно подробнее. По понятным причинам мне пришлось делать это с аккаунта Gmail, который раньше был моим основным почтовым аккаунтом, а теперь используется как резервный. Для солидности я представился не единственным владельцем почтового сервера, а одним из его системных администраторов, и сообщил, что на нём зарегистрировано несколько пользователей, которые тоже клиенты РЖД и испытывают аналогичные проблемы. Также я поблагодарил их за предложение проверить папку «Спам», но отметил, что оно является бессмысленным, поскольку мне доступны все логи соединений на сервере. И ещё я напомнил им про то, что письма не только не приходят, но и не отправляются.
В этот раз ответ пришёл быстрее, но ничего полезного в нём опять не было. Сотрудники РЖД просто попробовали соединиться с моим сервером, у них это сделать не получилось, и они сказали, что проблема на моей стороне:
Такой вариант действительно не исключается — ровно до тех пор, пока не установлено, где именно происходит обрыв соединения. Но раз сотрудники РЖД решили не заниматься выяснением подробностей, мне пришлось делать это самостоятельно. Для этого я использовал утилиту traceroute в TCP-режиме, указав порт 25 (основной порт SMTP-соединений между почтовыми серверами) в качестве целевого. Результат трассировки можно видеть ниже — я скрыл IP-адреса некоторых узлов в начале маршрута, чтобы не выдавать информацию о провайдере:
$ traceroute -T -O info -p 25 gvc-cggw-cgfe-01.rzd.ru
traceroute to gvc-cggw-cgfe-01.rzd.ru (217.175.155.64), 30 hops max, 60 byte packets
1 <REDACTED> 0.184 ms 0.124 ms 0.111 ms
2 <REDACTED> 0.363 ms 0.352 ms 0.351 ms
3 <REDACTED> 0.458 ms 0.449 ms 0.439 ms
4 <REDACTED> 0.370 ms 0.354 ms 0.340 ms
5 <REDACTED> 13.133 ms 13.120 ms 13.092 ms
6 GW-TransTeleCom.retn.net (87.245.249.47) 23.123 ms 22.941 ms 22.923 ms
7 spb14ra.transtelecom.net (188.43.208.50) 21.852 ms spb14ra.transtelecom.net (188.43.208.82) 21.727 ms spb14ra.transtelecom.net (188.43.208.50) 21.761 ms
8 spb14ra.transtelecom.net (188.43.208.78) 23.299 ms spb14ra.transtelecom.net (188.43.208.86) 24.061 ms 23.582 ms
9 mskn17ra.transtelecom.net (188.43.235.34) 30.704 ms 30.695 ms 30.725 ms
10 CSS-gw.transtelecom.net (188.43.235.33) 29.512 ms 29.702 ms 30.975 ms
11 * * *
...
30 * * *Здесь видно, что трафик доходит до узла CSS-gw.transtelecom.net (188.43.235.33) и дальше попадает в чёрную дыру. Чтобы понять, что происходит, я попробовал провести аналогичную трассировку, но уже с сервера, расположенного на территории РФ. Результаты для сравнения ниже — всё ещё не хочу рекламировать провайдеров, поэтому скрываю начальные адреса и в этот раз:
$ traceroute -T -O info -p 25 gvc-cggw-cgfe-01.rzd.ru
traceroute to gvc-cggw-cgfe-01.rzd.ru (217.175.155.64), 30 hops max, 60 byte packets
1 <REDACTED> 0.274 ms 21.345 ms 0.324 ms
2 <REDACTED> 0.303 ms 0.578 ms 0.643 ms
3 <REDACTED> 0.654 ms 0.605 ms <REDACTED> 1.602 ms
4 <REDACTED> 1.344 ms * *
5 * mskn17ra.transtelecom.net (188.43.235.34) 1.360 ms 1.330 ms
6 mskn17ra.transtelecom.net (188.43.235.34) 1.464 ms 1.363 ms CSS-gw.transtelecom.net (188.43.235.33) 1.772 ms
7 CSS-gw.transtelecom.net (188.43.235.33) 1.693 ms * *
8 * * *
9 gvc-cggw-cgfe-01.rzd.ru (217.175.155.64) <syn,ack> 2.190 ms * *Здесь с соединением всё в порядке, и более того — видно, что после CSS-gw.transtelecom.net (188.43.235.33) трафик почти сразу попадает на почтовый сервер РЖД. Между ними есть ещё один узел, который нам не ответил, но можно предположить, что это какой-то межсетевой экран. В любом случае, если сравнить эти результаты с предыдущими, то становится ясно, что источник проблемы находится гораздо ближе к РЖД, чем к моему провайдеру.
Результаты обеих проверок (которые, вообще говоря, должны были делать сотрудники РЖД) я отправил в очередном обращении, попросив также по возможности провести обратную трассировку, чтобы получить ещё одно свидетельство о том, на чьей стороне проблема. Очередной ответ был получен в течение нескольких дней. В этот раз без комментариев, просто читайте:
На этом шаге мне надоело вести переписку с РЖД, хотя, в теории, её можно было продолжать и дальше, например, таким образом: США — недружественная страна, а сервера Gmail находятся в ней, так почему же тогда доступ к серверам Gmail не закрыт? Лично мне было бы интересно посмотреть, что они ответят на это, но у меня больше нет желания тратить своё время. И вне зависимости от их ответа, мы и так знаем, в чём причина: если перестанут приходить письма от РЖД на Gmail, то жалобы посыпятся уже тысячами. Поэтому заблокировать Gmail они не могут, а вот личный независимый почтовый сервер — вполне. Конечно, я не думаю, что они блокируют конкретные сервера по IP-адресам: скорее всего, такая блокировка осуществляется по подсетям или даже по страновой принадлежности из WHOIS-данных, а подсеть Gmail просто внесена в белый список.
Выводы
Какой вывод можно сделать из всей этой истории? Если вы можете обойти проблемы с оплатой и продолжаете использовать сервера за границей, нужно быть готовым к появлению аналогичных ситуаций в будущем. И речь здесь идёт не только об электронной почте, так как эти блокировки вряд ли затрагивают лишь один протокол. В частности, это может касаться, например, того же DNS — на моём сервере в последние два месяца такое тоже происходило (помните про проблему с резолвингом MX?).
Чтобы обойти блокировку, мне пришлось арендовать дополнительный виртуальный сервер на территории РФ и добавить его с низким приоритетом в список MX-хостов для своих почтовых доменов. На этом сервере никакая почта не хранится — он соединён с основным через VPN-туннель, в который перенаправляются все входящие SMTP-соединения. Пришлось повозиться с настройками, чтобы при подключении через VPN был виден реальный IP-адрес удалённой стороны, а не локальный адрес сервера в туннеле (это важно для антиспам-проверок), но в конце концов таким способом мне всё-таки удалось получить письмо от РЖД. В теории, через этот же сервер можно также и отправлять письма в РЖД, но, как я уже говорил, вести с ними дальнейшую переписку я не планирую.
Техническое отступление
Полноценная реализация MTA должна проверять все MX-записи в DNS для домена получателя в порядке их приоритета. При любой временной ошибке (таковой является, в частности, отсутствие соединения), возникшей при попытке доставить почту через основной сервер, MTA должен совершить попытку доставки через сервера, указанные в MX с более низким приоритетом. В штатной ситуации, когда связь с основным сервером имеется, более низкоприоритетные MX использоваться не должны.
Кто-то скажет, что описанной здесь проблемы можно было бы избежать, изначально выбрав сервер на территории РФ. На первый взгляд это действительно так, да и проблем с оплатой такого сервера сейчас бы не было. Но даже если не рассматривать вопросы, связанные с безопасностью хранения личной переписки на сервере в РФ, остаётся ещё такой момент: а вы точно уверены, что подобные блокировки могут осуществляться только со стороны российских сервисов? К примеру, ограничение веб-трафика по географическому признаку всегда являлось весьма распространённой практикой — это я говорю по своему опыту, так как нередко наблюдал сообщение «Access Denied» или просто таймауты при попытке зайти на какой-либо иностранный веб-сайт, и началось это задолго до 24 февраля 2022 года. А уж после этой даты я не вижу никаких препятствий к расширению подобных ограничений и на другие виды интернет-трафика — и затронуть они могут не только электронную почту.
Комментарии (94)
baldr
23.04.2022 17:26+7Из Европы уже с начала марта недоступны сервера налоговой, госуслуг и прочие. Пришлось поднять дешёвый сервер в России для VPN, через него и хожу.
muromdx
24.04.2022 12:28Кстати Госуслуги уже стали доступны через европейский VPN (Нидерланды), правда вначале всегда показывается заглушка "Госуслуги сейчас откроются".
dartraiden
23.04.2022 18:02+20Вся эта катавасия с блокировками то в одну сторону (защита российских ресурсов от зарубежного DDoS), то в другую («ты грязный россиянин? иди лесом») лично у меня вызывает вопрос, почему практически ни один сервис в мире не позволяет при регистрации указать более одного адреса эл. почты? Зачастую даже сменить почту нельзя, не подтвердив изменение со старой почты (которая может внезапно послать меня, как россиянина, нахрен).
mortadella372
23.04.2022 19:49+3Возможно, именно поэтому? Те не бага, а фича.
Oblak_F_U
25.04.2022 17:39Я зарегистрировался только для того, чтобы сказать, что согласен с тобой. Жаль, что не могу просто поставить плюсик :/
questor
24.04.2022 10:01+2Новое крепостное право. ¯\_(ツ)_/¯ Люди - новая нефть, данные социального графа там или биометрия. Ну не будут крупные корпорации делиться с кем-то.
spaceatmoon
24.04.2022 10:54+1Использование почты это уже своего рода карго культ. Это чистейшая дыра в безопасности. Мы прямо и говорим сайту. Вот этот почтовый сервер если что владелец этого аккаунта. Нужна возможность регистрации вообще без почты.
Dolios
24.04.2022 14:45+7Так уже. По телефону. Куча сайтов, на которых я ранее регистрировался и заходил по почте, убрали такую возможность. Я бы не сказал, что ствло лучше.
Russula
26.04.2022 12:06В толку-то по телефону?
У меня Теле2 перестал работать
Поддержка сказала, что в стране не удалось заключить договор на роуминг
gecube
24.04.2022 16:31+5На самом деле все эти блокировки являются нарушением очень важного принципа - сетевого нейтралитета. Вот, скажем, я гр-н РФ и нахожусь заграницей. И мне кровь из носу надо воспользоваться госуслугами или записаться на прием в посольство. И как мне это сделать, если наши особо умные админы блочат по географическому признаку? Я уж не говорю о том, что GeoIP попросту может врать. Потому что вчера айпи был в недружественной стране, а сегодня его перекупили - и он принадлежит дружественной. Что за дичь?
vikarti
24.04.2022 19:53+1Все ЕЩЕ хуже.
Расположение IP это мнение авторов Maxmind'а и прочих геобаз.
Они могут расходится во мнениях.
Если при этом они дают возможность свои ошибки корректировать владельцу адресного пространства… ну я помню времена (сейчас я к тому PI-блоку адресов не имею отношения уже давно) когда у меня была возможность MaxMind'у сказать (и потом все именно так и распозновалось) что:
.1 — Лондон
.2 — Москва
.3 — Новосибирск
Реально при этом сервер что анонсировал этот блок /24 не в Лондоне хотя в Англии а туннели на него шли из разных мест но Москвы и Новосибирска там не было. В RIPE DB тоже были не Москва с Новосибирском.
И где эти адреса реально?Или вот адрес одного моего текущего сервера. Определяется как Нидерланды. Вот только плачу я за него в рублях компании официально зарегистрированной в России. Физически он в Нидерландах но контроль — из Росссии. И чей он?
ArkadiyShuvaev
25.04.2022 14:32Ещё хуже ситуация с оплатой коммуналки :) На некоторых поставщиков услуг просто невозможно зайти из Европы, даже через VPN сервера, расположенные в Казахстане, Молдове или другой дружественной стране.
Приходиться знакомых просить зайти под твоим аккаунтом.
Russula
26.04.2022 12:11С каналами тоже самое, говорят нас банят везде
При заходе на Винк говорят - фиг тебе, ты не с правильного места заходишь
Блин вы определитесь (facepalm)
JPEGEC
25.04.2022 07:02+1почему практически ни один сервис в мире не позволяет при регистрации указать более одного адреса эл. почты?
Например Хетцнер позволяет.
Это не коварство менеджеров а недалекость разработчиков сервисов. Хотя где-то их можно понять - повальное безумие подобное нынешнему, все же, нечто новое в истории.
semibiotic
23.04.2022 18:15-4Есть один ньюанс. Исходящий почтовый сервер не должен делить белый адрес с NAT.
NAT-ы могут периодически попадать в черный список CBL, который используется не только самостоятельно, но и в составе нескольких других почтовых черных списков.
Player701 Автор
24.04.2022 13:38+1Не очень понял, к чему это, но на всякий случай уточню, что адрес моего сервера ни с кем не делится по NAT.
cahbe
23.04.2022 18:52+6Мне крайне очень странно что подобная новость появилась только сейчас. Ребят, всё ГОРАЗДО хуже чем можно себе представить. Домашний почтовик на сервере в финляндии который вдруг перестал получать и писать на государственные почты это действительно грустно и печально, но вот что делать тем у кого по понятным причинам сервера давно давным находятся за паребриком? А ведь это просто уйма народу кто уже встречал космонавтов в своих серверных, и тех счастливчиков кто успел до их прихода. В инете куча мануалов с ВПНом в мир, но найти что то внятное как попасть из мира за колючую проволоку почти нет.
А уж как быть с двусторонними запретами так вообще крохи, и те платные.
Ждём с нетерпением манов как и на чём разворачивать каскадные ВПНы. Хотя если есть может кто то поделится?
pae174
23.04.2022 19:26+7В инете куча мануалов с ВПНом в мир, но найти что то внятное как попасть из мира за колючую проволоку почти нет.
Организация VPN из России во внешний мир абсолютно ничем не отличается от организации VPN из внешнего мира в Россию. Никакие такие особенные мануалы не нужны.
karavan_750
23.04.2022 20:22+4найти что то внятное как попасть из мира за колючую проволоку почти нет
Если очень кратко, то находим хостера с присутствием в РФ и иных странах.
Очень желательно, чтоб у хостера была собственная сеть между датацентрами в разных странах.
Арендуем две виртуалки - одну в РФ, вторую во внешнем мире.
Каждую виртуалку настраиваем как точку доступа для клиентов VPN.
Между виртуалками поднимаем канал на любой технологии типа point-to-point.
Далее настраиваем маршрутизацию на каждой по принципу:
- для находящейся в РФ пакеты с адресами назначения в РФ форвардим на внешний интерфейс, все остальное загоняем в канал ptp на вторую виртуалку.
- для находящейся во вне пакеты с адресами назначения в РФ форвардим в канал ptp на виртуалку в РФ, все остальное на внешний интерфейс.
F0iL
23.04.2022 21:39+2Очень желательно, чтоб у хостера была собственная сеть между датацентрами в разных странах.
Можете назвать кого-нибудь из таких?
karavan_750
23.04.2022 21:56+6Одного такого хостера я нашел, но озвучить не могу - попросили не делать им рекламы.
Могу подсказать признаки, по которым искать.
1. ДЦ в разных странах, не обязательно свои, достаточно присутствия.
2. Возможно наличие услуг типа CDN, анонс клиентских BGP сессий.
3. Если у тех. подов попросить лог трасерта между интересующими ДЦ, то в трассе будет не больше двух-трех хопов.
4. На мой вопрос хостеру как у них организована сеть между ДЦ, ответом было наличие арендованной оптики.
nivorbud
23.04.2022 22:43+1Я сам давно пользуюсь таким хостером, но... есть один нюанс - в правилах пользования (ВПС/серверами) строго запрещено подобного рода проксирование.
karavan_750
23.04.2022 23:10+2Есть смысл вам продолжить поиски.
-- Я у вас приобрел две виртуалки с локациями мск и ****.
Планирую использовать их для сплитования маршрутов - российские адреса выводить в мск, а все остальное роутить через ****.
Это не противоречит вашим внутренним правилам?-- Если это не нарушает никаких законов данных локаций, то вы можете использовать это.
Player701 Автор
24.04.2022 13:40Очень желательно, чтоб у хостера была собственная сеть между датацентрами в разных странах.
Интересный вариант - думаю, он был бы более надёжным. Но у моего основного провайдера дата-центров на территории РФ нет.
vikarti
24.04.2022 08:20+2Тут не впн надо (ну если совсем со связностью не плохо)
Тут просто надо почтовую систему которая умеет в кластер и ставить backup-mx где надо
+чтобы умела отправлять почту на разные домены не только напрямую а через выбранные для конкретных целей smarthost'ы(многие сервисы рассылок можно как смартхосты использовать)
С кластером: берем Proxmox Mail Gateway, берем например Selectel и делаем 3 узла — Мск/Амстердам/Ташкент и настраиваем их кидать почту на настоящую почтовую систему (недостаток — если узлы по минимальным требованием то это 0.8(если shared line)-1.5k рублей в месяц за узел).
Настоящая — например на https://mailcow.github.io/mailcow-dockerized-docs/ а transport maps там либо через конкретные узлы Proxmox Mail Gateway(в том плане что допустим на .ru — через узел в Мск, остальное через Амстердам) либо для каких то конфликтных доменов которые ну очень нужны — через что-то отдельное.
Настраиваем SPF и прочие DMARC/MTA-STS.
Если между частями инфрастраструктуры полетела связность — берем и спрашиваем поддержку селектела почему проблемы связи между их же датацентрами.Player701 Автор
24.04.2022 13:46Я выбрал вариант с VPN именно потому, что он не требует настройки второго почтового сервера. Снаружи получается два узла, а по факту весь трафик идёт на один, только разными маршрутами. Такой вариант, конечно, не подходит, если нужно именно резервирование (чтобы почта шла на backup-MX в случае, если основной сервер в дауне), но если речь идёт о сетевых блокировках, этого хватает.
vikarti
24.04.2022 19:55SPF и прочее настроить для этой схемы не забыли по всем гайдам?
Player701 Автор
25.04.2022 10:10Естественно. А кроме SPF здесь ничего не нужно. DKIM, DMARC и MTA-STS привязаны к почтовому домену, а не к конкретному серверу. Проверял с помощью mail-tester.com, он говорит, что всё в порядке.
crawlingroof
23.04.2022 18:53+3Это сделано в соответствии с рекомендациями Федеральной службы по техническому и экспортному контролю России для защиты сервиса электронной почты ФНС от внешнего негативного влияния (компьютерные атаки, вредоносные программы и так далее)».
aMster1
23.04.2022 19:37+2Интересно, а если у меня почта на домене .ru но по факту она хостится на Gmail?
Наш местный провайдер сначала держал свой почтовый сервер, раздал кучу ящиков, а потом решил сократить издержки на администрирование, и перенес всю почту на Gmail.
user5239
24.04.2022 10:47+1Там поручение забанить по иностранным AS, а не по доменному имени. Например, отдельно прилетало поручение не банить крымские AS.
Abyss777
23.04.2022 20:06+3Я в начале марта пустил весь домашний трафик через Финляндию, и началось. И треснул мир напополам... Часть ресурсов не доступна из-за рубежа, ладно гос. структуры, но блин коммерческие компании, аптека Живика, сима-лэнд, авито, ozon, e-katalog. Не верю, что их всех ДДоСят.
Когда список исключений перевалил за два десятка, плюнул и переключил обратно напрямую через РФ. Пришлось наполнять исключениями ресурсы недоступные из РФ. Их оказалось меньше...
resetsa
23.04.2022 21:24+10Зря, ДДОСят все. Начиная от крупных, заканчивая мелкими. Например сайт нашей конторы (около 300 сотрудников), никогда так популярен не был. Печально все это.
vikarti
24.04.2022 08:23+1Смотреть серию статей про BGP в этом плане — последняя — https://habr.com/ru/post/549282/
Ну или купить Adguard vpn и использовать выборочный режим там (либо для загона того что надо в впн либо наоборот пускания того чего не по впн)
isden
24.04.2022 09:50+1Ну озон, например, уже довольно давно только с ru адресов доступен. Часть других ресурсов тоже, еще задолго до известных событий блокировали не ru адреса.
blind_oracle
24.04.2022 10:38У меня Озон из Швейцарии открывается норм, так что видать открыт в мир...
dartraiden
24.04.2022 14:49авито
Авито сознательно ограничивает доступ с диапазонов хостеров. Вероятно, борются таким образом с ботами и скраперами.
Kiborg777
23.04.2022 20:38+2Периодически подобные проблемы возникали и до "специальной военной операции" и не только с российскими провайдерами услуг и не только с личными почтовыми серверами. Например, Яндекс периодически блокировался (под предлогом спама, хотя спама оттуда не наблюдалось, причины блокировки я узнать не смог тогда) американским интернет-провайдером Комкаст, а почта из израильских государственных организаций не доходила на некоторые емаил сервисы вне Израиля (не Gmail, правда, причина - неизвестна).
Поэтому уже как минимум лет десять я держу отдельный email адрес, который физически хостится в Израиле, и отдельно email адреса на Gmail (США), Ukr.net (Украинa) и один - в Европе (на всякий случай, пользуюсь редко, но пользуюсь).
Был адрес на mail.ru где-то с 1999 года, но после 24.02.2022 я его "прибил" - все российские контакты покинули РФ и email на mail.ru стал бесполезен (и, даже, потенциально опасен).
Hemml
23.04.2022 20:40+15Как сотрудник госучреждения (научный институт), волею судеб ответственный за почту, могу сказать в чем дело -- есть некий координационный центр, который последний месяц мониторит угрозы и рассылает рекомендации. Ограничить прием почты (и вообще доступ) из сетей недружественных стран -- одна из них. Сам я слишком ленив, чтобы заниматься таким маразмом, но админы РЖД могли получить приказ от начальства следовать рекомендациям буквально (а рассылаются они официальными письмами, за подписью и печатью) и у них просто нет другого выхода. Смирись.
Javian
23.04.2022 22:53+1Не только они. Я с прошлого лета не могу с почты yandex на личный почтовик в США отправить:
This is the mail system at host yandex.ru.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.You can find the the possible reasons of the undelivered message letter here:
https://yandex.com/support/mail-new/wizard/zout_send/not-got-report-yes-other.htmlPlease, do not reply to this message.
Action: failedStatus: 4.4.3Diagnostic-Code: X-Yandex; Host or domain name not found.
С gmail письма ходят.
vikarti
24.04.2022 08:26+2А что именно они просят ограничить?
Рубить на файрволле все не российские IP адреса?(через что именно определяется не российскость — база вроде MaxMind'а? Российский владелец? А IPv6?)
Было бы интересно посмотреть на эти письма если они не секретные. Можно ли выложить?
Tufed
24.04.2022 13:11Вопрос даже не в лености админов, а в приказе начальства: следовать рекомендациям центра мониторинга угроз. А за самодеятельность отвечать админам отвечать не улыбается.
tbp2k5
23.04.2022 21:52+6Все эти «формы обратной связи» пересылают ваши запросы в некий «Service Desk» который видимо сам пытается ответить или через кучу посредников отвечает не всегда по теме.
IMHO Вам нужно было писать на abuse@rzd.ru или postmaster@rzd.ru — эти адреса должны существовать и работать не зависимо от всяких желаний фильтровать (RFC2142 Section 2).
PS Хотя судя по симптомам, в компании либо нет квалифицированных специалистов либо в руководящей цепочке находятся идиоты которые не слушают своих специалистов и которым наплевать на последствия.Player701 Автор
24.04.2022 13:25+2Я писал и на postmaster@rzd.ru, и на abuse-адрес, который указан во WHOIS-данных для IP их почтовиков. Ответа предсказуемо не последовало.
tbp2k5
24.04.2022 21:41Я писал и на postmaster@rzd.ru, и на abuse-адрес, который указан во WHOIS-данных для IP их почтовиков. Ответа предсказуемо не последовало.
Радует что вы не получили ошибки «такого адреса не существует» (и такая дичь попадается). Я все больше склоняюсь к гипотезе «идиотов» в управляющей цепочке.
По поводу WHOIS: я тут глянул — эти записи указывают на «razinkinrn@css.rzd.ru» — скорее всего личный ящик. Дайте угадать: Заместитель начальника отдела технологического развития РАЗИНКИН Роман Николаевич? Видимо адрес человека который покупал домен. То-ли руки не дошли поправить, то-ли в отпуске… Даже не знаю.
PS Записи в WHOIS не заменяют, а дополняют требования RFC2142. «abuse» контакты из WHOIS в общем случае касаются проблем специфичных для сети (DOS, scan, etc.).
amarao
23.04.2022 23:55+13общаться сгосорганами имонополиями вРФ можнотолько сру и ссу доменов.
простите, пробелзападает.
Gasaraki
24.04.2022 02:00+9Я давно уже хочу, чтобы государство запилило гос почтовик для ящиков населения и юр лиц. Чтобы все письма внутри него считались как официальная бумажная переписка с конкретными требованиями на время ответа для юридических лиц.
А то электронный документоборот у нас узаконен, цифровые подписи есть. Но при этом общение с юр лицами через электронную почту можно считать бесполезным. Ты не докажешь что отправлял письмо и они его получили.
tmin10
24.04.2022 08:51В теории этим должна бы стать госпочта, но сейчас туда у меня ничего не приходило...
blind_oracle
24.04.2022 10:40Когда я ещё в РФ жил мне туда на ГосПочту штрафы от ГИБДД приходили, я где то там выбрал что мол бумажные не шлите. Причём приходило практически мгновенно.
Может там можно и на других подписаться ????
Ndochp
24.04.2022 13:48Вопрос в исходящих, то есть чтобы мое письмо из акка госуслуг на официальный ящик школа 1594 приравнивалось к заказному письму с уведомлением о вручении.
А от гос в меня ГосПочта работает, хорошо и удобно.
Player701 Автор
24.04.2022 13:26Мой домен в зоне .ru, но это не означает, что он обязательно должен обслуживаться российским сервером.
nick-for-habr
24.04.2022 00:08-11Не применительно к ситуации автора, но в целом в 99% процентов случаев проблема в хождении почты при использовании «своего почтового сервера» связана банально с его неполной/неверной настройкой. И никакая «кровавая гэбня» тут не причём — по этим граблям в странах «свободного мира» ходили уже десятки лет назад (и ходят до сих пор иногда), ну а мы — как и они: учимся на своих ошибках.
Да, SMTP — протокол древний и простой как палка, но помимо него в сфере почты ещё ооочень много всего. Опишу из своей практики админа в том числе почты — почему чаще всего ваши письма куда-то не доходят.
1. Некорректная/отсутствие PTR-записи для IP отправляющего сервера. На моих почтовых серверах например попытки подключения с таких адресов сразу идут в null. Кстати для частного лица даже с «белым» IP получить PTR-запись на свой адрес практически нереально ни у одного провайдера. Ну или я таких не знаю.
2. Неполные или вовсе отсутвие настроек SPF, DKIM, DMARC и т.п. У меня каждый отстутсвующий элемент повышает коэффициент вероятности спама. 2-3 таких «прокола», и суммарный коэффициент превышает заданный порог: привет null, но если повезёт — только пометка .
3. Нахождение IP-адреса отправителя в базах типа SORBS и т.п. Очень частая ситуация для почтовиков на популярных облачных площадках, адреса которых в таких списках сидят целыми подсетями, как и диапазоны провайдеров для частных лиц. Я не баню полностью за нахождение в таких списках: так много ложно-положительных срабатываний, но опять же повышаю коэффициент «спамности». Это в комплекте с другими пунктами выше обычно так же приводит к отправке письма в null.
А когда письмо пройдёт эти базовые проверки — тут в дело всупает ещё и эвристика: она то же может добавитьжарушанса на null.
И это только «почтовые» нюансы, не касаясь общесетевых проблем — DNS, маршруты, взаимные блокировки по GeoIP и т.п.
А в РЖД думаю скоро сообразят что они ступили, и поправят у себя настройки: для защиты почты банхаммер по GeoIP выглядит явно избыточным.
TheChief5055
24.04.2022 02:36+3Кстати для частного лица даже с «белым» IP получить PTR-запись на свой адрес практически нереально ни у одного провайдера.
Дом.ру даёт элементарно.
blind_oracle
24.04.2022 10:43+1Билайн Москва (ещё со времён Корбины) со статическим адресом тоже даёт PTR но выбрать его нельзя - он равен твоему логину.
13werwolf13
25.04.2022 10:32чёрта с два. знаю минимум два случая когда домру aka дурдом послали в эротическое пешее с такой просьбой..
mezhuev
26.04.2022 09:08Это делается через личный кабинет в разделе сервисных настроек. Там же можно отключить блокировку SMTP.
Player701 Автор
26.04.2022 09:26Почтовый сервер у себя дома - это, конечно, заманчивая идея. Я задумывался об этом, но в итоге отказался так делать по следующим причинам:
Проблемы с PTR, как уже говорили выше. Не все провайдеры делают PTR-запись физическим лицам, и даже если запись присутствует, она может быть в формате IP-адреса (что-то вроде 1-2-3-4.static.providername.com), а записи такого вида частенько недолюбливают различные антиспам-системы;
Может быть закрыт 25-й порт для исходящих соединений, и далеко не любой провайдер может согласиться его открыть. Возможно, среди российских провайдеров это не очень распространённая практика, но достоверно утверждать не могу;
IP-адреса, предназначенные для раздачи конечным пользователям интернета, обычно заносятся в списки вроде Spamhaus PBL, и не всегда может быть возможность удалить себя оттуда самостоятельно, если вообще может быть (у Spamhaus политика удаления из PBL различается в зависимости от конкретного блока адресов);
Ну и, конечно, вопросы аптайма и резервирования в домашних условиях - даже если вы можете себе позволить оборудование уровня дата-центра, скорее всего, вам это всё равно обойдётся дороже, чем аренда виртуального сервера.
Если ДОМру действительно даёт возможность сделать любую PTR-запись и открыть 25-й порт, то всё равно остаются последние два пункта. При этом вопрос аптайма и резервирования, наверное, даже более важен, чем попадание в чёрные списки (так как это можно обойти с помощью того же VPN-туннеля). Вот вы уехали в отпуск на две недели, а у вас в городе авария на подстанции, нет света полдня. UPS может столько и не протянуть (и не факт, что оборудование провайдера на чердаке тоже не отрубилось), а вам срочно нужно получить или отправить какое-то письмо...
При этом я не говорю, что нет смысла вообще дома держать какой-то сервер, если ваш провайдер выдаёт белый IP-адрес. Но такой критически важный сервис, как электронная почта, я бы хостить у себя "под столом" не стал, особенно с учётом вышесказанных особенностей, связанных с его настройкой.
ValdikSS
24.04.2022 07:04+1Вполне возможно, что проблема вызвана либо сетевыми блокировками, либо нарушением связности в сети. Так как вы █████████████████████████, сказать что-либо конкретное невозможно, посему статья годна только для потехи над ответом, но большого технического смысла не несет.
Player701 Автор
24.04.2022 13:31+1В статье есть лог трассировки TCP-соединения до сервера входящей почты РЖД - там видно, после какого узла трафик дальше не проходит. Похоже, что этот узел напрямую связан с сетью РЖД (если судить по второй трассировке из РФ), поэтому почти уверен, что о нарушении связности здесь речи не идёт.
ValdikSS
24.04.2022 14:45За последний месяц наблюдал минимум четыре случая нарушения связности.
Пост на ЛОРе два дня назад: https://www.linux.org.ru/forum/admin/16851829
проблема действительно была на стороне аплинка, с асимметричным роутингом
Player701 Автор
25.04.2022 10:23Хм, интересно. Да, я в этом не очень хорошо разбираюсь, видимо, возможен и такой вариант. Но РЖД сказали "доступ закрыт", так что, скорее всего, блокировка была целенаправленной.
ABy
24.04.2022 08:29+2А ведь мы выяснили, что даже у странаны есть проблемы с друзьями после 30! Кажется я начинаю догадываться для чего понадобился портал в ад.
kick_starter
24.04.2022 21:43У пьяного неадеквата, бросающегося с топором на соседей, всегда будут проблемы с друзьями.
systmctl
24.04.2022 13:34-4да уж, не просто так говорят что работа в тех. поддержке - не для слабонервных, то условные "чайники", которые не знают на какую кнопку нажать что бы "всё работало", то противоположная крайность вот такие "энтузиасты" как автор, со своими почтовыми серверами, хитро настроенными впнами и тд. и почему-то автор считает что в случае поломки, диагностикой должны заниматься на той стороне, т.е. автор изначально не провёл полную диагностику своих серверов, но уже бросился писать письма в поддержку
Player701 Автор
24.04.2022 13:34+1Да, я, скорее всего, в первый раз не слишком подробно описал им суть проблемы (текст этого обращения не сохранился, т.к. отправлял его из формы обратной связи на сайте). Но в последнем обращении я привёл абсолютно все подробности, включая логи трассировок, и им уже практически ничего не нужно было делать, чтобы понять, на чьей стороне проблема.
Kurochkin
24.04.2022 14:06Даже если они уже увидели, где именно проблема, дальше-то что? Проводить рабочую встречу с ТрансТелеком, чтобы решить проблемы доставки писем на один конкретный адрес, явно никто не будет, пока не поступит распоряжение сверху.
randomsimplenumber
24.04.2022 16:00да уж, не просто так говорят что работа в тех. поддержке - не для слабонервных
Даже если они уже увидели, где именно проблема, дальше-то что?
В любом случае можно использовать генератор отписок. Проблемы индейцев шерифа не волнуют.
tbp2k5
24.04.2022 21:54Даже если они уже увидели, где именно проблема, дальше-то что? Проводить рабочую встречу с ТрансТелеком, чтобы решить проблемы доставки писем на один конкретный адрес...
На самом деле в такой гипотетической ситуации профессионал должен действовать быстро и без указок начальства и связываться с нужными людьми так-как 'a priori' вы не знаете: пропала связность с одним адресом или вас пол-планеты не видит.Player701 Автор
25.04.2022 10:19На самом деле в такой гипотетической ситуации профессионал должен действовать быстро и без указок начальства и связываться с нужными людьми
В идеале - да. По факту - имеем то, что имеем. Вот если бы действительно отрубилось "пол-планеты", они бы просто не смогли не обратить на это внимание (см. заметку про Gmail в статье). Но мой случай, конечно, весьма специфический, поэтому я и не думал, что удастся сразу получить от них вменяемый ответ.
powerbroker
24.04.2022 13:35Указанной здесь проблемы можно было бы избежать, отказавшись от пользования услугами РЖД. Ничто так не способствует излечению продаванов от идиотизма, как целительный Денег-Ноль.
Player701 Автор
24.04.2022 13:35Согласен, но у нас альтернативы РЖД нет, если речь идёт о поездках на поезде, а я люблю путешествовать именно по железным дорогам, поэтому ничего не могу поделать.
Kurochkin
24.04.2022 14:09допишите "... в коммерческой структуре". Пассажирские перевозки скорее всего и так убыточны, т.е. отказ одного, десяти или даже тысяч пассажиров от услуг РЖД никак не скажется на их уровне идиотизма.
Dolios
24.04.2022 14:52Если от услуг РЖД откажутся все обладатели своих почтовых серверов, РЖД этого даже не заметит и никогда об этом не узнает. А вот альтернативы РЖД особо не наблюдается.
Buhram
24.04.2022 16:38-2Очевидно, что если воевать с мирными странами, до железного занавеса не далеко.
Gasaraki
24.04.2022 21:47+1А что в вашем понятии "мирная страна"? Экономическая война - это та же война. И народ из-за нее вполне себе от голода умирает.
dmitry28
25.04.2022 17:29У меня в последнее время периодически идёт отлуп такого вида:
host ericsson-com.mail.protection.outlook.com [104.47.5.36]
SMTP error from remote mail server after RCPT TO:<*******@ericsson.com>:
550 5.7.511
Access denied, banned sender[194.58.110.246]. To request removal from this list
please forward this message to delist@messaging.microsoft.com.
For more information please go to http://go.microsoft.com/fwlink/?LinkId=526653попытки заполнить формы delist остаются без ответа. почтовый сервер на regru
Player701 Автор
25.04.2022 17:37+1Вот это уже настораживает, если форма не работает, но здесь я, к сожалению, не знаю, что сказать - от меня письма иногда попадали в спам, но с 500-ми ошибками ни разу не отклонялись, если только речь не шла о проблеме на стороне получателя (неизвестный пользователь, ящик переполнен и т.д.).
Посмотрел листинги на mxtoolbox - показывает, что ваш IP в UCEPROTECT-L3 (туда заносятся целые подсети). Судя по тому, что мне известно о UCEPROTECT, они занимаются тем, что вымогают деньги за делистинг - об этом пишут, например, здесь. Многие российские подсети в этом списке присутствуют, например, наш рабочий почтовый сервер туда тоже попал, но, тем не менее, мы не испытывали никаких проблем с доставкой. Возможно, в вашем случае это самодеятельность Microsoft.
proximo
25.04.2022 18:29Хм, по работе столкнулся с тем, что и сайт www.pochta.ru недоступен из офиса в Казахстане, попробовал через VPN (Нидерланды,Румыния) - тоже блокируют, судя по трассировке. Проблему решили...но тем не менее, думаю, стоит ожидать таких сюрпризов и дальше...
Pas
Лол, похоже они ещё и не очень в адеквате, указав в ответе серые заNAT адреса своих почтовиков (10.248.25.66-10.248.25.68).
Кстати, обратил внимание, что ряд адресов получателей в зоне ru стали испытывать сложности с получением почты. Их MX-записи перестали резолвиться обычными тупиковыми резолверами время от времени.
nApoBo3
MX записи не резолвятся время от времени потому что dns сервера дождаться, судя по всему под ddos. В частности nic.ru последнее время «колбасит» регулярно.
Player701 Автор
Да, такое тоже было у меня несколько недель назад, но в последнее время проблем именно с nic.ru не замечал.