Внезапно возникла проблема при отправке почты ("от нас") на один домен. Получатель письма не получает, а мне приходит ответ типа такого:host remote-server[188.72.12.165] said: 554 5.7.1
<my-server.hostname>: Helo command rejected: Access denied (in reply to RCPT
TO command)На остальные домены все идет отлично. Т.е. проблема при отправке только на один домен.
У меня Postfix.
Часть конфига main.cf:
mynetworks = 127.0.0.0/8
myhostname = my-server.hostnamesmtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
permitПароль для отправки верный, аутентификация smtp проходит.
Это проблема исключительно на моей стороне или не факт? Например, ip моего smtp попал в список спама?
обратная зона у вас настроена? Проверте свой ай-пи в спам базах.
> обратная зона у вас настроена? Проверте свой ай-пи в спам базах.ptr настроена. Не у меня, а у хостинга (smtp - vps), но не суть - уже проверял, все ок. Сейчас посмотрю, где проверить на присутствие в спам-листингах. Спасибо!
Добавил: проверил через 2ip.ru. Все ок, нигде меня нет.
Добавил2: у меня есть второй smtp, тоже vps, но в другом хостинге. Через него все ок. Т.е. проблему, возможно, надо искать у меня?
>> обратная зона у вас настроена? Проверте свой ай-пи в спам базах.
> ptr настроена. Не у меня, а у хостинга (smtp - vps), но
> не суть - уже проверял, все ок. Сейчас посмотрю, где проверить
> на присутствие в спам-листингах. Спасибо!
> Добавил: проверил через 2ip.ru. Все ок, нигде меня нет.
> Добавил2: у меня есть второй smtp, тоже vps, но в другом хостинге.
> Через него все ок. Т.е. проблему, возможно, надо искать у меня?"Helo command rejected" - какое имя ваш сервер отдает в приветствии?
Сделайте FQDN и чтобы оно совпадало в тем, что прописано как MX для домена и в обратной зоне.
Вообще-то принимающей стороне нельзя отказать в приеме на основании этого, но случаи бывают всякие ... :)
> "Helo command rejected" - какое имя ваш сервер отдает в приветствии?
> Сделайте FQDN и чтобы оно совпадало в тем, что прописано как MX
> для домена и в обратной зоне.
> Вообще-то принимающей стороне нельзя отказать в приеме на основании этого, но случаи
> бывают всякие ... :)220 my-server.hostname ESMTP Postfix
my-server.hostname - это замена, реальное имя сервера в зоне .com
Здесь все ок.
Полный лог покажи
> Полный лог покажи1 relay postfix/smtpd[28801]: warning: 215.132.165.123: hostname <client_router_hostname> verification failed: Name or service not known
2 relay postfix/smtpd[28801]: connect from unknown[215.132.165.123]
3 relay postfix/smtpd[28801]: 22A4924631: client=unknown[215.132.165.123], sasl_method=DIGEST-MD5, sasl_username=my_email@hostname
4 relay postfix/cleanup[28810]: 22A4924631: message-id=<!&!AAAAAAAAAAAYAAAAAAAAAIcZxIrfYNdHpVrt4z9mJQBigwAAEAAAABAhhQ9rxRtArcU8Wal6FhYBAAAAAA==@hostname>
5 relay postfix/qmgr[28793]: 22A4924631: from=<my_email@hostname>, size=4367, nrcpt=1 (queue active)
6 relay postfix/smtp[28814]: 22A4924631: to=<email_to@receiver.com>, relay=mx.receiver.com[128.42.72.17]:25, delay=0.49, delays=0.26/0.01/0.14/0.07, dsn=5.7.1,
status=bounced (host mx.receiver.com[128.42.72.17] said: 554 5.7.1 <my-server.hostname>: Helo command rejected: Access denied (in reply to RCPT TO command))
7 relay postfix/cleanup[28810]: 921B624648: message-id=<20150820085133.921B624648@my-server.hostname>
8 relay postfix/qmgr[28793]: 921B624648: from=<>, size=6311, nrcpt=1 (queue active)
9 relay postfix/bounce[28815]: 22A4924631: sender non-delivery notification: 921B624648
10 relay postfix/qmgr[28793]: 22A4924631: removedКак я понимаю:
1,2 - ip, с которого я пишу письмо, не найден в mynetworks.
3 - Прошел проверку с именем my_email@hostname
4,5 - подготавливается письмо к отправке.
6 - при отправке удаленный сервер mx.receiver.com не принимает мой сервер
7-10 завершается соединение, письмо удаляется из очереди.Дальше в логе (не стал приводить) идет пересылка ответа (то, что я получаю в ответ):
... Бла-бла-бла
host mx.receiver.com[128.42.72.17] said: 554 5.7.1
<my-server.hostname>: Helo command rejected: Access denied (in reply to RCPT
TO command)Вроде ничего не упустил.
> Как я понимаю:
> 1,2 - ip, с которого я пишу письмо, не найден в mynetworks.Как я понимаю: 1,2 - это как раз отсутствие обратной зоны. dig -x 215.132.165.123 как бы намекают. Или это IP фейковый?
> Как я понимаю: 1,2 - это как раз отсутствие обратной зоны.
> dig -x 215.132.165.123 как бы намекают. Или это IP фейковый?Фейковый. Все верно. К сожалению, пришлось все пропатчить :( политика партии...
1 и 2 все же с моей точки зрения соотв. проверке permit_mynetworks. Т.к. этого ip в mynetworks нет (там только 127.0.0.0/8), то выводится соотв. сообщение. След. строка говорит о том, что клиент все же опознан.
> След. строка говорит о том, что клиент все же
> опознан.Авторизован по САСЛу. :) Так точнее.
>> След. строка говорит о том, что клиент все же
>> опознан.
> Авторизован по САСЛу. :) Так точнее.Да, конечно. За столько лет к терминологии так и не привык. Спасибо ))
> host remote-server[188.72.12.165] said: 554 5.7.1
> <my-server.hostname>: Helo command rejected: Access denied (in reply"Access denied" означает, что ваш helo/ehlo внесли в чёрный список на принимающем сервере. Возможно, под какой-то регексп вы попали, или вас нарочно забанили.
Рассылками не занимаетесь? Как выглядит ваш HELO - сколько в нём точек и/или цифр? Может в нём есть что-то похожее на IP или слово dynamic/adsl/client и т.п.?
> Рассылками не занимаетесь? Как выглядит ваш HELO - сколько в нём точек
> и/или цифр? Может в нём есть что-то похожее на IP или
> слово dynamic/adsl/client и т.п.?Рассылками, естественно, не занимаюсь. Тут и говорить не о чем.
Если HELO - это то, что видно если сделать telnet на 25 порт, то вот:
220 my-server.hostname ESMTP Postfix
(вместо my-server.hostname стоит нормальный домен).
Тут вряд ли злой умысел, скорее совпадение не очень нормальных настроек плюс что-либо из антиспама необычного на принимающей стороне. Я написал запрос и менеджеру, с кем работаем, и, по его ответу, в тех. поддержку мол давайте решим проблему. И тишина. Вот и долбаю со своей стороны. Про получателя ничего не знаю, что у них и как. Проблемы с ними уже были как-то.
По RFC 2821 п. 4.1.1.1 и в последующих, пришедшим ему на смену, в HELO/EHLO положено писать FQDN хоста, зарегенное в DNS или литеральный адрес - IP адрес в квадратных скобках.
По RFC 1912 п 2.1 Записи в прямой и обратной зон должны ОДНОЗНАЧНО указывать друг на друга.Вы бы не прятали свое имя почтового домена и IP адрес, вы их и так в инете светите почтой, а мы бы тогда могли проверить и сказать точнее, что у вас за проблема. Пока могу лишь предположить, что имя HELO/EHLO не совпадает с FQDN именем хоста в DNS с ip, с которого шлете почту. Такого требования о совпадении в RFC нет , в HELO/EHLO можно писать хоть 3com.com, главное, чтобы оно резолвилось. Но некоторые админы в целях борьбы со спамом включают такое требование.
P.S.
озвучь свой почтовый домен - проверю твой почтовый домен на уровне DNS.
Ну, в принципе, согласен. У меня дефолтный уровень паранойи ингода дает сбои.Мой почтовый smtp relay.genver.com. С него отправляю исходящие письма. И, соотв., именно его не принимает удаленная сторона.
> Мой почтовый smtp relay.genver.com.Ну вот, собственно, 'relay' и может подпадать под какие-то регекспы. Принимающая сторона, конечно же, не права, если режет входящую почту на основании такой подстроки, но если вам надо доставлять почту с меньшим кол-вом подобных казусов, то лучше бы заменить имя хоста на что-то более нейтральное. На название компании, например, или там alfa/beta/gamma.
Использовать подстроки 'smtp' или 'mail' тоже не стоит, во избежание напороться на излишне ретивых почтовых админов.
> Ну вот, собственно, 'relay' и может подпадать под какие-то регекспы.Никогда не думал про это, если честно. С другой стороны, другие smtp тоже по такому принципу идут (relay4, например. С него все ок идет)... Спасибо, учту.
>> Мой почтовый smtp relay.genver.com.
> Ну вот, собственно, 'relay' и может подпадать под какие-то регекспы. Принимающая сторона,
> конечно же, не права, если режет входящую почту на основании такой
> подстроки, но если вам надо доставлять почту с меньшим кол-вом подобных
> казусов, то лучше бы заменить имя хоста на что-то более нейтральное.
> На название компании, например, или там alfa/beta/gamma.
> Использовать подстроки 'smtp' или 'mail' тоже не стоит, во избежание напороться на
> излишне ретивых почтовых админов.Вряд ли тут пахнет паранойей, это чистой воды маразм. Если удаленный сервер не принимает сообщения, в то время когда другие работают без сбоев, есть ли смысл крутить настройки своего сервера, не проще ли связаться с postmaster, по RFC удалённая сторона обязана принимать все сообщения на этот адрес.
Извиняюсь за тавтологию.
> Вряд ли тут пахнет паранойей, это чистой воды маразм. Если удаленный сервер
> не принимает сообщения, в то время когда другие работают без сбоев,
> есть ли смысл крутить настройки своего сервера, не проще ли связаться
> с postmaster, по RFC удалённая сторона обязана принимать все сообщения на
> этот адрес.Собственно, после общения в теме, на мой взгляд, все просто. Предположим, что каким-то образом мой проблемный сервер не нравится принимающей стороне и принимающая сторона не желает разбираться (или тратить время и ресурсы). Ок. На этот случай у меня и есть разные серверы у разных провайдеров. Я тоже не буду больше тратить время, в том числе и форумчан здесь, т.к. очевидных проблем вроде бы нет, давайте закроем тему. Я могу сделать следующее: подготовлю на другом хостинге smtp и просто сделаю relay уже там. Вот и делов. Это как раз именно такой случай, когда разбор полетов в течение 2+ дней становится дороже других вариантов.
Всем спасибо. Действительно, помогает общение с коллегами, пусть и удаленно.
> по RFC удалённая сторона обязана принимать все сообщения на этот адрес.Это интернет, тут никто никому ничего не обязан. А особенно, когда дело касается почты (спасибо спамерам).
Связаться с постмастером, конечно, лучше, но не всегда проще :( - топикстартер уже писал, что тот на связь не выходит.