Vasiliy P. Melnik wrote: > > smtp_banner и smtp_active_hostname менять вообще не нужно > > А что плохого, чтобы хело-ехло совпадало с запись в днс-е ?
аргумент команд HELO/EHLO должен содержать FQDN хоста отправителя. который может быть чуть меньше чем полностью никак не связан с smtp_active_hostname. и тем более smtp_banner. чисто теоретический пример - у хоста один внешний интерфейс чисто для приема почты (свой IP адресом своей PTR записью в реверсной зоне) и пара интерфейсов для отсылки исходящих писем (со своими IP адресами и своими PTR записями в реверсной зоне). так вот, для каждого IP адреса интерфейсов, используемых для отсылки почты, PTR запись должна резолвиться в соответствующий IP адрес. очень желательно, чтобы аргумент команды HELO/EHLO резолвился в IP адрес исходящего интерфейса (хотя формально по RFC даже не обязательно, чтобы он резолвился). желательно, но не обязательно, чтобы аргумент команды HELO/EHLO совпадал с PTR записью адреса интерфейса, через который уходит письмо. требований о совпадении вообще нет, на сколько я знаю. но такое совпадение гарантирует прохождение даже самых экстремистских фильтров по HELO. при этом smtp_active_hostname вообще не важен при отсылке почты. при этом вообще неважно, какая будет PTR запись у адреса интерфейса, используемого только для приема почты. единственная причина, по которой мне приходилось делать вычисляемое значение smtp_active_hostname, это когда один сервер должен был выглядеть как два разных в зависимости от того, на какой интерфейс пришел коннект. в этом случае менялись smtp_active_hostname, smtp_banner, received_header_text, tls_certificate, tls_privatekey, message_id_header_domain. это всё критично для входящей почты. а для исходящей нужно было только менять interface и helo_data в remote_smtp в зависимости от домена отправителя или от адреса внутреннего интерфейса, на который пришел коннект от SMTP клиента. нерешенной осталась только проблема указания interface и helo_data при отсылке bounce message, если не удалось доставить локально (или смаршрутизировать письмо получателю в случае рилеемого домена). признаки того, кому не удалось доставить письмо, находятся только в самом теле bounce message. > ротация исходящих адресов для исходящих писем касается исключительно > remote_smtp трансорта > > только кроме helo_data нужно менять и interface > > А разве экзим не будет использовать интерфейс в зависимости от гейта ? если у сервера несколько разных каналов (каждый со своим гейтом, конечно же), то система (не exim) в качестве исходящего адреса выберет ближайший к гейту. а если несколько адресов прибиты алиасами к одному интерфейсу, то сам exim может вполне указать системе, какой src адрес будет у пакетов. есть у меня клиент. у них небольшая рассылка примерно на 18-20 тысяч адресов держателей дисконтных карт их магазинов. из них 5-6 тысяч пользователей ukr.net (точно не меньше, а может и больше). клиент изначально получил штук пять дополнительных IP адресов у провайдера исключительно для рассылок. внешний канал у них один, эти пять адресов прибиты алиасами к внешнему интерфейсу. а в remote_smtp транспорте interface и helo_data используются дефолтные для писем от живых людей, либо используется один из этих пяти адресов, если во внешний мир отсылается письмо от mailman. плюс заморозка в очереди писем в сторону ukr.net и костыль для их дозированной разморозки и доставки. а вот как раз helo_data можно и не менять в remote_smtp транспорте. но только в одном случае - PTR запись у всех возможных адресов, используемых в качестве значений для interface в remote_smtp трансорте, должна быть одинаковая. и ей должны соответствовать несколько A записей - по одной на каждое значение для interface. в чистом виде вряд ли кто-то это будет использовать. чисто технически никаких нарушений в этой схеме нет, но чудо враждебной техники MDaemon при проверке соответствия записей в прямой и реверсной зонах проверяет не всех A записи для PTR записи хоста, а только первую. но аргумент HELO с несколькими A записями может понадобится, когда почтовый сервер работает из-за NAT'а, на router'е есть интерфейсы в сторону нескольких провайдеров, а exim заранее не знает, через какой из интерфейсов уйдет письмо. соответственно не знает, какой будет адрес этого интерфейса. поэтому будет лучше, если HELO будет резолвится в адреса всех интерфейсов, а PTR записи адресов всех интерфейсов будут совпадать с этим HELO. отосланное таким образом письмо может не пройти только проверку вышеупомянутого MDaemon или сопоставимой по кривизне поделки. хотя всё это уже далековато от темы задержке доставки почты в сторону ukr.net. p. s. зато письма из рассылки (по крайней мере два последних) стали приходить быстрее (три минуты и минута по сравнению с 12-24 минутами). -- Best wishes Victor Ustugov mailto:[email protected] public GnuPG/PGP key: http://victor.corvax.kiev.ua/corvax.asc ICQ UIN: 371808614 JID: [email protected] nic-handle: CRV-UANIC _______________________________________________ Exim-users mailing list [email protected] http://mailground.net/mailman/listinfo/exim-users
