не доставляется письмо на один адрес. каков алгоритм локализации?
smtp-сервер, через который ты отправляешь — для него есть A и PTR записи в DNS. Некоторые серверы настроены так, что если для IP с которого к ним подключаются нет PTR, то они пошлют нафиг. А некоторые даже проверяют IP -> PTR -> name -> A -> IP.
450 <company1.local>: Helo command rejected: Host not foundваш сервер представляется именем company1.local, которое неизвестно серверу адресата
да, забыл указать, что прямая и обратная зоны настроены, т.е. скорее всего дело не в этом.
да, как раз меня это тоже смущает. а где это должно правиться? схема немного путаная:
=>postfix=>security server (тот самый company1.local)=>exchange 2010 => outlook client => exchange 2010 => security server => THE INTERNET
на сервере безопасности стоит MIMESweeper for SMTP, где сейчас, как я вижу, висят все сообщения, отправленные на @zaporizhstal.com
=>postfix=>security server (тот самый company1.local)=>exchange 2010 => outlook client => exchange 2010 => security server => THE INTERNET
на сервере безопасности стоит MIMESweeper for SMTP, где сейчас, как я вижу, висят все сообщения, отправленные на @zaporizhstal.com
отправил себе сообщение на жмаил:
получается, что для внешних получателей наш сервер тоже представляется локальным именем? если письмо не уходит по причине несовпадения FQDN и МХ, то можно ли это поправить, а в идеале, вообще убрать имя почтового сервера?
Delivered-To: gmail.com
Received: by 10.231.240.6 with SMTP id ky6csp203409ibb;
Wed, 30 Jan 2013 09:35:06 -0800 (PST)
X-Received: by 10.112.38.228 with SMTP id j4mr2281832lbk.1.1359567305405;
Wed, 30 Jan 2013 09:35:05 -0800 (PST)
Return-Path: <company2.ru>
Received: from [b]security.company1.local (company1.ru. [195.239.132.xx])[/b]
by mx.google.com with ESMTP id ew1si1094465lbb.23.2013.01.30.09.35.04;
Wed, 30 Jan 2013 09:35:05 -0800 (PST)
Received-SPF: pass (google.com: domain of company2.ru designates 195.239.132.xx as permitted sender) client-ip=195.239.132.xx;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of company2.ru designates 195.239.132.xx as permitted sender) smtp.mail=company2.ru
Received: from exchange_server.company1.local (exchange_server.company1.local) by security.company1.local
(Clearswift SMTPRS 5.5.0) with ESMTP id <Ta999cb330c0asecurity.company1.local> for <gmail.com>;
Wed, 30 Jan 2013 21:35:03 +0400
Received: from exchange_server.company1.local ([10.10.254.197]) by
exchange_server.company1.local ([10.10.254.197]) with mapi id 14.02.0247.003;
Wed, 30 Jan 2013 21:35:03 +0400
From: company2.ru
To: "gmail.com" <mymailgmail.com>
получается, что для внешних получателей наш сервер тоже представляется локальным именем? если письмо не уходит по причине несовпадения FQDN и МХ, то можно ли это поправить, а в идеале, вообще убрать имя почтового сервера?
схема немного путаная:Немного путаная? Это жесть вообще говоря.
=>postfix=>security server (тот самый company1.local)=>exchange 2010 => outlook client => exchange 2010 => security server => THE INTERNET
Что это за порнота?
exchange 2010 => outlook client => exchange 2010
Ну видимо как говорит, они проверяют то, что в helo им передают, извращенцы.
Нада на последнем "вашем" сервере поменять в настройках как он представляется. Или убедить тех, что они не правы, хотя это редко удаётся.
Нада на последнем "вашем" сервере поменять в настройках как он представляется. Или убедить тех, что они не правы, хотя это редко удаётся.
они проверяют то, что в helo им передают, извращенцы.почему извращенцы?
всякие там червяки пишут фигню в helo (например, берут виндовое имя без доменной части), а у настоящего сервера должно быть нормальное имя там
почему извращенцы?Ну как-то жестоко это. Вот видишь же, почту им отправить не получается.
Это нормальная практика - в helo должно быть то, что резолвится IP, являющимся MX в зоне, в которой хост.
Это нормальная практика - в helo должно быть то, что резолвится IP, являющимся MX в зоне, в которой хост.Да нет, не нормально. Т.к. сервер, принимающий почту для домена может сильно отличаться от пересылающего.
Т.к. сервер, принимающий почту для домена может сильно отличаться от пересылающего.А вот это как раз извращение.
ну это как если ты придёшь в почтовое отделение, будучи котом
а тебе там говорят, что от котов письма не принимают
а тебе там говорят, что от котов письма не принимают
ну это как если ты придёшь в почтовое отделение, будучи котомДля этого SPF и прочее придумали вроде. А так они всё равно не проверят, что ты человек. Зато мозги поебут, спрашивая: "А почему у вас на футболке написано, что вы кот?"
а тебе там говорят, что от котов письма не принимают
Зато мозги поебут, спрашивая: "А почему у вас на футболке написано, что вы кот?"Если ты на самом деле кот, то никакого эффекта не будет.
А если человек, то оденешься по форме и придешь ещё раз.
Если ты на самом деле кот, то никакого эффекта не будет.Так ведь смотрят только на футболку, а проверить, что на самом деле всё равно не могут.
А если человек, то оденешься по форме и придешь ещё раз.
Фиг с ними с аналогиями, эта проверка нужна, если может защитить, например, от спама при отстутствии заметного количества ложных срабатываний, а то и вообще нежелательно. А у них может серверу нельзя задать как ему представляться в локальной и глобальной сети по-разному или он не знает своего внешнего адреса. А от спама от всего это не защищает. Ну т.е. какую-то частичку можем порезать, но как-то цена велика по мне. Так ведь ещё те, кто так защищаются и на других свои проблемы спихивают. Они сами пошли на такой компромисс, что они не всю почту смогут принимать, но виноваты в этом оказываются те, кто отправить не им может.
я думаю, очень мало ложных срабатываний
гораздо больше от отсутствия PTR, что лечится просто - надо завести PTR
проблемы челов, которые хотят на диалапе без постоянного IP держать почтовый сервер - никого не интересуют
точно так же, как и проблемы тех, кто не знает своего доменного имени
в то время как вирус реально может не знать имени, тут-то его и ловят
гораздо больше от отсутствия PTR, что лечится просто - надо завести PTR
проблемы челов, которые хотят на диалапе без постоянного IP держать почтовый сервер - никого не интересуют
точно так же, как и проблемы тех, кто не знает своего доменного имени
в то время как вирус реально может не знать имени, тут-то его и ловят
точно так же, как и проблемы тех, кто не знает своего доменного имениДа ладно, я думаю, что полно всяких энтерпрайзных решений. Где этот сервер может в каком-нибудь DMZ находиться с локальными адресами, наружу натиться и т.п. И реально не знать свой внешний адрес.
в то время как вирус реально может не знать имени, тут-то его и ловятВ то время как вирус у диалапщика будет скорее всего с прямым адресом и узнать PTR ему не составит труда.
Да ладно, я думаю, что полно всяких энтерпрайзных решений. Где этот сервер может в каком-нибудь DMZ находиться с локальными адресами, наружу натиться и т.п. И реально не знать свой внешний адрес.Там будет десяток админов за >150к, и все в белых рубашках.
Кто-нибудь из них точно должен знать, как поставить имя серверу.
Там будет десяток админов за >150к, и все в белых рубашках.Ну да, обязательно. В общем продолжайте отстреливать себе и другим ноги просто так.
Кто-нибудь из них точно должен знать, как поставить имя серверу.
спасибо!
изменил EHLO/HELO на нормальное имя, и все заработало.
изменил EHLO/HELO на нормальное имя, и все заработало.
Оставить комментарий
sasha397
при этом к company2 почта от них попадает без проблем.
nslookup c company1.local
с компа company1.local telnet на relay.zaporizhstal.com 25
проверял в черных списках - нашего адреса нет.
что я упустил?