https://opennet.ru/openforum/vsluhforumID1/96254.html Внезапно возникла проблема при отправке почты ("от нас") на один домен. Получатель письма не получает, а мне приходит ответ типа такого:<br><br>host remote-server[188.72.12.165] said: 554 5.7.1<br> &lt;my-server.hostname&gt;: Helo command rejected: Access denied (in reply to RCPT<br> TO command)<br><br>На остальные домены все идет отлично. Т.е. проблема при отправке только на один домен.<br><br>У меня Postfix.<br><br>Часть конфига main.cf:<br><br>mynetworks = 127.0.0.0/8<br>myhostname = my-server.hostname<br><br>smtpd_helo_restrictions =<br> permit_mynetworks,<br> permit_sasl_authenticated,<br> reject_invalid_helo_hostname,<br> reject_non_fqdn_helo_hostname,<br> reject_unknown_helo_hostname,<br> permit<br><br>Пароль для отправки верный, аутентификация smtp проходит.<br><br>Это проблема исключительно на моей стороне или не факт? Например, ip моего smtp попал в список спама?<br> https://opennet.ru/openforum/vsluhforumID1/96254.html#19 Mon, 24 Aug 2015 01:05:07 GMT &gt; по RFC удалённая сторона обязана принимать все сообщения на этот адрес.<br><br>Это интернет, тут никто никому ничего не обязан. А особенно, когда дело касается почты (спасибо спамерам).<br>Связаться с постмастером, конечно, лучше, но не всегда проще :( - топикстартер уже писал, что тот на связь не выходит.<br> https://opennet.ru/openforum/vsluhforumID1/96254.html#18 Sun, 23 Aug 2015 11:16:02 GMT &gt; Вряд ли тут пахнет паранойей, это чистой воды маразм. Если удаленный сервер <br>&gt; не принимает сообщения, в то время когда другие работают без сбоев, <br>&gt; есть ли смысл крутить настройки своего сервера, не проще ли связаться <br>&gt; с postmaster, по RFC удалённая сторона обязана принимать все сообщения на <br>&gt; этот адрес.<br><br>Собственно, после общения в теме, на мой взгляд, все просто. Предположим, что каким-то образом мой проблемный сервер не нравится принимающей стороне и принимающая сторона не желает разбираться (или тратить время и ресурсы). Ок. На этот случай у меня и есть разные серверы у разных провайдеров. Я тоже не буду больше тратить время, в том числе и форумчан здесь, т.к. очевидных проблем вроде бы нет, давайте закроем тему. Я могу сделать следующее: подготовлю на другом хостинге smtp и просто сделаю relay уже там. Вот и делов. Это как раз именно такой случай, когда разбор полетов в течение 2+ дней становится дороже других вариантов.<br><br>Всем спасибо. Действительно, помогает общение с коллегами, пусть и у https://opennet.ru/openforum/vsluhforumID1/96254.html#17 Sun, 23 Aug 2015 08:22:39 GMT &gt;&gt; Мой почтовый smtp relay.genver.com.<br>&gt; Ну вот, собственно, 'relay' и может подпадать под какие-то регекспы. Принимающая сторона, <br>&gt; конечно же, не права, если режет входящую почту на основании такой <br>&gt; подстроки, но если вам надо доставлять почту с меньшим кол-вом подобных <br>&gt; казусов, то лучше бы заменить имя хоста на что-то более нейтральное. <br>&gt; На название компании, например, или там alfa/beta/gamma.<br>&gt; Использовать подстроки 'smtp' или 'mail' тоже не стоит, во избежание напороться на <br>&gt; излишне ретивых почтовых админов.<br><br>Вряд ли тут пахнет паранойей, это чистой воды маразм. Если удаленный сервер не принимает сообщения, в то время когда другие работают без сбоев, есть ли смысл крутить настройки своего сервера, не проще ли связаться с postmaster, по RFC удалённая сторона обязана принимать все сообщения на этот адрес. <br>Извиняюсь за тавтологию.<br> https://opennet.ru/openforum/vsluhforumID1/96254.html#16 Sat, 22 Aug 2015 21:12:09 GMT &gt;&gt; След. строка говорит о том, что клиент все же <br>&gt;&gt; опознан.<br>&gt; Авторизован по САСЛу. :) Так точнее.<br><br>Да, конечно. За столько лет к терминологии так и не привык. Спасибо ))<br> https://opennet.ru/openforum/vsluhforumID1/96254.html#15 Sat, 22 Aug 2015 21:10:44 GMT &gt; Ну вот, собственно, 'relay' и может подпадать под какие-то регекспы.<br><br>Никогда не думал про это, если честно. С другой стороны, другие smtp тоже по такому принципу идут (relay4, например. С него все ок идет)... Спасибо, учту.<br> https://opennet.ru/openforum/vsluhforumID1/96254.html#14 Sat, 22 Aug 2015 07:42:46 GMT &gt; След. строка говорит о том, что клиент все же <br>&gt; опознан.<br><br> Авторизован по САСЛу. :) Так точнее.<br><br><br> https://opennet.ru/openforum/vsluhforumID1/96254.html#13 Fri, 21 Aug 2015 23:37:02 GMT &gt; Мой почтовый smtp relay.genver.com.<br><br>Ну вот, собственно, 'relay' и может подпадать под какие-то регекспы. Принимающая сторона, конечно же, не права, если режет входящую почту на основании такой подстроки, но если вам надо доставлять почту с меньшим кол-вом подобных казусов, то лучше бы заменить имя хоста на что-то более нейтральное. На название компании, например, или там alfa/beta/gamma.<br>Использовать подстроки 'smtp' или 'mail' тоже не стоит, во избежание напороться на излишне ретивых почтовых админов.<br> https://opennet.ru/openforum/vsluhforumID1/96254.html#12 Fri, 21 Aug 2015 14:37:09 GMT Ну, в принципе, согласен. У меня дефолтный уровень паранойи ингода дает сбои.<br><br>Мой почтовый smtp relay.genver.com. С него отправляю исходящие письма. И, соотв., именно его не принимает удаленная сторона.<br><br> https://opennet.ru/openforum/vsluhforumID1/96254.html#11 Fri, 21 Aug 2015 11:57:46 GMT По RFC 2821 п. 4.1.1.1 и в последующих, пришедшим ему на смену, в HELO/EHLO положено писать FQDN хоста, зарегенное в DNS или литеральный адрес - IP адрес в квадратных скобках.<br> <br>По RFC 1912 п 2.1 Записи в прямой и обратной зон должны ОДНОЗНАЧНО указывать друг на друга.<br><br>Вы бы не прятали свое имя почтового домена и IP адрес, вы их и так в инете светите почтой, а мы бы тогда могли проверить и сказать точнее, что у вас за проблема. Пока могу лишь предположить, что имя HELO/EHLO не совпадает с FQDN именем хоста в DNS с ip, с которого шлете почту. Такого требования о совпадении в RFC нет , в HELO/EHLO можно писать хоть 3com.com, главное, чтобы оно резолвилось. Но некоторые админы в целях борьбы со спамом включают такое требование. <br>P.S.<br>озвучь свой почтовый домен - проверю твой почтовый домен на уровне DNS.<br>