Вот это уже настораживает, если форма не работает, но здесь я, к сожалению, не знаю, что сказать - от меня письма иногда попадали в спам, но с 500-ми ошибками ни разу не отклонялись, если только речь не шла о проблеме на стороне получателя (неизвестный пользователь, ящик переполнен и т.д.).
Посмотрел листинги на mxtoolbox - показывает, что ваш IP в UCEPROTECT-L3 (туда заносятся целые подсети). Судя по тому, что мне известно о UCEPROTECT, они занимаются тем, что вымогают деньги за делистинг - об этом пишут, например, здесь. Многие российские подсети в этом списке присутствуют, например, наш рабочий почтовый сервер туда тоже попал, но, тем не менее, мы не испытывали никаких проблем с доставкой. Возможно, в вашем случае это самодеятельность Microsoft.
Хм, интересно. Да, я в этом не очень хорошо разбираюсь, видимо, возможен и такой вариант. Но РЖД сказали "доступ закрыт", так что, скорее всего, блокировка была целенаправленной.
На самом деле в такой гипотетической ситуации профессионал должен действовать быстро и без указок начальства и связываться с нужными людьми
В идеале - да. По факту - имеем то, что имеем. Вот если бы действительно отрубилось "пол-планеты", они бы просто не смогли не обратить на это внимание (см. заметку про Gmail в статье). Но мой случай, конечно, весьма специфический, поэтому я и не думал, что удастся сразу получить от них вменяемый ответ.
Естественно. А кроме SPF здесь ничего не нужно. DKIM, DMARC и MTA-STS привязаны к почтовому домену, а не к конкретному серверу. Проверял с помощью mail-tester.com, он говорит, что всё в порядке.
Я выбрал вариант с VPN именно потому, что он не требует настройки второго почтового сервера. Снаружи получается два узла, а по факту весь трафик идёт на один, только разными маршрутами. Такой вариант, конечно, не подходит, если нужно именно резервирование (чтобы почта шла на backup-MX в случае, если основной сервер в дауне), но если речь идёт о сетевых блокировках, этого хватает.
Согласен, но у нас альтернативы РЖД нет, если речь идёт о поездках на поезде, а я люблю путешествовать именно по железным дорогам, поэтому ничего не могу поделать.
Да, я, скорее всего, в первый раз не слишком подробно описал им суть проблемы (текст этого обращения не сохранился, т.к. отправлял его из формы обратной связи на сайте). Но в последнем обращении я привёл абсолютно все подробности, включая логи трассировок, и им уже практически ничего не нужно было делать, чтобы понять, на чьей стороне проблема.
В статье есть лог трассировки TCP-соединения до сервера входящей почты РЖД - там видно, после какого узла трафик дальше не проходит. Похоже, что этот узел напрямую связан с сетью РЖД (если судить по второй трассировке из РФ), поэтому почти уверен, что о нарушении связности здесь речи не идёт.
Вот это уже настораживает, если форма не работает, но здесь я, к сожалению, не знаю, что сказать - от меня письма иногда попадали в спам, но с 500-ми ошибками ни разу не отклонялись, если только речь не шла о проблеме на стороне получателя (неизвестный пользователь, ящик переполнен и т.д.).
Посмотрел листинги на mxtoolbox - показывает, что ваш IP в UCEPROTECT-L3 (туда заносятся целые подсети). Судя по тому, что мне известно о UCEPROTECT, они занимаются тем, что вымогают деньги за делистинг - об этом пишут, например, здесь. Многие российские подсети в этом списке присутствуют, например, наш рабочий почтовый сервер туда тоже попал, но, тем не менее, мы не испытывали никаких проблем с доставкой. Возможно, в вашем случае это самодеятельность Microsoft.
Хм, интересно. Да, я в этом не очень хорошо разбираюсь, видимо, возможен и такой вариант. Но РЖД сказали "доступ закрыт", так что, скорее всего, блокировка была целенаправленной.
В идеале - да. По факту - имеем то, что имеем. Вот если бы действительно отрубилось "пол-планеты", они бы просто не смогли не обратить на это внимание (см. заметку про Gmail в статье). Но мой случай, конечно, весьма специфический, поэтому я и не думал, что удастся сразу получить от них вменяемый ответ.
Естественно. А кроме SPF здесь ничего не нужно. DKIM, DMARC и MTA-STS привязаны к почтовому домену, а не к конкретному серверу. Проверял с помощью mail-tester.com, он говорит, что всё в порядке.
Я выбрал вариант с VPN именно потому, что он не требует настройки второго почтового сервера. Снаружи получается два узла, а по факту весь трафик идёт на один, только разными маршрутами. Такой вариант, конечно, не подходит, если нужно именно резервирование (чтобы почта шла на backup-MX в случае, если основной сервер в дауне), но если речь идёт о сетевых блокировках, этого хватает.
Интересный вариант - думаю, он был бы более надёжным. Но у моего основного провайдера дата-центров на территории РФ нет.
Не очень понял, к чему это, но на всякий случай уточню, что адрес моего сервера ни с кем не делится по NAT.
Да, такое тоже было у меня несколько недель назад, но в последнее время проблем именно с nic.ru не замечал.
Согласен, но у нас альтернативы РЖД нет, если речь идёт о поездках на поезде, а я люблю путешествовать именно по железным дорогам, поэтому ничего не могу поделать.
Да, я, скорее всего, в первый раз не слишком подробно описал им суть проблемы (текст этого обращения не сохранился, т.к. отправлял его из формы обратной связи на сайте). Но в последнем обращении я привёл абсолютно все подробности, включая логи трассировок, и им уже практически ничего не нужно было делать, чтобы понять, на чьей стороне проблема.
В статье есть лог трассировки TCP-соединения до сервера входящей почты РЖД - там видно, после какого узла трафик дальше не проходит. Похоже, что этот узел напрямую связан с сетью РЖД (если судить по второй трассировке из РФ), поэтому почти уверен, что о нарушении связности здесь речи не идёт.
Мой домен в зоне .ru, но это не означает, что он обязательно должен обслуживаться российским сервером.
Я писал и на postmaster@rzd.ru, и на abuse-адрес, который указан во WHOIS-данных для IP их почтовиков. Ответа предсказуемо не последовало.