Vasiliy P. Melnik wrote: > а по существу - кроме aol.com <http://aol.com> ни одна из почтовых > систем, с которыми > доводилось сталкиваться, не ставит перед постмастерами столько проблем, > сколько ukr.net <http://ukr.net>. > > Та ну - а как жыж mail.ru <http://mail.ru>
кроме отсутствия возможности проверить существование получателя на этапе RCPT To они меня вроде ничем не доставали. > на части серверов, с которых мои клиенты производят рассылки своим > клиентам, приходится в системном фильтре замораживать все сообщения в > сторону ukr.net <http://ukr.net>, а потом скриптом отдельным, > запускаемым из планировщика > задач, размораживать письма по одному и отправлять их с интервалами. без > этого рано или поздно ukr.net <http://ukr.net> начинает возвращать > 4xx хотя бы на часть > писем. иногда начинает вообще отвергать доставку писем. > > плюс при возможности проводить ротацию исходящих IP аресов, не забывая > использовать HELO, соответствующее используемому IP адресу. > > > Я данный вопрос решил где-то за 10 минут с помощью гугля. > > smtp_banner = "$smtp_active_hostname ESMTP Server $tod_full" > smtp_active_hostname = ${lookup > dnsdb{defer_never,ptr=$received_ip_address}{$value}{$primary_hostname}} > > remote_smtp: > driver = smtp > helo_data = ${lookup dnsdb{ptr=$sending_ip_address}{$value} > {$primary_hostname}} smtp_banner и smtp_active_hostname менять вообще не нужно ротация исходящих адресов для исходящих писем касается исключительно remote_smtp трансорта только кроме helo_data нужно менять и interface > и не забывать, что Владимир пальцем тычет в STD3 (надеюсь, что таки в > http://www.rfc-editor.org/std/std3.txt, а не > http://www.ukr.net/mta/std3.html), поэтому в retry rules для ukr.net > <http://ukr.net> > прописать отдельное правило с периодом повторной доставки 30 минут. хотя > рекомендация 1989 года могла и устареть. хотя даже в далеком 1989 году > имелось ввиду "the retry interval SHOULD be at least 30 minutes", а не > "MUST be". при этом когда-то несколько лет назад на паре серверов > проблемы доставки в сторону ukr.net <http://ukr.net> были решены > только после увеличения > retry interval до 30 минут. > > но кроме retry rule все вышеуказанное актуально скорее при проблемах > доставки рассылок для пользователей ukr.net <http://ukr.net>. > > > А если бы все придерживались правил, то и спама бы не было. Да фиг с ним > с укрнетом - ну хотят они так, ну пусть будет так. Ну есть у них этот > чудо-грейлистинг - пусть развлекаются. > > З.Ы. Я свой вопрос решил. И свой второй вопрос о покупке нового сервера > тоже решил - спасибо укрнету :) если уж пошла такая пьянка, то и свою историю расскажу. есть у меня клиент. позвали они меня несколько лет назад посмотреть, что там за проблемы у них с почтой. а у ихнего Kerio MailServer и входящая и исходящая почта были завернуты через сервера Golden Telecom. и что-то там случилось, что у них исходящая почта могла на серверах Golden Telecom по неделе или две мариноваться. с входящей тоже проблем хватало. толкового постмастера для Kerio MailServer у них не было, чтобы полноценно обслуживать почту без заворота через провайдера. они согласились на компромиссный вариант - использование exim в качестве прокладки между Kerio MailServer (который они используют не только и не столько как почтовый сервер, сколько как средство групповой работы). плюс через этот exim стали проводиться рассылки их клиентам. и вот в прошлом году в головном офисе этой конторы (который в Праге) постановили почти все сервисы виртуализировать и перенести в датацентр в Праге. это означало, что у меня становилось на одного клиента меньше, т. к. все сервера по доровору должна были обслуживать чешская аутсорсинговая контора. но они не смогли добиться доставки писем из ERP этого клиента через их postfix на debian'е в сторону ukr.net. за неделю примерно они не смогли пробиться. а киевская контора со мной договор не расторгла еще. и они тихо стали по нему платить дальше. теперь те же деньги платят за обслуживание почтового сервера, через который больше не ходит корпоративная почта, а ходят лишь рассылки для клиентов. кстати, тоже с тем костылем с заморозкой писем в системном фильтре и разморозкой внешним скриптом. получается контроллируемая задержка в доставке части писем вместо возможной неконтроллируемой задержки доставки всех писем или вовсе отсутствия доставки. так что от ukr.net в этом плане пользы больше, чем от других почтовых сервисов ;-) -- 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
