С одной организации до меня не доходила, почта, стал разбираться в причине.
Кусок моего лога:
Dec 5 10:46:59 mail postfix/smtpd[11604]: connect from domain.ru[xxx.xxx.xxx.xxx]
Dec 5 10:46:59 mail postfix/smtpd[11604]: NOQUEUE: reject: RCPT from domain.ru[xxx.xxx.xxx.xxx]: 450 4.7.1 <host.domain.ru>: Helo command rejected: Host not found; from=<user@domain.ru> to=<main@domain1.ru> proto=ESMTP helo=<host.domain.ru>
Dec 5 10:46:59 mail postfix/smtpd[11604]: disconnect from domain.ru[xxx.xxx.xxx.xxx]В кратце причина:
host.domain.ru Имя хоста в заголовках
domain.ru реальное имя доменав соответсвии с RFC821 в HELO должно быть имя домена. а у тут не имя домена, а имя хоста в этом домене.
У меня в постфиксе стоит проверка заголовков, в том числе имен и соответствия ип адресам, естественно получаемое письмо эту проверку не проходит.
Админы противоположной компании, говорят, что проблемы только со мной, что со всеми остальными у них все ходит, и работает и ДАЖЕ с ПИТЕРОМ ;), мои мольбы и просьбы изучить RFC821 ни к чему не привели. Исправлять у себя ни чего не хотят, почтой обмениваться надо, я же в свою очередь, проверку тоже отключать не хочу, т.к. она ооочень отшибает спам более 90%.
Соответсвенно вопрос, можно ли мой постфикс заставить как нибудь не проверять почтовый трафик с домена противоположной компании?
>[оверквотинг удален]
>
>Админы противоположной компании, говорят, что проблемы только со мной, что со всеми
>остальными у них все ходит, и работает и ДАЖЕ с
>ПИТЕРОМ ;), мои мольбы и просьбы изучить RFC821 ни к
>чему не привели. Исправлять у себя ни чего не хотят, почтой
>обмениваться надо, я же в свою очередь, проверку тоже отключать не
>хочу, т.к. она ооочень отшибает спам более 90%.
>
>Соответсвенно вопрос, можно ли мой постфикс заставить как нибудь не проверять почтовый
>трафик с домена противоположной компании?Если коротко, то смотреть в сторону check_sender_access
Из RFC821The argument field contains the host name of the sender-SMTP.
Так что еще вопрос кто прав.
У меня часто встречается такая ситуация, когда в HELO посылают все что угодно, даже localhost. Бороться с такими трудно. А в HELO наверника должна стоять запись компа (сервера) имеющего запись в прямой и обратной зоне на DNS сервере. :) (Плохо знаю английский, читал только перевод rfc)
>должна стоять запись компа (сервера) имеющего запись в прямой и обратной
>зоне на DNS сервере. :) (Плохо знаю английский, читал только перевод
>rfc)Абсолютно точно, и на нормальных серверах (с нормальными прокладками между стулом и клавой) оно приведено в соотвествие...
А то, что у части народа в заголовках содержиться хлам тык это и способствует спамерству в инете, и администраторы должны понимать это и приводить в норму, просто есть админы, которые спасибо скажут за найденную ошибку, а некоторые и пальцем не пошевелят...
Кстати процент серверов с кривыми HELLO на самом деле не очень то и велик, за мой последний год работы это второй случай (не ISP, но почты ходит много), при первом у меня стоял qmail тоже с проверкой, но там админы адекватные были, и все поправили.
>Из RFC821
>
>The argument field contains the host name of the sender-SMTP.
>Так что еще вопрос кто прав.Я не совсем точно исказил информацию ( :) ) :
Выглядит так:
есть провайдер: provider.ru
есть клиент: org.provider.ru
На нем (клиенте, стоит почтовый сервер) и он то как раз и является хостовой машиной для провайдера и доменом для себя (своей организации), а в hello приходит comp1.org.provider.ruИ вы считаете это верным?!
А что такое тогда вот это и для чего или кого?----------
The sender-SMTP MUST ensure that the <domain> parameter in a
HELO command is a valid principal host domain name for the
client host. As a result, the receiver-SMTP will not have to
perform MX resolution on this name in order to validate the
HELO parameter.The HELO receiver MAY verify that the HELO parameter really
RFC1123 MAIL -- SMTP & RFC-822 October 1989
corresponds to the IP address of the sender. However, the
receiver MUST NOT refuse to accept a message, even if the
sender's HELO command fails verification.
----------
>[оверквотинг удален]
>
> October 1989
>
> corresponds to the IP
>address of the sender. However, the
> receiver MUST NOT refuse
>to accept a message, even if the
> sender's HELO command fails
>verification.
>----------Так вот же английским по зеленому написано
However, the receiver MUST NOT refuse to accept a message, even if the
sender's HELO command fails verification.Однако, получатель НЕ ДОЛЖЕН отказывать принимать сообщение, даже если отправительская команда HELO не проходит проверку.
>[оверквотинг удален]
>>----------
>
>Так вот же английским по зеленому написано
>
>However, the receiver MUST NOT refuse to accept a message, even if
>the
>sender's HELO command fails verification.
>
>Однако, получатель НЕ ДОЛЖЕН отказывать принимать сообщение, даже если отправительская команда HELO
>не проходит проверку.Да дело то не только в HELO, он и на тест обратной зоны проверку не проходит, т.к. ну нет там соответсвия ip и имени которое пришло в заголовке!!!
Ну млин....
А такой helo [ip address] - тоже неправильный?
>А такой helo [ip address] - тоже неправильный?Цетирую из: http://www.yekt.info/postfix_antyspam.html
-----
файл /etc/postfix/helo_regexp:/([0-9]{1,3}(\.|-)){3}[0-9]{1,3}/i REJECT IP-able helo SPAM
запрещаем ИП-адрес в качестве HELO.
Это явное нарушение RFC, но практика показала, что это работает без сбоев.
>[оверквотинг удален]
>>The argument field contains the host name of the sender-SMTP.
>>Так что еще вопрос кто прав.
>
>Я не совсем точно исказил информацию ( :) ) :
>Выглядит так:
>есть провайдер: provider.ru
>есть клиент: org.provider.ru
>На нем (клиенте, стоит почтовый сервер) и он то как раз и
>является хостовой машиной для провайдера и доменом для себя (своей организации),
>а в hello приходит comp1.org.provider.ruВся проблема в том, что в зоне прямого просмотра нету A записи comp1.org.provider.ru, и нельзя определить IP адрес. Такого хоста просто не существует для внешнего мира. Нужно в зоне прямого просмотра просто добавить A запись comp1.org.provider.ru которая будет соответствовать IP почтовика.
В зоне обратного просмотра должна быть PTR запись для IP адреса почтовика, соответствующая comp1.org.provider.ru, то что вываливает HELO.
>[оверквотинг удален]
>>На нем (клиенте, стоит почтовый сервер) и он то как раз и
>>является хостовой машиной для провайдера и доменом для себя (своей организации),
>>а в hello приходит comp1.org.provider.ru
>
>Вся проблема в том, что в зоне прямого просмотра нету A записи
>comp1.org.provider.ru, и нельзя определить IP адрес. Такого хоста просто не существует
>для внешнего мира. Нужно в зоне прямого просмотра просто добавить A
>запись comp1.org.provider.ru которая будет соответствовать IP почтовика.
>В зоне обратного просмотра должна быть PTR запись для IP адреса почтовика,
>соответствующая comp1.org.provider.ru, то что вываливает HELO.Ну я предлогал им более демократичный способ, почтовому серверу присвоить имя org.provider.ru, т.к. хозяин (провайдер) зоны provider.ru не будет добавлять в файл зоны доменов 4 го уровня :) Иначе затолбают его с такими просбами, да и порядка не будет ;)
>[оверквотинг удален]
>>comp1.org.provider.ru, и нельзя определить IP адрес. Такого хоста просто не существует
>>для внешнего мира. Нужно в зоне прямого просмотра просто добавить A
>>запись comp1.org.provider.ru которая будет соответствовать IP почтовика.
>>В зоне обратного просмотра должна быть PTR запись для IP адреса почтовика,
>>соответствующая comp1.org.provider.ru, то что вываливает HELO.
>
>Ну я предлогал им более демократичный способ, почтовому серверу присвоить имя org.provider.ru,
>т.к. хозяин (провайдер) зоны provider.ru не будет добавлять в файл зоны
>доменов 4 го уровня :) Иначе затолбают его с такими просбами,
>да и порядка не будет ;)Нормальный провайдер зону может делегировать....
>[оверквотинг удален]
>>остальными у них все ходит, и работает и ДАЖЕ с
>>ПИТЕРОМ ;), мои мольбы и просьбы изучить RFC821 ни к
>>чему не привели. Исправлять у себя ни чего не хотят, почтой
>>обмениваться надо, я же в свою очередь, проверку тоже отключать не
>>хочу, т.к. она ооочень отшибает спам более 90%.
>>
>>Соответсвенно вопрос, можно ли мой постфикс заставить как нибудь не проверять почтовый
>>трафик с домена противоположной компании?
>
>Если коротко, то смотреть в сторону check_sender_accessВы про это:
smtpd_sender_restrictions = permit_mynetworks,
check_sender_access hash:$base/sender_access,
reject_authenticated_sender_login_mismatch,
reject_unknown_sender_domain,
reject_unlisted_sender,
reject_unverified_senderдобавил я в файл sender_access домен, пересобрал .db, перестартовал postfix, но почта с хоста так и не принемается все по той же причине :(
smtpd_client_restrictions>smtpd_sender_restrictions = permit_mynetworks,
> check_sender_access hash:$base/sender_access,
> reject_authenticated_sender_login_mismatch,
> reject_unknown_sender_domain,
> reject_unlisted_sender,
> reject_unverified_sender
>smtpd_client_restrictions
>
>>smtpd_sender_restrictions = permit_mynetworks,
>> check_sender_access hash:$base/sender_access,
>> reject_authenticated_sender_login_mismatch,
>> reject_unknown_sender_domain,
>> reject_unlisted_sender,
>> reject_unverified_senderИ его опробовал не помогает:
Может: smtpd_helo_restrictions поможет?
Где бы поподробней инфу почитать о smtpd_*_restrictions
http://www.postfix.org/spam.html
>http://www.postfix.org/spam.htmlВот нашел на русском, может кому еще пригодиться (очень хороший док):
http://www.freesource.info/wiki/Dokumentacija/Postfix/antisp...
>>http://www.postfix.org/spam.html
>
>Вот нашел на русском, может кому еще пригодиться (очень хороший док):
>http://www.freesource.info/wiki/Dokumentacija/Postfix/antisp...Вопрос снимаю с повестки дня
Проблема решена добавлением кривого адреса приходящего ко мне в helo в бд smtpd_helo_restrictionsУРА!!!
Особая благодарность за помощь Sam ;)
>Админы противоположной компании, говорят, что проблемы только со мной, что со всеми
>остальными у них все ходит, и работает и ДАЖЕ с
>ПИТЕРОМ ;), мои мольбы и просьбы изучить RFC821 ни к
>чему не привели. Исправлять у себя ни чего не хотят, почтой
>обмениваться надо, я же в свою очередь, проверку тоже отключать не
>хочу, т.к. она ооочень отшибает спам более 90%.А теперь представь себе хостинговый сервер hosting.ru
На котором куча доменов domain.ru, domain2.ru, domain3.ru, domain4.ru, domain5.ru
И куча IP 1.1.1.1, 1.1.1.2, 1.1.1.3, причем IP меньше чем доменов.Как по твоему это все должно работать? ;)
>[оверквотинг удален]
>>ПИТЕРОМ ;), мои мольбы и просьбы изучить RFC821 ни к
>>чему не привели. Исправлять у себя ни чего не хотят, почтой
>>обмениваться надо, я же в свою очередь, проверку тоже отключать не
>>хочу, т.к. она ооочень отшибает спам более 90%.
>
>А теперь представь себе хостинговый сервер hosting.ru
>На котором куча доменов domain.ru, domain2.ru, domain3.ru, domain4.ru, domain5.ru
>И куча IP 1.1.1.1, 1.1.1.2, 1.1.1.3, причем IP меньше чем доменов.
>
>Как по твоему это все должно работать? ;)Работает же, и народ нежалуется qmail+vpopmail ;)
>[оверквотинг удален]
>>>обмениваться надо, я же в свою очередь, проверку тоже отключать не
>>>хочу, т.к. она ооочень отшибает спам более 90%.
>>
>>А теперь представь себе хостинговый сервер hosting.ru
>>На котором куча доменов domain.ru, domain2.ru, domain3.ru, domain4.ru, domain5.ru
>>И куча IP 1.1.1.1, 1.1.1.2, 1.1.1.3, причем IP меньше чем доменов.
>>
>>Как по твоему это все должно работать? ;)
>
>Работает же, и народ нежалуется qmail+vpopmail ;)Что значит работает же? Что должен говорить сервер в HELO? с какого IP должен слать почту? Какой должен быть обратный резолвинг у этого IP?
>[оверквотинг удален]
>>>На котором куча доменов domain.ru, domain2.ru, domain3.ru, domain4.ru, domain5.ru
>>>И куча IP 1.1.1.1, 1.1.1.2, 1.1.1.3, причем IP меньше чем доменов.
>>>
>>>Как по твоему это все должно работать? ;)
>>
>>Работает же, и народ нежалуется qmail+vpopmail ;)
>
>Что значит работает же? Что должен говорить сервер в HELO? с какого
>IP должен слать почту? Какой должен быть обратный резолвинг у этого
>IP?ИП, резолвинг этогоИП,и имя указывется основного сервера (Например mail.provider.ru)
HELO тоже соответственно имя основного сервера
Имена доменов подменяются только в поле from.
А при проверке существования виртуальных ящиков сервером проверяется наличие домена в списках, наличие ящика и затем в случае успешных проверок отдается true...
Или я не прав?
>[оверквотинг удален]
>>Что значит работает же? Что должен говорить сервер в HELO? с какого
>>IP должен слать почту? Какой должен быть обратный резолвинг у этого
>>IP?
>
>ИП, резолвинг этогоИП,и имя указывется основного сервера (Например mail.provider.ru)
>HELO тоже соответственно имя основного сервера
>Имена доменов подменяются только в поле from.
>А при проверке существования виртуальных ящиков сервером проверяется наличие домена в списках,
>наличие ящика и затем в случае успешных проверок отдается true...
>Или я не прав?И в один прекрасный день IP попадает в пару популярных спам-листов, и даже не IP а вся подсеть. И со всех хостинговых серверов перестает доходить почта, каждые пять минут звонят клиенты и жалуются. Почту нужно слать с IP из другой подсети, который можно оперативно заменить и начать выносить предыдущий из спамлистов.
Еще одна причина -- отдельный канал и сетевой интерфейс специально для почты (т.е. не основной IP сервера), не занятый вообще больше ничем.
Это не RFC, это жизнь.Кроме того, есть куча "любителей RFC" плохо, к сожалению, знакомых с английским которые делают проверки типа:
1. соответствие HELO и From
2. Соответствие PTR IP с которого пришел коннект и A записи домена из FROM и/или HELO
3. Соответствие IP A записи домена в PTR записи IP с которого пришел коннект и IP с которого пришел коннект (башку можно сломать да?)
Ну и всякие другие "гениальные вещи".А вот Вам ещё примерчик:
[root@freebsd ~]# dig mx gmail.com
;; ANSWER SECTION:
gmail.com. 1273 IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. 1273 IN MX 10 alt2.gmail-smtp-in.l.google.com.
gmail.com. 1273 IN MX 50 gsmtp163.google.com.
gmail.com. 1273 IN MX 50 gsmtp183.google.com.
gmail.com. 1273 IN MX 5 gmail-smtp-in.l.google.com.
[root@freebsd ~]# dig gmail-smtp-in.l.google.com;; ANSWER SECTION:
gmail-smtp-in.l.google.com. 284 IN A 64.233.183.114
gmail-smtp-in.l.google.com. 284 IN A 64.233.183.27[root@freebsd ~]# dig -x 64.233.183.114
;; ANSWER SECTION:
114.183.233.64.in-addr.arpa. 86400 IN PTR gsmtp183-2.google.com.[root@freebsd ~]#
Гмыло не соответствует RFC ? :)
>И в один прекрасный день IP попадает в пару популярных спам-листов, и
>даже не IP а вся подсеть. И со всех хостинговых серверов
>перестает доходить почта, каждые пять минут звонят клиенты и жалуются. Почту
>нужно слать с IP из другой подсети, который можно оперативно заменить
>и начать выносить предыдущий из спамлистов.
>Еще одна причина -- отдельный канал и сетевой интерфейс специально для почты
>(т.е. не основной IP сервера), не занятый вообще больше ничем.
>Это не RFC, это жизнь.Вчера, когда искал доку по постфиксу, нашел одну статейку, адрес к сожалению не сохранил, так вот написано, что защищаться надо не только от внешних воздействий но и от своих клиентов :)
И проблемы тогда с попаданием в spam листы врядли будутТолько что, не поленился и завел ящик на gmail.com отправил тестовое письмо на свой почтовый сервер (с постфиксом, который оттопыривал сообщения, и стал причиной создания этого трейда) и как ты думаешь? Письмо дошло...
Хотя согласно твоим мыслям такое работать не должно :)
>Отдельный канал и сетевой интерфейс специально для почты (т.е. не основной IP сервера), >не занятый вообще больше ничем
В этом проблем вобще ни каких не вижу, в большинстве своем оно всегда так.
>Кроме того, есть куча "любителей RFC" плохо, к сожалению, знакомых с английским которые >делают проверки типа:
>1. соответствие HELO и From
>2. Соответствие PTR IP с которого пришел коннект и A записи домена из FROM и/или HELO
>3. Соответствие IP A записи домена в PTR записи IP с которого пришел коннект и IP с >которого пришел коннект (башку можно сломать да?)Это как рассматривать, я вот смотрю на это со стороны борьбы со спамом, и если бы все грамотно подходили к настройке почтового сервера, и ставили подобные фишки, то спамерам стало бы жить ооочень худо
Так что еще раз - все зависит от прокладки между клавой и креслом ;)
>[оверквотинг удален]
> 64.233.183.27
>
>[root@freebsd ~]# dig -x 64.233.183.114
>
>;; ANSWER SECTION:
>114.183.233.64.in-addr.arpa. 86400 IN PTR gsmtp183-2.google.com.
>
>[root@freebsd ~]#
>
>Гмыло не соответствует RFC ? :)Соответсвует.
gmail-smtp-in.l.google.com используется у них для приема почты.
Отправка идет с других хостов. С того же, например, gsmtp183.google.com, а с ним все ОК.
>Соответсвует.
>gmail-smtp-in.l.google.com используется у них для приема почты.
>Отправка идет с других хостов. С того же, например, gsmtp183.google.com, а с
>ним все ОК.Именно! Я про то и говорю :)
2 SiN
Возможно, я Вас неправильно понимаю.
"Да дело то не только в HELO, он и на тест обратной зоны проверку не проходит, т.к. ну нет там соответсвия ip и имени которое пришло в заголовке!!!"
Берем тот же гугл. Письмо приходит с хоста gsmtp183.google.com, который ну никак не похож на то что в заголовке (gmail.com)
Либо Вы не до конца понимаете как работает Ваша система, либо чего-то не догоняю я...
На самом деле решение всей этой загадки уже было в обсуждении, вот оно"Вся проблема в том, что в зоне прямого просмотра нету A записи comp1.org.provider.ru, и нельзя определить IP адрес. Такого хоста просто не существует для внешнего мира. Нужно в зоне прямого просмотра просто добавить A запись comp1.org.provider.ru которая будет соответствовать IP почтовика. В зоне обратного просмотра должна быть PTR запись для IP адреса почтовика, соответствующая comp1.org.provider.ru, то что вываливает HELO."
Однако и это ЖЕЛАТЕЛЬНО но не обязательно
Ибо как кто-то верно заметил:
The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.В общем читаем тут, тут даже табличка есть интересная на эту тему (кто что может и должен)
http://www.faqs.org/rfcs/rfc1123.htmlПочему так сделано? Да просто хотя бы потому что на Ваших ДНС серверах может быть устаревшая информация в кеше.
Я понимаю, что все это делается в целях борьбы со спамом, но "свинья грязь найдет" и спам будет, а вот нормальным людям, в особенности хостинг-провайдерам, это порой доставляет немало хлопот.
>Почему так сделано? Да просто хотя бы потому что на Ваших ДНС
>серверах может быть устаревшая информация в кеше.
>Я понимаю, что все это делается в целях борьбы со спамом, но
>"свинья грязь найдет" и спам будет, а вот нормальным людям, в
>особенности хостинг-провайдерам, это порой доставляет немало хлопот.В таком случае можно сделать open relay, сложить руки и через некоторое время выковыривать свой хост из блек листов, ругая на чем свет стоит RBL и тому подобное, говоря, что
"..."свинья грязь найдет" и спам будет, а вот нормальным людям, в особенности хостинг-провайдерам, это порой доставляет немало хлопот..."
RBL многим не нравится, проверка соответствия тоже не устраивает - spamassissin тогда вообще ф топку??? Купить трафа побольше (чтоб на спам хватало) и гуд???Ничего личного. Мое субъективное мнение.
А может быть стоит не зацикливаться на субъективном мнении а попытаться все же понять, почему в объективных RFC написано именно так, а не иначе?
>А может быть стоит не зацикливаться на субъективном мнении а попытаться все
>же понять, почему в объективных RFC написано именно так, а не
>иначе?RFC - рекомендации, но не правила.
А может привести все записи DNS в соответствие с реальностью?
>[оверквотинг удален]
>>>На котором куча доменов domain.ru, domain2.ru, domain3.ru, domain4.ru, domain5.ru
>>>И куча IP 1.1.1.1, 1.1.1.2, 1.1.1.3, причем IP меньше чем доменов.
>>>
>>>Как по твоему это все должно работать? ;)
>>
>>Работает же, и народ нежалуется qmail+vpopmail ;)
>
>Что значит работает же? Что должен говорить сервер в HELO? с какого
>IP должен слать почту? Какой должен быть обратный резолвинг у этого
>IP?А несколько имен на 1 ип нормальное явление при хостинге, просто несколько записей А или CNAME в днс, только вот какая из них правильнее не помню, надо смотреть, и на них уже MX, в случае если это одна зона, а с разными зонами, указваем один и тот же ИП в каждой зоне...