Не , ну можно конечно и так , только у меня дневной трафф на каждуй сервер порядка 4-5 Гигоф, я боюсь что устану парсить, а с callout у меня сервак сдохнет от такого количества коннектов
On Thu, Oct 27, 2005 at 08:25:19PM +0400, Artem Chuprina wrote: > Andrey Melnikoff -> [email protected] @ Thu, 27 Oct 2005 > 19:52:57 +0400: > > >> >> ДА неплохой вариант , но для меня не приемлем , т.к. сервера на > >> >> которые пересылаются письма , не мои и никакого управления ими у > >> >> меня нет. > >> AM> callout не требует никакого управления. Только банальная SMTP > сессия. Ы? > > >> В момент приема письма. Это очень жесткое требование. В таком > >> раскладе вообще непонятно, нафига тут этот релей, следует прописать > >> MX непосредственно туда и расслабиться. > AM> нЭт. В момент приема первого письма на адрес получателя и до > AM> момента вызова tidyup на callout.db. Если с той стороны нормальный > AM> сервер - прийдет письмо чуть позже. Но если это тебя так пугает - > AM> написать скриптик на перловке, которы после logrotate заглянет в > AM> /var/log/exim/mainlog, выберет всех нормальных получателей, и > AM> засунет из в /etc/exim4/recipient-whitelist - делов на 20 минут. > > AM> Чем не устроит скажем вот такое: > > AM> deny condition = ${if [EMAIL PROTECTED] \ > AM> lsearch {/etc/exim4/recipient-whitelist} \ > AM> {no}{yes}}} > AM> domains = + relay_to_dmmains > AM> !verify = recipient/callout/2m,no_details > > AM> Другим перловым скриптиком раз с весяц проверять живость тех, кто > AM> попал в /etc/exim4/recipient-whitelist. > > Я боюсь такого количества костылей... > > -- > Artem Chuprina > RFC2822: <ran{}ran.pp.ru> Jabber: [EMAIL PROTECTED] > > Fill the difference... > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
