[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: postfix + gmail



Добавил себе в mail.cf
header_checks = regexp:/etc/postfix/header_checks
Создал файл header_checks с соответствующим содержанием следуя нижеизложенному 
примеру, однако эта конфигурация полностью игнорируется postfix-ом, так как 
почта отсылается или непосредственно или через relayhost (если он указан).

------- Original message -------
From: Artem Chuprina <ran@ran.pp.ru>
To: debian-russian@lists.debian.org
Subject: Re: postfix + gmail
Date: Sunday 25 September 2005 10:34
> Serja -> debian-russian@lists.debian.org  @ Sun, 25 Sep 2005 07:50:52 +0200:
>  >> Ну... зачем так жестоко, у меня вполне работают настройки в
>  >> header_checks: /^From:.*@mail.ru/      FILTER smtp:smtp.mail.ru
>
>  S> Здесь, если я правильно понимаю, можно всесто *@mail.ru просто
>  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: ran@jabber.ran.pp.ru
>
> Вот .NET и Mono - это современные технологии.  В смысле - сырые и глюкавые.
> 	Victor Wagner в <cisnd1$qtc$4@wagner.wagner.home>

-- 
Who the hell are you, and why are you playing with my kernel?

Reply to: