Re: [uanog] smtp sender verify

2009/9/1 Pavel Gulchouck :

On Tue, Sep 01, 2009 at 01:59:59PM +0300, Vladimir Velychko writes: VV> 2009/9/1 Pavel Gulchouck :

...

...

On Tue, Sep 01, 2009 at 02:14:45AM +0300, Vladimir Velychko writes:

...

2009/8/31 Pavel Gulchouck :

...

Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts

...

Дык а что происходит, когда на мосту встречаются два барана (два МТА с sender callout) ? Калаутят друг друга до потери пульса. Тоже самое происходит, если с одной стороны sender callout, а с другой greylist.

Чтобы такого не случалось, callout делается от имени "<>" либо от адреса, для которого callout не делается (например, postmaster@...).

VV> Это хорошо. До всех пользователей "калаута" это сложно донести. :-( VV> Везде, где сталкивался с этой фичей были приведённые выше проблемы.

То есть, фича плоха, потому что везде, где ты её видел, её сетапили криворукие админы? Странная логика.

Павел, скажу сразу, что "я тоже за советскую власть". :)) И "за II интернационал", но реалии (на мой непросвещённый взгляд) жизни далеки от идеала. Фича плоха (неудобна, малопригодна) когда она не работает как надо по дефолту и потратив время на её включение ещё нужно тратить время на её тюнинг. Иначе получаем то, что имеем сейчас.

Криво настроить callout в exim - это ещё постараться надо. Как в других MTA - не знаю.

И exim4 тоже не у всех стоИт :-(

...

...

Складывается впечатление, что callout считается не модным и делающие callout заносятся в blacklist из-за того, что есть кривые реализации callout. Но это ведь бред?

VV> Спамеры любят слать на последние МХ-ы в списке, которые уже в свою очередь VV> валят всё на основной сервер. И колаутить свой МХ на предмет проверки сендера...

Да кто придумал, что проверять сендера нужно на отправляющем серваке, а не в соответствии с MX-ами? Откуда вообще такая странная идея взялась? Кто (какой MTA) так делает?

Меня долбил sendmail (вроде SCV настроен через milter), для которого я MX.

VV> ИМО проверка отправителя скорее зло, чем польза (интересно, есть VV> статистика, сколько писем среди режектнутых было легальных, а не VV> спамом? (-: )

Много ли шлётся нормальных писем с несуществующих или неработающих адресов? Думаю, что почти не шлются. Мне такие хочется получать крайне редко. То есть, ложных срабатываний у такой проверки гораздо меньше, чем от цифровых helo и других подобных. Если, конечно, делать sender verify нормально, а не у отправляющего сервера спрашивать или другие неожиданные способы применять.

VV> А вот проверка получателя оч. даже правильно (чего оч. нехватает на VV> неподконтрьных МХ-ах).

Зачем и в каких случаях нужны (полезны) неподконтрольные MX-ы?

В случаях, когда это единственный вариант кроме основного МХ-а. Делается затем, чтобы письмо в этот почт. домен у отправителя уходило, а не тут же возвращалось с ошибкой и поднималась паника в момент, когда узел по каким то причинам недоступен.

Чем они могут быть вредны - очевидно: нет доступа к логам, сильно снижена секьюрность, может быть изменение настроек без предупреждения, например, ограничение на размер письма и т.д. То есть, вот как раз от неподконтрольных MX-ов IMHO вреда больше, чем пользы.

+100

Проверка получателя по SMTP - тоже довольно неоднозначная фича. Ведь тогда фактически получается, что лежание младшего MX приводит к тому, что все остальные тоже отказываются принимать почту. Зачем тогда они нужны? И тогда получается, что при получении почты через старший MX младшему нужно не просто принять эту почту, а сначала провести пустую smtp-сессию для проверки получателя, а потом настоящую (со старшим MX) для приёма почты, т.е. установка backup MX с receipient verify увеличит нагрузку на primary MX. Чтобы этого не было, каждый MX должен сам знать валидные почтовые адреса в домене получателя, без всяких verify receipient через smtp - тогда нагрузка будет снижена.

Кластер из Lotus Domino? :) Не успели взять по понятным причинам. :-( -- VEL-[RIPE|UANIC]