smtp sender verify

older
Cisco Expo 2009, Київ, 22-23 жовтня

Pavel Gulchouck

31 Aug 2009 31 Aug '09

5:44 p.m.

Hi! Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp? -- Паша.

Show replies by date

Vasiliy P. Melnik

31 Aug 31 Aug

6:14 p.m.

а еще нельзя рассылать спам - это вообще противозаконно в некоторых странах. On Mon, Aug 31, 2009 at 08:44:01PM +0300, Pavel Gulchouck wrote:

...

Hi!

Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

-- Паша.

-- ------------------------------------------------------------------------------- Vasiliy P. Melnik VPM-RIPE, VPM-UANIC

Valentin Nechayev

6:22 p.m.

Mon, Aug 31, 2009 at 20:44:01, gul wrote about "[uanog] smtp sender verify":

...

Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

Картина с почтой сейчас такая: или ты плюёшь на всех звонарей и делаешь так, как работает, или плюёшь на всё и переходишь на gmail. Что бы ты ни делал, тебя обязательно куда-нибудь залистят и обольют грязью, ибо иначе не могут. Главное в этом процессе - не париться. Жалобы тоже не модны, модна фильтрация у себя, spamassassin или ещё чего круче (а когда надоест его строить - тот же gmail выручит). -netch-

Alex Belinsky

6:26 p.m.

Дядя Нетч, а как же спамотсо^H^H^Hборона имени яндекса? У нас кастомеры пользуют. 2009/8/31 Valentin Nechayev :

...

Mon, Aug 31, 2009 at 20:44:01, gul wrote about "[uanog] smtp sender verify":

...
Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

Картина с почтой сейчас такая: или ты плюёшь на всех звонарей и делаешь так, как работает, или плюёшь на всё и переходишь на gmail. Что бы ты ни делал, тебя обязательно куда-нибудь залистят и обольют грязью, ибо иначе не могут. Главное в этом процессе - не париться. Жалобы тоже не модны, модна фильтрация у себя, spamassassin или ещё чего круче (а когда надоест его строить - тот же gmail выручит).

-netch-

-- wbr, Alex

Valentin Nechayev

6:33 p.m.

Mon, Aug 31, 2009 at 21:26:12, alex.belinsky wrote about "Re: [uanog] smtp sender verify":

...

Дядя Нетч, а как же спамотсо^H^H^Hборона имени яндекса? У нас кастомеры пользуют.

Если не парятся - пусть живёт. -netch-

Pavel Gulchouck

6:40 p.m.

On Mon, Aug 31, 2009 at 09:14:30PM +0300, Vasiliy P. Melnik writes:

...

а еще нельзя рассылать спам - это вообще противозаконно в некоторых странах.

Как интересно (я имею ввиду постановку в один ряд этих действий). А слать icmp echoreply и/или icmp unreachable ещё можно? Отвечать на валидные udp-запросы? Ведь это всё (и многое другое) можно использовать для организации DDoS. Действительно ли ни один из противников smtp callout не шлёт ни echoreply, ни unreachable ни с одной из своих железок? Или я что-то упускаю в логике?

...

On Mon, Aug 31, 2009 at 08:44:01PM +0300, Pavel Gulchouck wrote:

...
Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

-- Паша.

Pavel Gulchouck

6:43 p.m.

On Mon, Aug 31, 2009 at 09:40:37PM +0300, Pavel Gulchouck writes:

...

...
а еще нельзя рассылать спам - это вообще противозаконно в некоторых странах.

PG> Как интересно (я имею ввиду постановку в один ряд этих действий). PG> А слать icmp echoreply и/или icmp unreachable ещё можно? Отвечать на PG> валидные udp-запросы? Ведь это всё (и многое другое) можно использовать PG> для организации DDoS. Действительно ли ни один из противников smtp PG> callout не шлёт ни echoreply, ни unreachable ни с одной из своих PG> железок? PG> Или я что-то упускаю в логике? Ещё подумал: чем smtp callout принципиально отличается от tcp synack, посылаемого жертве в ответ на попытку установки соединения на 25/tcp?

...

...
On Mon, Aug 31, 2009 at 08:44:01PM +0300, Pavel Gulchouck wrote:

...
Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

-- Паша.

Oleg V. Nauman

7:13 p.m.

On Monday 31 August 2009 21:43:20 Pavel Gulchouck wrote:

...

On Mon, Aug 31, 2009 at 09:40:37PM +0300, Pavel Gulchouck writes:

...
...
а еще нельзя рассылать спам - это вообще противозаконно в некоторых странах.

PG> Как интересно (я имею ввиду постановку в один ряд этих действий). PG> А слать icmp echoreply и/или icmp unreachable ещё можно? Отвечать на PG> валидные udp-запросы? Ведь это всё (и многое другое) можно использовать PG> для организации DDoS. Действительно ли ни один из противников smtp PG> callout не шлёт ни echoreply, ни unreachable ни с одной из своих PG> железок? PG> Или я что-то упускаю в логике?

Ещё подумал: чем smtp callout принципиально отличается от tcp synack, посылаемого жертве в ответ на попытку установки соединения на 25/tcp?

Тем более что sender callout действительно ничем не отличается от dictionary attack. Ну и предположение во многих реализациях callout что inbound и outbound server это один и тот же сервер тоже не выдерживает критики.

...

...
...
On Mon, Aug 31, 2009 at 08:44:01PM +0300, Pavel Gulchouck wrote:

...
Ходят слухи, что использовать smtp sender callout нынче уже не

модно:

...

...
...
...
http://www.backscatterer.org/?target=sendercallouts

С другой стороны в Backscatter не попасть - себя не уважать. Забейте ибо сервис для умалишенных

...

...
...
...
Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

Кстати святая правда - мои DNS сервера часто попадают в чужие bogon lists именно по этой причине. Так и живем. -- Науман Олег

Alex Belinsky

7:22 p.m.

Паша, in и out не всегда одно и то же. 2009/8/31 Pavel Gulchouck :

...

On Mon, Aug 31, 2009 at 09:40:37PM +0300, Pavel Gulchouck writes:

...
...
а еще нельзя рассылать спам - это вообще противозаконно в некоторых странах.

PG> Как интересно (я имею ввиду постановку в один ряд этих действий). PG> А слать icmp echoreply и/или icmp unreachable ещё можно? Отвечать на PG> валидные udp-запросы? Ведь это всё (и многое другое) можно использовать PG> для организации DDoS. Действительно ли ни один из противников smtp PG> callout не шлёт ни echoreply, ни unreachable ни с одной из своих PG> железок? PG> Или я что-то упускаю в логике?

Ещё подумал: чем smtp callout принципиально отличается от tcp synack, посылаемого жертве в ответ на попытку установки соединения на 25/tcp?

...
...
On Mon, Aug 31, 2009 at 08:44:01PM +0300, Pavel Gulchouck wrote:

...
Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

-- Паша.

-- wbr, Alex

Pavel Gulchouck

7:30 p.m.

On Mon, Aug 31, 2009 at 10:22:54PM +0300, Alex Belinsky writes: AB> Паша, in и out не всегда одно и то же. Я бы сказал, что оно вообще редко одно и то же. :) Но к чему это в данном случае? Я привожу примеры возможных DDoS-атак с использованием udp, icmp или tcp synack аналогично атаке через smtp callout. То есть, я посылаю tcp syn req от твоего имени на миллион smtp-серверов, и ты получаешь миллион synack от разных источников. Разве не то же самое, что с callout? Аналогично я могу послать миллион udp-запросов от твоего имени или миллион пингов. Почему именно smtp callout считают некошерными, а ответ на пинги - нормальным? AB> 2009/8/31 Pavel Gulchouck :

...

...
On Mon, Aug 31, 2009 at 09:40:37PM +0300, Pavel Gulchouck writes:

...
...
а еще нельзя рассылать спам - это вообще противозаконно в некоторых странах.

PG>> Как интересно (я имею ввиду постановку в один ряд этих действий). PG>> А слать icmp echoreply и/или icmp unreachable ещё можно? Отвечать на PG>> валидные udp-запросы? Ведь это всё (и многое другое) можно использовать PG>> для организации DDoS. Действительно ли ни один из противников smtp PG>> callout не шлёт ни echoreply, ни unreachable ни с одной из своих PG>> железок? PG>> Или я что-то упускаю в логике?

...
Ещё подумал: чем smtp callout принципиально отличается от tcp synack, посылаемого жертве в ответ на попытку установки соединения на 25/tcp?

...
...
On Mon, Aug 31, 2009 at 08:44:01PM +0300, Pavel Gulchouck wrote:

...
Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

-- Паша.

Oleg V. Nauman

8:05 p.m.

On Monday 31 August 2009 22:30:28 Pavel Gulchouck wrote:

...

On Mon, Aug 31, 2009 at 10:22:54PM +0300, Alex Belinsky writes: AB> Паша, in и out не всегда одно и то же.

Я бы сказал, что оно вообще редко одно и то же. :) Но к чему это в данном случае?

Шлет один сервер, проверяют либо тот же ( что чаще всего бесмысслено ) либо сервер который это письмо не слал.

...

Я привожу примеры возможных DDoS-атак с использованием udp, icmp или tcp synack аналогично атаке через smtp callout. То есть, я посылаю tcp syn req от твоего имени на миллион smtp-серверов, и ты получаешь миллион synack от разных источников. Разве не то же самое, что с

callout?

...

Аналогично я могу послать миллион udp-запросов от твоего имени или миллион пингов. Почему именно smtp callout считают некошерными, а ответ на пинги - нормальным?

Sender callout есть ответ на запрос которого проверяемый сервер не делал

...

AB> 2009/8/31 Pavel Gulchouck :

...
...
On Mon, Aug 31, 2009 at 09:40:37PM +0300, Pavel Gulchouck writes:

...
...
а еще нельзя рассылать спам - это вообще противозаконно в

некоторых

...

...
...
...
...
странах.

PG>> Как интересно (я имею ввиду постановку в один ряд этих действий). PG>> А слать icmp echoreply и/или icmp unreachable ещё можно? Отвечать на PG>> валидные udp-запросы? Ведь это всё (и многое другое) можно использовать PG>> для организации DDoS. Действительно ли ни один из противников smtp PG>> callout не шлёт ни echoreply, ни unreachable ни с одной из своих PG>> железок? PG>> Или я что-то упускаю в логике?

...
Ещё подумал: чем smtp callout принципиально отличается от tcp synack, посылаемого жертве в ответ на попытку установки соединения на 25/tcp?

...
...
On Mon, Aug 31, 2009 at 08:44:01PM +0300, Pavel Gulchouck wrote:

...
Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

-- Науман Олег

Pavel Gulchouck

8:15 p.m.

On Mon, Aug 31, 2009 at 11:05:02PM +0300, Oleg V. Nauman writes:

...

On Monday 31 August 2009 22:30:28 Pavel Gulchouck wrote:

...
On Mon, Aug 31, 2009 at 10:22:54PM +0300, Alex Belinsky writes:

...
Паша, in и out не всегда одно и то же.

Я бы сказал, что оно вообще редко одно и то же. :) Но к чему это в данном случае?

...

Шлет один сервер, проверяют либо тот же ( что чаще всего бесмысслено )

А, я про этот вариант не думал. Какой MTA так делает? Это ведь куча нормальной почты будет отброшена. Ну и наличие кривых реализаций не является аргументом против технологии.

...

либо сервер который это письмо не слал.

Не слал - ну и что? DNS мне тоже ничего не слал, но я же могу запросить у него, существует ли такой домен? То же и с почтовиком, разве нет?

...

...
Я привожу примеры возможных DDoS-атак с использованием udp, icmp или tcp synack аналогично атаке через smtp callout. То есть, я посылаю tcp syn req от твоего имени на миллион smtp-серверов, и ты получаешь миллион synack от разных источников. Разве не то же самое, что с callout? Аналогично я могу послать миллион udp-запросов от твоего имени или миллион пингов. Почему именно smtp callout считают некошерными, а ответ на пинги - нормальным?

...

Sender callout есть ответ на запрос которого проверяемый сервер не делал

Равно как и во всех перечисленных мной случаях (tcp syn, udp, icmp) при forged ip source. -- Паша.

Oleg V. Nauman

8:37 p.m.

On Monday 31 August 2009 23:15:05 Pavel Gulchouck wrote:

...

On Mon, Aug 31, 2009 at 11:05:02PM +0300, Oleg V. Nauman writes:

...
On Monday 31 August 2009 22:30:28 Pavel Gulchouck wrote:

...
On Mon, Aug 31, 2009 at 10:22:54PM +0300, Alex Belinsky writes:

...
Паша, in и out не всегда одно и то же.

Я бы сказал, что оно вообще редко одно и то же. :) Но к чему это в данном случае?

Шлет один сервер, проверяют либо тот же ( что чаще всего бесмысслено )

А, я про этот вариант не думал. Какой MTA так делает? Это ведь куча нормальной почты будет отброшена.

В смысле? Это следствие того факта что outbound != inbound на котором есть смысл делать проверку. А outbound вообще не обязан знать о кастомерах.

...

Ну и наличие кривых реализаций не является аргументом против технологии.

...
либо сервер который это письмо не слал.

Не слал - ну и что? DNS мне тоже ничего не слал, но я же могу запросить у него, существует ли такой домен? То же и с почтовиком, разве нет?

...
...
Я привожу примеры возможных DDoS-атак с использованием udp, icmp или tcp synack аналогично атаке через smtp callout. То есть, я посылаю tcp syn req от твоего имени на миллион smtp-серверов, и ты получаешь миллион synack от разных источников. Разве не то же самое, что с callout? Аналогично я могу послать миллион udp-запросов от твоего имени или миллион пингов. Почему именно smtp callout считают некошерными, а ответ на пинги - нормальным?

Sender callout есть ответ на запрос которого проверяемый сервер не делал

Равно как и во всех перечисленных мной случаях (tcp syn, udp, icmp) при forged ip source.

Ну так правильно, далее следующий малюсенький шаг по цепочке логики.. Реализация sender callout есть реализация forged SMTP sender. -- Науман Олег

Vladimir Velychko

11:14 p.m.

2009/8/31 Pavel Gulchouck :

...

Hi!

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

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

...

Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

-- Паша. -- VEL-[RIPE|UANIC]

Pavel Gulchouck

1 Sep 1 Sep

4:35 a.m.

On Mon, Aug 31, 2009 at 11:37:18PM +0300, Oleg V. Nauman writes: OVN> On Monday 31 August 2009 23:15:05 Pavel Gulchouck wrote:

...

...
On Mon, Aug 31, 2009 at 11:05:02PM +0300, Oleg V. Nauman writes:

...
On Monday 31 August 2009 22:30:28 Pavel Gulchouck wrote:

...
On Mon, Aug 31, 2009 at 10:22:54PM +0300, Alex Belinsky writes:

...
Паша, in и out не всегда одно и то же.

Я бы сказал, что оно вообще редко одно и то же. :) Но к чему это в данном случае?

Шлет один сервер, проверяют либо тот же ( что чаще всего бесмысслено )

А, я про этот вариант не думал. Какой MTA так делает? Это ведь куча нормальной почты будет отброшена.

...

В смысле? Это следствие того факта что outbound != inbound на котором есть смысл делать проверку. А outbound вообще не обязан знать о кастомерах.

Какой MTA делает callout на отправляющий сервер, а не по MX? И, повторюсь, это всего лишь кривая реализация, которая не говорит о кривизне технологии.

...

...
...
либо сервер который это письмо не слал.

Не слал - ну и что? DNS мне тоже ничего не слал, но я же могу запросить у него, существует ли такой домен? То же и с почтовиком, разве нет?

...
...
Я привожу примеры возможных DDoS-атак с использованием udp, icmp или tcp synack аналогично атаке через smtp callout. То есть, я посылаю tcp syn req от твоего имени на миллион smtp-серверов, и ты получаешь миллион synack от разных источников. Разве не то же самое, что с callout? Аналогично я могу послать миллион udp-запросов от твоего имени или миллион пингов. Почему именно smtp callout считают некошерными, а ответ на пинги - нормальным?

Sender callout есть ответ на запрос которого проверяемый сервер не делал

Равно как и во всех перечисленных мной случаях (tcp syn, udp, icmp) при forged ip source.

...

Ну так правильно, далее следующий малюсенький шаг по цепочке логики.. Реализация sender callout есть реализация forged SMTP sender.

Но почему же возможность организации DDoS является аргументом против smtp callout, но по аналогичным соображениям в blacklist не заносятся сервера, отвечающие на 53/udp, на icmp echorequest, шлющие icmp unreachable? Через них тоже можно сделать DDoS. Мало того: DDoS можно сделать через smtp-сервера, не делающие callout, отправляя на них tcp syn от имени жертвы. Так почему именно callout считается неправильным, а все остальные аналогичные вещи - нормальными? -- Паша.

Pavel Gulchouck

4:39 a.m.

On Tue, Sep 01, 2009 at 02:14:45AM +0300, Vladimir Velychko writes: VV> 2009/8/31 Pavel Gulchouck :

...

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

VV> Дык а что происходит, когда на мосту встречаются два барана (два МТА с VV> sender callout) ? VV> Калаутят друг друга до потери пульса. VV> Тоже самое происходит, если с одной стороны sender callout, а с другой greylist. Чтобы такого не случалось, callout делается от имени "<>" либо от адреса, для которого callout не делается (например, postmaster@...). Складывается впечатление, что callout считается не модным и делающие callout заносятся в blacklist из-за того, что есть кривые реализации callout. Но это ведь бред?

...

...
Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

-- Паша.

Vladimir Litovka

6:11 a.m.

Я недавно возился с этим вопросом, решил для себя что а) в чем-то backscatter прав и б) затраты на callout несколько выше, чем отсечение письма по ошибкам в заголовках и в envelope, например: 2009-08-15 23:16:48 rejected EHLO from (afcn215.neoplus.adsl.tpnet.pl) [83.10.122.236] 2009-08-15 23:16:50 rejected EHLO from (201-95-6-21.dsl.telesp.net.br) [189.18.213.4] 2009-08-15 23:16:52 rejected EHLO from (aamo225.neoplus.adsl.tpnet.pl) [83.29.64.130] 2009-08-15 23:16:56 rejected EHLO from (MBEAMTB) [85.198.148.237] 2009-08-15 23:17:00 rejected EHLO from ( 189-73-211-36.dsl.cbace701.brasiltelecom.net.br) [201.11.180.8] 2009-08-15 23:17:02 rejected EHLO from ( 189-74-220-226.paemt702.dsl.brasiltelecom.net.br) [200.96.171.59] 2009-08-15 23:17:06 rejected EHLO from ([190.87.77.103]) [190.87.120.13] таким образом отсекается вот такой процент входящих: [root@vugluskr /var/log/exim]# cat mainlog |grep rejected |wc -l 74303 [root@vugluskr /var/log/exim]# cat mainlog |grep "<= " |wc -l 1925 оставшийся процент - вполне subject для локальной обработки и дальнейшего отстрела. IMHO, понятное дело - у меня не production mail server :-) 2009/8/31 Pavel Gulchouck

...

Hi!

Ходят слухи, что использовать smtp sender callout нынче уже не модно: http://www.backscatterer.org/?target=sendercallouts Что по этому поводу думает прогрессивная общественность? Никто ли не обидится на резолвинг домена отправителя (без callout), или за это уже тоже могут в пособники спамеров записать, поскольку таким образом можно сделать DDoS на 53/udp?

-- Паша.

-- /doka

Marina S. Uzhentseva

7:27 a.m.

Приветствую On Tuesday 01 of September 2009 09:11:52 Vladimir Litovka wrote:

...

таким образом отсекается вот такой процент входящих:

[root@vugluskr /var/log/exim]# cat mainlog |grep rejected |wc -l 74303 [root@vugluskr /var/log/exim]# cat mainlog |grep "<= " |wc -l 1925

оставшийся процент - вполне subject для локальной обработки и дальнейшего отстрела.

Не, от sender verify пока отказываться не буду. Даже после чтения backscatter. У меня сначала чекается HELO/EHLO (режектится IP-only or IP-starting), а потом sender verify. Получается вот что: [ /var/log/exim]# grep -c "rejected EHLO or HELO" mainlog* mainlog:288 mainlog.0:656 mainlog.1:255 mainlog.2:321 mainlog.3:539 mainlog.4:766 mainlog.5:816 mainlog.6:769 mainlog.7:485 [ /var/log/exim]# grep -c "ender verify" mainlog* mainlog:5928 mainlog.0:50684 mainlog.1:13116 mainlog.2:15014 mainlog.3:45084 mainlog.4:61902 mainlog.5:47544 mainlog.6:55574 mainlog.7:13512 [ /var/log/exim]# grep -c "<=" mainlog* mainlog:703 mainlog.0:2135 mainlog.1:374 mainlog.2:429 mainlog.3:2205 mainlog.4:2325 mainlog.5:2573 mainlog.6:2143 mainlog.7:442

...

IMHO, понятное дело - у меня не production mail server :-)

С каких оборотов будем начинать считать relay продакшном? ;) -- Marina S. Uzhentseva UM551-RIPE

Vladimir Litovka

7:31 a.m.

Цифры отличаются разительно. А в каком порядке Exim делает проверку? если включен sender verify - то сначала он или HELO/EHLO? Потому что у меня реджектов по HELO/EHLO десятки тысяч, а у тебя - несколько сотен versus десятки тысяч по sender verify. 2009/9/1 Marina S. Uzhentseva

...

Приветствую

On Tuesday 01 of September 2009 09:11:52 Vladimir Litovka wrote:

...
таким образом отсекается вот такой процент входящих:

[root@vugluskr /var/log/exim]# cat mainlog |grep rejected |wc -l 74303 [root@vugluskr /var/log/exim]# cat mainlog |grep "<= " |wc -l 1925

оставшийся процент - вполне subject для локальной обработки и дальнейшего отстрела.

Не, от sender verify пока отказываться не буду. Даже после чтения backscatter. У меня сначала чекается HELO/EHLO (режектится IP-only or IP-starting), а потом sender verify. Получается вот что:

[ /var/log/exim]# grep -c "rejected EHLO or HELO" mainlog* mainlog:288 mainlog.0:656 mainlog.1:255 mainlog.2:321 mainlog.3:539 mainlog.4:766 mainlog.5:816 mainlog.6:769 mainlog.7:485 [ /var/log/exim]# grep -c "ender verify" mainlog* mainlog:5928 mainlog.0:50684 mainlog.1:13116 mainlog.2:15014 mainlog.3:45084 mainlog.4:61902 mainlog.5:47544 mainlog.6:55574 mainlog.7:13512 [ /var/log/exim]# grep -c "<=" mainlog* mainlog:703 mainlog.0:2135 mainlog.1:374 mainlog.2:429 mainlog.3:2205 mainlog.4:2325 mainlog.5:2573 mainlog.6:2143 mainlog.7:442

...
IMHO, понятное дело - у меня не production mail server :-)

С каких оборотов будем начинать считать relay продакшном? ;)

-- Marina S. Uzhentseva UM551-RIPE

-- /doka

Dmitry Kiselev

7:42 a.m.

Добрый день! On Tue, Sep 01, 2009 at 10:27:37AM +0300, Marina S. Uzhentseva wrote:

...

...
IMHO, понятное дело - у меня не production mail server :-)

С каких оборотов будем начинать считать relay продакшном? ;)

С начала получения денег за этот сервис [в составе другой услуги]? -- Dmitry Kiselev

Marina S. Uzhentseva

7:49 a.m.

Приветствую On Tuesday 01 of September 2009 10:31:35 Vladimir Litovka wrote:

...

Цифры отличаются разительно. А в каком порядке Exim делает проверку? если включен sender verify - то сначала он или HELO/EHLO? Потому что у меня реджектов по HELO/EHLO десятки тысяч, а у тебя - несколько сотен versus десятки тысяч по sender verify.

Порядок проверки в конфиге exim-а: acl_check_helo: .include /usr/local/etc/exim/acl-check-helo.conf acl_check_rcpt: accept hosts = : accept authenticated = * .include /usr/local/etc/exim/acl-check-rcpt.conf deny domains = +local_domains local_parts = ^[.] : ^.*[@%!/|] deny domains = !+local_domains local_parts = ^[./|] : ^.*[@%!] : ^.*/\\.\\./ accept local_parts = postmaster domains = +local_domains accept local_parts = abuse domains = +local_domains accept hosts = +accept_from_hosts # require verify = sender deny message = Sender verification failed. hosts = !+accept_from_hosts !verify = sender/callout=60s /usr/local/etc/exim/acl-check-helo.conf : accept hosts = : accept hosts = +relay_from_hosts drop condition = ${if match{$sender_helo_name}{MY_IP}{yes}{no} } message = "Dropped spammer pretending to be us" drop condition = ${if match{$sender_helo_name}{^[0-9]\.[0-9]\.[0-9]\.[0-9]} {yes}{no} } message = "Dropped IP-only or IP-starting helo" accept -- Marina S. Uzhentseva UM551-RIPE

Marina S. Uzhentseva

8:03 a.m.

Приветствую On Tuesday 01 of September 2009 10:42:30 Dmitry Kiselev wrote:

...

...
С каких оборотов будем начинать считать relay продакшном? ;)

С начала получения денег за этот сервис [в составе другой услуги]?

Ok, у меня тогда маленький продакшн ;) -- Marina S. Uzhentseva UM551-RIPE

Max A. Krasilnikov

9:43 a.m.

День добрий! Tue, Sep 01, 2009 at 02:14:45AM +0300, vvelychko wrote:

...

2009/8/31 Pavel Gulchouck :

...
Hi!

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

...

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

Только если оба кривы. Иначе - просто более длинный callout с элементами greylist :) -- WBR, pseudo Avalon Project http://avalon.org.ua

Vladimir Velychko

10:59 a.m.

2009/9/1 Pavel Gulchouck :

...

On Tue, Sep 01, 2009 at 02:14:45AM +0300, Vladimir Velychko writes: VV> 2009/8/31 Pavel Gulchouck :

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

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

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

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

...

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

Спамеры любят слать на последние МХ-ы в списке, которые уже в свою очередь валят всё на основной сервер. И колаутить свой МХ на предмет проверки сендера... В кач-ве последних МХ-ов не редко используются МТА вышестоящего провайдера со своими антиспам политиками... ИМО проверка отправителя скорее зло, чем польза (интересно, есть статистика, сколько писем среди режектнутых было легальных, а не спамом? (-: ) А вот проверка получателя оч. даже правильно (чего оч. нехватает на неподконтрьных МХ-ах). -- VEL-[RIPE|UANIC]

Marina S. Uzhentseva

11:03 a.m.

Приветствую On Tuesday 01 of September 2009 13:59:59 Vladimir Velychko wrote:

...

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

Почему же зло? Учитывая количество спама со сгенерированными роботом адресами в поле FROM. Я вот считаю, что отправка почты в мир с несуществующими адресами в поле FROM - зло ;)

...

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

А это уже можно проверять отдельно, после sender verify. -- Marina S. Uzhentseva UM551-RIPE

Vladimir Velychko

11:18 a.m.

2009/9/1 Marina S. Uzhentseva :

...

Приветствую

On Tuesday 01 of September 2009 13:59:59 Vladimir Velychko wrote:

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

Почему же зло?

Потому что больше вреда чем пользы :-)

...

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

А это уже можно проверять отдельно, после sender verify.

Вот им и пользуемся. :) -- VEL-[RIPE|UANIC]

Marina S. Uzhentseva

11:27 a.m.

Приветствую On Tuesday 01 of September 2009 14:18:54 Vladimir Velychko wrote:

...

...
On Tuesday 01 of September 2009 13:59:59 Vladimir Velychko wrote:

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

Почему же зло?

Потому что больше вреда чем пользы :-)

Я, может, что-то недопонимаю, но я не вижу, где вреда больше, чем пользы. Честно. Я там ниже статистику своих режектов приводила. Так вот sender verify - у меня вне конкуренции. Кстати, результаты коллаута хранятся в кэше какое-то время, поэтому релей не долбится каждый раз за проверкой на MX домена, который стоит в поле FROM. А еще выше в треде, Павел Гульчук хорошо сказал: PG> Как интересно (я имею ввиду постановку в один ряд этих действий). PG> А слать icmp echoreply и/или icmp unreachable ещё можно? Отвечать на PG> валидные udp-запросы? Ведь это всё (и многое другое) можно использовать PG> для организации DDoS. Действительно ли ни один из противников smtp PG> callout не шлёт ни echoreply, ни unreachable ни с одной из своих PG> железок? PG> Или я что-то упускаю в логике? PG> Ещё подумал: чем smtp callout принципиально отличается от tcp synack, PG> посылаемого жертве в ответ на попытку установки соединения на 25/tcp? -- Marina S. Uzhentseva UM551-RIPE

Oleg V. Nauman

11:34 a.m.

On Tuesday 01 September 2009 13:59:59 Vladimir Velychko wrote:

...

2009/9/1 Pavel Gulchouck :

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

VV> 2009/8/31 Pavel Gulchouck :

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

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

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

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

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

Спамеры любят слать на последние МХ-ы в списке, которые уже в свою очередь валят всё на основной сервер. И колаутить свой МХ на предмет проверки сендера... В кач-ве последних МХ-ов не редко используются МТА вышестоящего провайдера со своими антиспам политиками... ИМО проверка отправителя скорее зло, чем польза (интересно, есть статистика, сколько писем среди режектнутых было легальных, а не спамом? (-: ) А вот проверка получателя оч. даже правильно (чего оч. нехватает на неподконтрьных МХ-ах).

И все больше и больше серверов сейчас Вам вернут 250 на любой rcpt to: для своих доменов - молча дропнув все что не надо. Во избежание. И правильно. -- Науман Олег

vladimir.sharun＠ukr.net

12:20 p.m.

Sender verify полезен только против определенного кол-ва фримейлов, как больших сосредоточителей пользователей. Но на них можно схватить бан за словарную атаку. Далее - плох SVC тем, что отнимает твои ресурсы (процессоры не резиновые) и позволяет забить принимающие стволы ботнетом из пары-тройки сотен хостов. Средний ботнет, который бомбит нас - 10-70к хостов. Проверять существование домена отправителя можно и нужно, более того - проверять насколько домен существует с МХ записью или просто хост, за что ставить/снимать баллы. Да, грейлистинг рулит, равно как и поведенческий анализ хоста. Но в любом случае надо понимать недостатки грейлистинга в его классическом варианте (настоятельно не рекомендую к использованию ибо тупняк и кастомерский вой) и смотреть, как себя ведет хост и следить за его "кредитной историей". Пример: появляется некий хост без бэкрезолва (получи сразу балл в минус), который до now() не доставил еще ни одного письма и пытается влить сразу в большом кол-ве почты. А теперь смотрим на получателей, а точнее кол-во фэйлов среди них. Если переваливает за какие-то разумные коэффициенты - иди подолбись часиков 5 об файрвол, бот херов. Ну и т.д. Срабатывают поведенческие методики на большом волуме почты (500-1000 доменов минимум и/или кол-во писем от 3-4 сотен тысяч в сутки).

...

Ещё подумал: чем smtp callout принципиально отличается от tcp synack, посылаемого жертве в ответ на попытку установки соединения на 25/tcp?

Vladimir Velychko

1:42 p.m.

2009/9/1 : ...

...

Да, грейлистинг рулит, равно как и поведенческий анализ хоста. Но в любом случае надо понимать недостатки грейлистинга в его классическом варианте (настоятельно не рекомендую к использованию ибо тупняк и кастомерский вой) и

Кстати (если не ошибаюсь) ukr.net пришлось внести в whitelist (greylist'a) потому что слал письмо только раз, т.е. получив "451 Please try later" повторно не слал. -- VEL-[RIPE|UANIC]

vladimir.sharun＠ukr.net

1:45 p.m.

Ошибаешься :) Там чуть-чуть поправленные дефолтные retry rules. В любом случае за грейлистингом нужен глаз да глаз, т.к. есть системы, которые имеют общий спул, а шлют с разных хостов - с ними только руками.

...

...
Да, грейлистинг рулит, равно как и поведенческий анализ хоста. Но в любом случае надо понимать недостатки грейлистинга в его классическом варианте (настоятельно не рекомендую к использованию ибо тупняк и кастомерский вой) и

Кстати (если не ошибаюсь) ukr.net пришлось внести в whitelist (greylist'a) потому что слал письмо только раз, т.е. получив "451 Please try later" повторно не слал.

Vladimir Velychko

1:53 p.m.

Может быть и ошибся, но в вайтлисте точно есть. :-) 2009/9/1 :

...

Ошибаешься :) Там чуть-чуть поправленные дефолтные retry rules. В любом случае за грейлистингом нужен глаз да глаз, т.к. есть системы, которые имеют общий спул, а шлют с разных хостов - с ними только руками.

...
...
Да, грейлистинг рулит, равно как и поведенческий анализ хоста. Но в любом случае надо понимать недостатки грейлистинга в его классическом варианте (настоятельно не рекомендую к использованию ибо тупняк и кастомерский вой) и

Кстати (если не ошибаюсь) ukr.net пришлось внести в whitelist (greylist'a) потому что слал письмо только раз, т.е. получив "451 Please try later" повторно не слал.

-- VEL-[RIPE|UANIC]

Lystopad Olexandr

2:03 p.m.

Hello, vladimir.sharun@ukr.net! On Tue, Sep 01, 2009 at 04:45:37PM +0300 vladimir.sharun@ukr.net wrote about "Re: [uanog] smtp sender verify":

...

Ошибаешься :) Там чуть-чуть поправленные дефолтные retry rules. В любом случае за грейлистингом нужен глаз да глаз, т.к. есть системы, которые имеют общий спул, а шлют с разных хостов - с ними только руками.

Или грейлистить не x.y.z.w, а x.y.z так как обычно хосты эти все в одной /24 сети сидят. Ну и + глаз да глаз, но уже меньше.. :) -- Olexandr Lystopad

Pavel Gulchouck

2:48 p.m.

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> Везде, где сталкивался с этой фичей были приведённые выше проблемы. То есть, фича плоха, потому что везде, где ты её видел, её сетапили криворукие админы? Странная логика. Криво настроить callout в exim - это ещё постараться надо. Как в других MTA - не знаю.

...

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

VV> Спамеры любят слать на последние МХ-ы в списке, которые уже в свою очередь VV> валят всё на основной сервер. И колаутить свой МХ на предмет проверки сендера... Да кто придумал, что проверять сендера нужно на отправляющем серваке, а не в соответствии с MX-ами? Откуда вообще такая странная идея взялась? Кто (какой MTA) так делает? VV> ИМО проверка отправителя скорее зло, чем польза (интересно, есть VV> статистика, сколько писем среди режектнутых было легальных, а не VV> спамом? (-: ) Много ли шлётся нормальных писем с несуществующих или неработающих адресов? Думаю, что почти не шлются. Мне такие хочется получать крайне редко. То есть, ложных срабатываний у такой проверки гораздо меньше, чем от цифровых helo и других подобных. Если, конечно, делать sender verify нормально, а не у отправляющего сервера спрашивать или другие неожиданные способы применять. VV> А вот проверка получателя оч. даже правильно (чего оч. нехватает на VV> неподконтрьных МХ-ах). Зачем и в каких случаях нужны (полезны) неподконтрольные MX-ы? Чем они могут быть вредны - очевидно: нет доступа к логам, сильно снижена секьюрность, может быть изменение настроек без предупреждения, например, ограничение на размер письма и т.д. То есть, вот как раз от неподконтрольных MX-ов IMHO вреда больше, чем пользы. Проверка получателя по SMTP - тоже довольно неоднозначная фича. Ведь тогда фактически получается, что лежание младшего MX приводит к тому, что все остальные тоже отказываются принимать почту. Зачем тогда они нужны? И тогда получается, что при получении почты через старший MX младшему нужно не просто принять эту почту, а сначала провести пустую smtp-сессию для проверки получателя, а потом настоящую (со старшим MX) для приёма почты, т.е. установка backup MX с receipient verify увеличит нагрузку на primary MX. Чтобы этого не было, каждый MX должен сам знать валидные почтовые адреса в домене получателя, без всяких verify receipient через smtp - тогда нагрузка будет снижена. -- Паша.

Oleg V. Nauman

3:30 p.m.

On Tuesday 01 September 2009 17:48:26 Pavel Gulchouck wrote:

...

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> Везде, где сталкивался с этой фичей были приведённые выше проблемы.

То есть, фича плоха, потому что везде, где ты её видел, её сетапили криворукие админы? Странная логика. Криво настроить callout в exim - это ещё постараться надо. Как в других MTA - не знаю.

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

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

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

Ну вот например http://www.postfix.org/ADDRESS_VERIFICATION_README.html -- Науман Олег

Vladimir Velychko

3:36 p.m.

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]

Mykola Dzham

9:19 p.m.

Vladimir Velychko wrote:

...

2009/9/1 Pavel Gulchouck :

...
On Tue, Sep 01, 2009 at 02:14:45AM +0300, Vladimir Velychko writes: VV> 2009/8/31 Pavel Gulchouck :

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

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

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

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

Или у Вас кривая статистика, или Вы просто замечаете наличие каллаута только когда вылазят вот такие вот проблемы.

...

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

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

Дык не надо каллаутить свои MX-ы, пусть они сами каллаутят.

...

В кач-ве последних МХ-ов не редко используются МТА вышестоящего провайдера со своими антиспам политиками...

По моему держание backup MX-ов на неподконтрольных серверах сейчас особого смысла не имеет, а часто вообще backup и не нужен: если что и у отправителя в очереди полежит немного.

...

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

Такую статистику по любой проверке хотелось бы видеть. Но почему-то практически всегда любят показывать только "сколько процентов почты было отбито", при этом подразумевая что вся отбитая почта являлась спамом. -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua

George Belousov

3 Sep 3 Sep

5:48 a.m.

Доброе утро. Вот мои цифры, с 2х релеев. Порядок проверок: helo (empty, syntax, regexp), svc, rbl, etc root@logs:~# zcat /var/log/mail.log.1.gz |grep ACL-EMPTY-HELO- |wc -l 1598 root@logs:~# zcat /var/log/mail.log.1.gz |grep ACL-SYNTAX-HELO |wc -l 1140713 root@logs:~# zcat /var/log/mail.log.1.gz |grep ACL-REGEXP-HELO |wc -l 914780 root@logs:~# zcat /var/log/mail.log.1.gz |grep ACL-REGEXP-PTR |wc -l 201259 root@logs:~# zcat /var/log/mail.log.1.gz |grep "sender verify" |wc -l 596726 1 сентября 2009 г. 11:27 пользователь Marina S. Uzhentseva (samemari@gmail.com) написал:

...

Приветствую

On Tuesday 01 of September 2009 09:11:52 Vladimir Litovka wrote:

...
таким образом отсекается вот такой процент входящих:

[root@vugluskr /var/log/exim]# cat mainlog |grep rejected |wc -l 74303 [root@vugluskr /var/log/exim]# cat mainlog |grep "<= " |wc -l 1925

оставшийся процент - вполне subject для локальной обработки и дальнейшего отстрела.

Не, от sender verify пока отказываться не буду. Даже после чтения backscatter. У меня сначала чекается HELO/EHLO (режектится IP-only or IP-starting), а потом sender verify. Получается вот что:

[ /var/log/exim]# grep -c "rejected EHLO or HELO" mainlog* mainlog:288 mainlog.0:656 mainlog.1:255 mainlog.2:321 mainlog.3:539 mainlog.4:766 mainlog.5:816 mainlog.6:769 mainlog.7:485 [ /var/log/exim]# grep -c "ender verify" mainlog* mainlog:5928 mainlog.0:50684 mainlog.1:13116 mainlog.2:15014 mainlog.3:45084 mainlog.4:61902 mainlog.5:47544 mainlog.6:55574 mainlog.7:13512 [ /var/log/exim]# grep -c "<=" mainlog* mainlog:703 mainlog.0:2135 mainlog.1:374 mainlog.2:429 mainlog.3:2205 mainlog.4:2325 mainlog.5:2573 mainlog.6:2143 mainlog.7:442

-- WBR, George Belousov NULL-RIPE

5588

Age (days ago)

5591

Last active (days ago)

List overview

Download

37 comments

14 participants

participants (14)

Alex Belinsky
Dmitry Kiselev
George Belousov
Lystopad Olexandr
Marina S. Uzhentseva
Max A. Krasilnikov
Mykola Dzham
Oleg V. Nauman
Pavel Gulchouck
Valentin Nechayev
Vasiliy P. Melnik
Vladimir Litovka
Vladimir Velychko
vladimir.sharun＠ukr.net