Добавил себе в mail.cf header_checks = regexp:/etc/postfix/header_checks Создал файл header_checks с соответствующим содержанием следуя нижеизложенному примеру, однако эта конфигурация полностью игнорируется postfix-ом, так как почта отсылается или непосредственно или через relayhost (если он указан).
------- Original message ------- From: Artem Chuprina <[EMAIL PROTECTED]> To: [email protected] Subject: Re: postfix + gmail Date: Sunday 25 September 2005 10:34 > Serja -> [email protected] @ Sun, 25 Sep 2005 07:50:52 +0200: > >> Ну... зачем так жестоко, у меня вполне работают настройки в > >> header_checks: /^From:[EMAIL PROTECTED]/ FILTER smtp:smtp.mail.ru > > S> Здесь, если я правильно понимаю, можно всесто [EMAIL PROTECTED] просто > S> попробовать указать полный адрес своего отправителя и конечно же > S> заставлять fetchmail отдавать всё procmail-у, "а то мало ли что ;)". > > Ну, если у тебя входящая почта бывает только от fetchmail, то да. С > некоторыми оговорками типа "почту от одного юзера локальной сети другому > мы тоже будем слать через gmail.com, если автор подписался гмейловским > адресом", но жить будет. (Помнится, ходили одно время IP-пакеты с 10 > этажа ГЗ МГУ на 12-й, метров 20 по прямой, через Америку и Голландию...) > Если у тебя к smtpd может придти почта снаружи, будут уже проблемы. > > S> Однако тут возникла следующая проблема. > S> Прочитав howto > (http://souptonuts.sourceforge.net/postfix_tutorial.html) и S> получив > следующий лог, я так понял, что в установленной версией sasl, postfix S> > работать в нужном мне режиме не будет. > > S> Sep 24 18:04:26 localhost postfix/smtp[8207]: 01B9F107856: > S> Authentication failed: cannot SASL authenticate to server > S> smtp.gmail.com[64.233.185.111]: no mechanism available. > > S> В упомянутом howto пишется, что эта проблема решается исключительно > S> посредством установки более новой версии sasl. Или не обязательно > S> обновлять? > > Ответ на этот вопрос зависит от того, какие механизмы предлагает тот > конец. no mechanism available бывает и тогда, когда общий механизм > есть, но либо не разрешен к использованию конфигурацией, либо к нему не > удалось найти пароль для данного сайта. Помнишь, я писал про chroot в > прошлом письме? Я по этим граблям, помнится, несколько часов > ходил... Я тогда, правда, вход настраивал, мне хотелось пароль > системного пользователя проверить. Это был еще woody, с pwcheck, > который тоже пришлось уговаривать свой сокет заводить в пределах > /var/spool/postix. > > S> По поводу вышеизложенного возник ещё один вопрос: как настроить > S> postfix, чтобы он при подобных ошибках возникших при отправке, не > S> только в логи это заносил, а еще и сообщение отсылал по локалке? > > По локалке - совершенно незачем. Достаточно постмастеру. Для этого > надо, во-первых, обеспечить, чтобы его почта посылалась реальному юзеру > (и не руту, если у тебя рут - реальный юзер; постфикс не любит слать > почту руту), а во-вторых, man postconf на предмет слова bounce. > > Хотя тут возможно несколько способов получить misconfiguration с разными > результатами. Вариант "развернули сразу на SMTP диалоге", похоже, > отпадает, поскольку фильтр after-queue (или я невнимательно читал вчера > доку). Возможно, вышеупомянутая ошибка - временная. Поищи письмо в > очереди. В принципе, постфикс умеет слать предупреждения о том, что > доставка задерживается (и кажется, с диагностикой, почему, то бишь с > последним диалогом с тем концом). Это предупреждение включается > посредством delay_warning_time. Если же ошибка сочтена постоянной, > постфикс должен пытаться отправить сообщение о недоставке отправителю. > Зайдешь в следующий раз за своей почтой на gmail - поищи его там. Теперь > у письма From совершенно нормальный, и потому оно должно спокойно уйти > туда, если почту с твоего домена примет твой основной релей (тут тоже > может быть засада - если у тебя домен в письмах от мейлер-демона за > пределами твоей локалки не существует, то любой почтовый сервер по > дороге может письмо не принять, и будет совершенно прав; если при этом > это не первый твой релей, то ты об этом даже и не узнаешь). Если > же он у тебя не знает, как туда почту отправить, либо письмо отверг > основной релей, получится double bounce. Куда отправлять оные double > bounces, написано в переменной 2bounce_notice_recipient (оно по > умолчанию правильное), а отправлять ли их туда - в notify_classes (и ее > вполне разумное значение по умолчанию не включает double bounce, но на > время отладки навороченных систем вполне разумно его, а то и просто > bounce, туда включить). Возможно, я еще не все варианты сходу сообразил. > > В качестве естественного заключения этого развесистого абзаца повторю > свой вопрос: а смысл? Если в качестве учебной задачи (попробовать > добиться такого эффекта, понять в процессе, как работает почтовка в том > или ином сложном случае, а потом откатить конфигурацию на нормальную) - > то понятно. Задача действительно позволяет заглянуть в ряд полезных в > сложной конфигурации мест. > > S> И что если exim4 попробовать вместо postfix поставить? > > Скорее всего, будут те же проблемы, только искать ответы на твои вопросы > будут другие люди. > > -- > Artem Chuprina > RFC2822: <ran{}ran.pp.ru> Jabber: [EMAIL PROTECTED] > > Вот .NET и Mono - это современные технологии. В смысле - сырые и глюкавые. > Victor Wagner в <[EMAIL PROTECTED]> -- Who the hell are you, and why are you playing with my kernel?
