LINUX.ORG.RU

Вышел sendmail 8.13.6: устранена серьезная уязвимость


0

0

Вышла версия 8.13.6 самого популярного почтового сервера. В новой версии исправлена серьезная ошибка (CVE-2006-0058), позволяющая удаленному пользователю выполнять на целевой системе произвольные команды с правами пользователя, запустившего sendmail (часто это root). Уязвимы все предыдущие версии, разработчики рекомендуют всем срочно обновиться.

>>> Сайт проекта

★★

Проверено: Tima_ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

Потому что ему не только сокет открыть и привилегии сбросить, но и с файлами различными работать /etc/mail, /var/spool/mqueue, ~user/.forward, ...

A middle ground is to make sendmail setuid to root, but set the RunAsUser option. This causes sendmail to become the indicated user as soon as it has done the startup that requires root privileges (primarily, opening the SMTP socket). If you use RunAsUser, the queue directory (normally /var/spool/mqueue) should be owned by that user, and all files and databases (including user .forward files, alias files, :include: files, and external databases) must be readable by that user. RunAsUser is probably best suited for firewall configurations that don't have regular user logins.

Тут SUID ...

sdio ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

А Вы имеете реальный опыт эксплуатации сендмэйла? Я вижу, что нет. Что бы сендмэйл поднял новый бинарник его достаточно просто HUPнуть. При этом обработка почтны не останавливается ни на секунду.

PS: а qmail без патчей уже научился переберать МХы зоны или все так же херит почту, если первый МХ в дауне?

GeoF ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> qmail не возвращает оригинал письма,

Не важно, что он возвращает.

> делая подобную рассылку бессмысленной.

В ней и нет смысла, смысл для спаммера в спаме первого порядка. Спам второго порядка всего лишь последствие.

> При чем тут <> вообще не понятно

Да совершенно не при чем !! Я этот mail from использовать исключительно как просто какой-то mail from. Я же говорю, суть того примера, что я привёл в начале, rcpt to. То, что сервер принял сообщение для несуществующего пользователя. Точно так же он примет и в случае оверквоты, и т.д. Да, если mail from бкдет <>, боунса не будет, то только вот и mail from:<> в реальной ситуации тоже не будет.

> Чем отличется от того же sendmail?

Тем, что вместо

rcpt to:<jsajasbvja@cr.yp.to>
250 ok

он скажет

rcpt to:<jsajasbvja@cr.yp.to>
550 5.1.1 <jsajasbvja@cr.yp.to>... User unknown

Дальше еще объяснять ?

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> /etc/mail, /var/spool/mqueue,

Тут поможет общая группа.

> ~user/.forward, ...

С этим сложнее, что-то я как-то про него даже забыл. С одной стороны, в общем, можно общую группу тоже, но это будет означать, что юзеры смогут свои форвардв смотреть. А можно запретить использовать этот самый forward.

На самом деле, на крупных серверах почту в обычном майлбоксе/майлдире мало кто хранит, как правило, используется какой-либо imap-сервер, который получает почту от MTA, скажем, по lmtp, а вот тогда MTA совсем не надо работать с файлами юзеров.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> он скажет > > rcpt to:<jsajasbvja@cr.yp.to> > 550 5.1.1 <jsajasbvja@cr.yp.to>... User unknown > > Дальше еще объяснять ? > > AS ** (*) (23.03.2006 20:04:37)

О чем это говорит? о том, что процесс, принимающий соединения должен иметь доступ к базе данных адресов. Если в этом процессе обнаруживается уязвимость, то база оказывается в руках спамера, после чего уже делается целевая рассылка всем пользователям данного провайдера. qmail защишает своих пользователей, а то, что bounce идет кому-то еще - это вина спамера, а не провайдера. У меня, например, есть адрес, на который я принимаю только сообщения с действующим сертификатом. Если сертификата нет или он невалиден, то отправителю возващается вежливое сообщение о том, что следует подписать свое письмо и отправить еще раз. Это очень действенно против спамеров, но может так же вызвать "спам второго уровня". Волнует ли меня это? Нет, ибо я борюсь таким образом против спама к себе, а не пытаюсь защитить весь мир. Это мой личный почтовый адрес и если человек не достаточно уважает меня, чтобы подписать свое письмо, то я не считаю нужным его читать.

Bogerm ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> И про отправку почты локальными демонами не забыть
> mail или
> ... | /usr/sbin/sendmail

с этим все в порядке. Начиная с 8.12 он стартует из-под юзера в конфигурации по-умолчанию.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> а вот тогда MTA совсем не надо работать с файлами юзеров.

тогда он не сможет делать reject в момент получения письма или для этого процесса придется делать LDAP/MySQL соединение к базе пользователей.

Bogerm ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> должен иметь доступ к базе данных адресов

Запущенный qmail и так имеет доступ к базе данных адресов. Если он не в chroot или если... Впрочем, зачем объяснять очевидные вещи, можете почитать.

> qmail защишает своих пользователей,

теперь это так называется ? :-) Теоретически, я мог бы хоть сейчас дать рутовый доступ на сервер с sendmail, мне очень интересно, как будет получена оттуда база юзеров. :-) На практике, конечно, я это не сделаю, так как головной боли много. Хотя, если это будет спор на, скажем, $1000, я бы подумал... :-) Нет, лучше на $10000.
Но рассказать могу, там всё просто и очевидно - всё равно спорить не будете.

> что bounce идет кому-то еще - это вина спамера, а не провайдера.

Это - вина постмастера.

> Волнует ли меня это? Нет, ибо я борюсь таким образом против спама к себе,

Зато это волнует того, к кому этот спам приходит. И домен уходит нахрен в блек-лист. А потом будешь бабушке во дворе рассказывать, что ты не спаммер. Так-то вот...

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>> а вот тогда MTA совсем не надо работать с файлами юзеров.

> тогда он не сможет делать reject в момент получения письма или для
> этого процесса придется делать LDAP/MySQL соединение к базе
> пользователей.

Предлагаю читать про socket map в sendmail и smmapd в cyrus-imap до просвещения.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

to AS: постфикс действительно щас не принимает почту для несуществуещего юзера. а для кумыла есть патчик большой такой - chkuser. И тогда насколько я знаю ответов не будет.

IMHO: sendmail и qmail сложны в настройке. sendmail своим конфигом, а кумыло тем что любой функционал прикручивается n-ым количеством патчей. И это имхо действительно проблема. А чистый кумэйл имхо никто не использует (ну разве, что дома).

Золотая середина postfix. :-)

tugrik ★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> > 1. Спам легко пройдёт проверку на smtp callback. > 2. на cr.yp.to посыпется вагон отлупов и создаст нехилый трафик.

> Не пойдет если домен настроен нормальным админом, а не адептом sendmail. Письмо от <> распознается как письмо от MAILER-DAEMON, на которое ответ не генерится.

Да хоть не от <>, что за дыбильные отмазки?

220 a.mx.cr.yp.to NO UCE ESMTP
EHLO lor.lor
250-a.mx.cr.yp.to NO UCE
250-PIPELINING
250 8BITMIME
MAIL FROM:<asas@gnu.org>
250 ok
RCPT TO:<sdfsdf@cr.yp.to>
250 ok
DATA
354 go ahead
dfd
.
250 ok 1143143322 qp 41837
QUIT
221 a.mx.cr.yp.to NO UCE
Connection closed by foreign host.

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

кстати интересно а кто-нибудь знает что используют 
крупные рссийские фирмы в качестве почтовика:
например тот же яндекс.ру майл.ру rambler.ru ??

tugrik ★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Запущенный qmail и так имеет доступ к базе данных адресов.

К базе данных адресов доступ имеет _только_ qmail_lspawn, а qmail_smtpd работает под своим отдельным пользователем и может только передать через пайп полученное в qmail_queue.

Кстати, обрати внимание, что в качестве qmail_queue может выступать какой-нибудь qscanq, вызывающий clamdscan, или всё, что администратору угодно. А это "что-угодно" может вернуть ошибку, и тогда тогда DATA завершится не 250, а 5хх или 4хх на твой выбор.

>> qmail защишает своих пользователей

> теперь это так называется ? :-)

А чему улыбаться? djb считает VRFY, EXPN и прямой ответ "таких тут не знаем" privacy-invading.

А тебе будет легче, если сервер будет возвращать на несуществующего пользователя 4xx? Мне нравится -- пусть у спаммеров очереди пухнут ;)

baka-kun ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> К базе данных адресов доступ имеет _только_ qmail_lspawn, а
> qmail_smtpd работает под своим отдельным пользователем и может только
> передать через пайп полученное в qmail_queue.

Проблема только в том, что в, обычной жизни, доступ на чтение к passwd имеет любой процесс. Ну а если жизнь не сильно обычная (в смысле пользователи не системные, или в системе юзеры не в passwd, или процесс в chroot засунут и т.п.), то, как я уже сказал, и у sendmail к списку пользователей доступа может не быть в явном виде.

> Кстати, обрати внимание, что в качестве qmail_queue может выступать какой-нибудь qscanq

Это еще одна подпорка ? А если её убрать (ну, упала вдруг), qmail основную работу делать будет ? А вообще, на самом деле, мне интересно, если можно сделать, почему же не сделано ?

> djb считает <skip> прямой ответ "таких тут не знаем" privacy-invading.

Это проблемы только и только djb (ну и его последователей). Он славится своим "оригинальным" мнением. Видимо, все мозги истратил на программирование (не могу сказать, что плохое, кстати), а на подумать про что-то еще не осталось. :-)

> А тебе будет легче, если сервер будет возвращать на несуществующего
> пользователя 4xx? Мне нравится -- пусть у спаммеров очереди пухнут ;)

в плане описываемых событий большой разницы нет, но вот для своей системы это проблемы создаст: ты один, их много, а максимальное количество процессов/сокетов/разное конечно.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

хм...
я не знаю в чем причина но очень часто qmail на отправку такого уведомления спамеру ругается Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)
в таком случае он откладывает отправку письма, и очередь в этом случае уже начинает пухнуть у вас.

tugrik ★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> я не знаю в чем причина но очень часто qmail на отправку такого уведомления спамеру ругается

baka-kun имел ввиду сразу не принимать с 4xx. Если принял, то да, это уже твои проблемы.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Проблема только в том, что в, обычной жизни, доступ на чтение к passwd имеет любой процесс.

А кто тебе сказал, что письмо vasya.pupkine@my.super.domen.tld должно лечь в maildir к системному юзеру vasya.pupkine? А алиасы, виртуальные домены, групповые ящики? Хочешь проверку полноценную, придется нагрузить qmail_smtpd почти всей функциональностью qmail_send, qmail_lspawn и qmail_local.

> Это еще одна подпорка?

Нет. Это стандартный способ. qmail_smtpd запускает suid qmailq qmail_queue, и льет в него конверт и письмо. Если тебе нужен препроцессинг до попадания в очередь писем, ты просто вставляешь между ними свой обработчик. unix-way, однако.

> А если её убрать (ну, упала вдруг)

qmail_smtpd запускает qmail_queue на каждую сессию.

> Это проблемы только и только djb (ну и его последователей).

Не всем приятно помогать спаммерам составлять актуальные списки адресов.

> в плане описываемых событий большой разницы нет, но вот для своей системы это проблемы создаст: ты один, их много

Больше половины спаморассыльщиков действуют по принципу shoot-n-forget. Те же, кто пытается вести очередь, будут страдать тем больше, чем больше серверов в мире будут отвечать 4хх хотя бы первые пару раз на уникальный триплет ip+mail_from+rcpt_to.

baka-kun ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> О чем и речь. Уж не знаю, можно ли его довести до ума, но то, что он много где недоведённый - это совершенно бесспорно.

Нельзя, неполиткорректно так говорить. QMail не нарушает RFC. Измените
RFC сначала, добейтесь официальных поправок в протоколе, а потом
требуйте адекватных действий со стороны qmail. Нельзя решать проблему на
коленке и кто на что горазд. Всякие там SPF, greylisting - что это?
Это бардак и рукоблудство. К чему вы призываете? Это не костыли?
Сколько времени понадобится спамерам чтобы обойти эти "преграды"?
Да легко и быстро, ибо защита - тупее некуда. А вот нормальные люди
пострадают. Этак через несколько лет вообще невозможно будет пробиться
к кому-либо на почту.

И ещё я второй раз повторю: _можно_ сделать такую функциональность для
qmail. И делается это элементарно. Я уже писал, как.

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> > Это проблемы только и только djb (ну и его последователей).
> Не всем приятно помогать спаммерам составлять актуальные списки адресов.

А ведь и вправду отлупы на несуществующего юзера позволяют легко и
непринужденно составить актуальный список ящиков в домене! Простым
алфавитным перебором. Нет, в тысячный раз убеждаешься в гениальности
djb. Он ничего не делает просто так. Всё продумано до мелочей на 1000
лет вперёд.

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> А кто тебе сказал, что письмо vasya.pupkine@my.super.domen.tld
> должно лечь в maildir к системному юзеру vasya.pupkine

Да я этого и не утверждал. Я просто не понял (да и сейчас не понимаю) утверждение Bogerm "О чем это говорит? о том, что процесс, принимающий соединения должен иметь доступ к базе данных адресов. Если в этом процессе обнаруживается уязвимость, то база оказывается в руках спамера,"
Ну и привёл на вскидку несколько разных вариантов, когда может иметь, а когда может и не иметь.

> Не всем приятно помогать спаммерам составлять актуальные списки адресов.

550 в ответ на rcpt to: ? По-моему, тут больше за, чем против. По крайней мере, это даёт тебе возможность не мешать другим.

> Те же, кто пытается вести очередь, будут страдать тем больше, чем больше серверов в мире будут отвечать 4хх

Если бы их сразу стало много, пожалуй, а в одиночку или, даже, десятками начинать - тяжеловато.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> А ведь и вправду отлупы на несуществующего юзера позволяют легко и
> непринужденно составить актуальный список ящиков в домене!

Ты, в любом случае, обязан либо вернуть либо 5xx, либо боунс. Боунс вернётся чуть позже. Несколько больше шансов, что кто-то может пожаловаться кому-то, но и только.

> Нет, в тысячный раз убеждаешься в гениальности djb. Он ничего не
> делает просто так. Всё продумано до мелочей на 1000 лет вперёд.

Ага, да-да... Дебил он в том, что не касается программирования. Или просто идеалист. Не живём мы в идеальном мире, к сожалению.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Измените RFC сначала, добейтесь официальных поправок в протоколе,

550 после rcpt to вполне в рамках RFC, а голова - она не для фуражки.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>Kонфиг слишком сложный? :) >Ставим уиндовс.

Умный да? Ну настрой мне Sendmail как замену Exchange 2003 на 13000 пользователей. Железо на выбор. Цену можешь тут посчитать.

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> А ведь и вправду отлупы на несуществующего юзера позволяют легко и непринужденно составить актуальный список ящиков в домене! Простым алфавитным перебором. Нет, в тысячный раз убеждаешься в гениальности djb. Он ничего не делает просто так. Всё продумано до мелочей на 1000 лет вперёд.

Если имена пользователей больше пяти букв, найти их перебором не реально. Если они содержат ещё и цифры, то тем более.

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Я просто не понял (да и сейчас не понимаю) утверждение Bogerm "О чем это говорит? о том, что процесс, принимающий соединения должен иметь доступ к базе данных адресов.

Он должен проделать все операции, связанные с выяснением места назначения письма и его доступностью. То есть проделать все шаги вплоть до момента фактического размещения в хранилище. Соответственно, умирает вся прелесть оффлоада этой задачи на разборщик очередей. Да и сами очереди локальной доставки становятся ненужными, поскольку вот письмо, вот место назначения.

> 550 в ответ на rcpt to: ? По-моему, тут больше за, чем против.

За: нет баунса невиновному, хотя в MAIL FROM: спама реальные адреса попадаются редко, намного реже фиктивных.

Против: помогаем спамерам актуализировать списки реальных адресов. Опять таки просматривается тренд: чем больше серверов не отвечают на VRFY и не возвращают 5хх, тем больше в базах спамеров мусора, тем меньше мы мешаем невиновным, тем меньше эффективность спама...

> Если бы их сразу стало много, пожалуй, а в одиночку или, даже, десятками начинать - тяжеловато.

Ничуть. У того же qmail запас о-о-очень большой, поскольку каждая SMTP сессия _очень_ короткая (отключить ресолв реверса, идент и прочие задержки -- сессия проходит моментально).

Мы экспериментировали на небольшом сервере (около 20000 аккаунтов и одного гигабайта доставленной входящей почты в сутки) -- загрузка по concurrency подросла в пределах погрешности измерения (на 3-5%). Количество спама одновременно уменьшилось почти на четверть. Что может говорить только о том, что спаммерские сети были вынуждены пытаться повторно доставить почту вместо того, чтобы слать новый спам.

baka-kun ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Ты, в любом случае, обязан либо вернуть либо 5xx, либо боунс. Боунс вернётся чуть позже.

Но он не вернется _спаммеру_! Поэтому тот никак не узнает, что пользователя нет.

> Несколько больше шансов, что кто-то может пожаловаться кому-то, но и только.

"А это вон та редиска в ip xxx.xxx.xxx.xxx использует для рассылки спама твой адрес, подай на неё и её провайдера в суд. Боаго законы местами позволяют."

baka-kun ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Если имена пользователей больше пяти букв, найти их перебором не реально.

Так ведь "sendmail может обрабатывать МИЛЛИОНЫ писем в ЧАС"!!! ;)

Вот и считай: 26 букв, 10 цифр, плюс парочка знаков -- считаем алфавит в 40 символов. Значит, до шестисимвольных адресов мы доберемся через 102.4 миллиона попыток (то есть будем иметь список _всех_ валидных пятисимвольников). Если еще учесть недопустимые комбинации, да добавить перебор по словарю...

baka-kun ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

Сам использую Sendmail (привычка) Спор очень жесткий и бесмысленный.

Вы мне лучше скажите на чем работает gmail.com , mail.ru и hotmail.com =)

TuLiss ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>> Измените RFC сначала

> 550 после rcpt to вполне в рамках RFC

Как и 250 ;)

Речь о том, что уж если взял письмо к доставке, то единственный способ сообщить о неудаче -- баунс.

И также о том, что для _очень_крупных_ почтовых систем накладненько получается проверять получателя на этапе сессии. Им намного проще получать SMTP на "фронтенде", и быстренько сплавлять его по QMTP в машинки с queue. А из очереди либо опять-таки по QMTP на рассыльщики, либо в хранилище.

baka-kun ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>У провайдеров и больших компаний есть специально разработанные процедуры установки патчей и апгрейдов. Для этого они делают специальный стенд, на котором выполняют апгрейд, потом направляют на этот стенд поток почты ( это не 1 - 2 письма, а гигабайты ) и проверяют живучесть системы. Только после этого пишется подробный план апгрейда основной системы, оповещаются пользователи о возможных проблемах и выполняется непосредственно апгрейд. На это уходит от недели до месяца. Если не следовать такой процедуре и в момент апгрейда случится хоть малейший сбой, то в службу тех поддержки придет несколько миллионов жалоб от клиентов и она просто "утонет". Поэтому большой конторе выгоднее поставить "лишний" сервер с надежной системой, которую не нужно обновлять каждый месяц, чем жить как на пороховой бочке. По-этому и используют debian или Solaris (а в последнее время еще и RHES) в качестве серверов, apache в качестве web и qmail для приема почты.


Что-то я не понял
Если направляют на стенд поток почты, то что стенд делает с этим потоком ?
Вариант 1 - отправляет в /dev/null
Тогда где тут полноценное тестирование ?
Интересно ведь как реально с отправкой дела обстоят у этого сервера,
а не только тестировать прием.

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

И ?

odip ★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>Вот еще искать...

Мы поняли, что не не Царское дело в с конфигах ковыряться. Но тем не менее Qmail рулит (количество называть не буду, хотя оно равно примерно *000, что горбатятся на GMC. Как бля я ненавижу этот отстойник!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Desmaster ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>А ведь и вправду отлупы на несуществующего юзера позволяют легко и
>непринужденно составить актуальный список ящиков в домене! Простым
>алфавитным перебором. Нет, в тысячный раз убеждаешься в гениальности
>djb. Он ничего не делает просто так. Всё продумано до мелочей на 1000
>лет вперёд.

Так вот кто эту идиотическую идею первый придумал. А я то думаю, чего это лемминги с этой идеей как с флагом носятся, хотя простые арифметические выкладки ее развеивают в пыль? А это гениальный djb придумал, ясно тогда все.

Что-то смотрю в этой тебе все постфикс, да постфикс. А про exim всего два слова. Не пойдеть! (с) Exim - очень, очень, очень красивый, быстрый, гибкий MTA. Имхо - лучший.

Az ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Он должен проделать все операции, связанные с выяснением места назначения письма и его доступностью.

Достаточно просто спросить после rcpt to у mail storage и получить ответ можно/нельзя/подожди[/почему]

> Против: помогаем спамерам актуализировать списки реальных адресов.

Недостаточный "против". Можно просто письмо послать и посмотреть, сколько боунсов вернулось. Всего-то завести ненадолго халявный ящик где-нибудь и послать спам с этим mail from. А понять, надо слать боунс или нет не так просто... Сложнее, но выполнимо. Причём, даже, палки в колёса проще вставить в варианте с 550 - сделать задержку на ответ. В этом случае исходному процессу-переборщику гарантированно придётся работать долго, а не в виде плюнул группы сообщений и ждать. Да и вообще, не делает это практически никто, илначе не было бы столько отлупов по несуществующим пользователям.

> отключить ресолв реверса

Это не сильно здорово. Теряется возможность фильтровать всякие dsl-201-127-118-238.prod-infinitum.com.mx, а эффект от этого очень неплохой. Я, когда статистику прикинул в своё время по спам/почта по этому критерию, аж удивился. За несколько лет эксплуатации фильтра накопилось десятка три исключений всего.

Кстати, пауза секунд в 15 перед первым 220 и отлуп, если трафик раньше пошёл, тоже помогает неплохо - многие не ждут, им бы побыстрее.



AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> > Ты, в любом случае, обязан либо вернуть либо 5xx, либо боунс. Боунс вернётся чуть позже.

> Но он не вернется _спаммеру_! Поэтому тот никак не узнает, что пользователя нет.

Для этого ты должен гарантированно опознать спам. А, вдруг, это не спам, а ты боунс не вернёшь ? это не сильно хорошо.

> А это вон та редиска в ip xxx.xxx.xxx.xxx использует для рассылки спама твой адрес,

А откуда ты IP узнаешь ? Ты можешь гарантированно знать IP предыдущего релея, так как своему доверяешь, а что там было до того, можешь только предполагать... А в случае 5xx до окончания smtp-сессии боунс тебе придёт, но уже от сервера отправителя, если рассылка через нормальный сервер. Жалоба будет послана туда, где могут принять конкретные меры, а не будет проводиться игра "перешли соседу". А если через ненормальный, то и вообще не придёт.




AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Сам использую Sendmail (привычка) Спор очень жесткий и бесмысленный.

Спор, как раз, правильный. Он уже про поведение MTA. То, что с той или иной степенью удобства это можно добиться от любого MTA, уже как бы выяснили. И qmail можно обучить, и sendmail можно поставить так, что его взлом не будет иметь последствий, кроме DoS (и то еще не факт). У кого это сразу, у кого какие-то довески где-то, это уже перестало быть принципиальным сообщений 10 назад. :-)

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>1. нехрен баунсить не в тему - это спам.
Клиенты крайне неохотно идут на переделку своих систем. Им это финансово мотивировать надо. Попадание в списки+трафик для них мотивацией не является, бо это не маленькие конторы, а неповоротливые корпомонстры.

>2. нехрен bl.spamcop.net для блокировки использовать, он для этого не предназначен.

Слов нет. Его, родной, не мы и не клиенты пользуют, а недоадмины на стороне реципиента. Которые, к слову, и на письма не отвечают. Сходим им расскажи про то, что надо использовать, а что не надо.

//Loseki

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

Кстати, тем, кто тут говорил про то, что реальные адреса во From: спамерских писем встречаются много реже, чем фиктивные - неправда.

Более того, появилось спамерское мудачьё, которое во From: ставит адреса -ловушки разных спискодержателей, вроде Spamcop.

//Loseki

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Речь о том, что уж если взял письмо к доставке, то единственный способ сообщить о неудаче -- баунс.

Вопрос, кто его должен формировать. А формировать его должнен сервер отправителя на основании ответа сервера получателя, а не сервер получателя. По RFC-то всё равно, но есть ещё здравый смысл.

> И также о том, что для _очень_крупных_ почтовых систем накладненько получается проверять получателя на этапе сессии.

Вопрос, как это построить... А вот проверь очень крупные системы и посмотри, когда они отлуп дают.

Вот тебе mail.ru к примеру:

250 mx12.mail.ru ready to serve
mail from:<>
250 OK
rcpt to:<hsvcjvdkdsc@mail.ru>
250 OK
data
354 Go ahead
wew
.
550 spam message discarded. If you think that the system is mistaken, please report details to abuse@corp.mail.ru

Да, не после rcpt to, но до окончания сессии. И боунс будет формировать не он.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>И также о том, что для _очень_крупных_ почтовых систем накладненько получается проверять получателя на этапе сессии.

Ну да, на этапе сессии накладно, а прогулять письмо, проверить на месте и сгенерить баунс - не накладно. Ерунда. Генери из своей крупной системы хешированый список и пусть твой фронтенд в него смотрит.

//Loseki

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> более того, появилось спамерское мудачьё, которое во From: ставит адреса -ловушки разных спискодержателей, вроде Spamcop.

ух ты. вот этого я еще не видел.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>Вопрос, как это построить... А вот проверь очень крупные системы и посмотри, когда они отлуп дают.
> (skipped)

В том, что mail.ru отлуп на несуществующего пользователя даёт после data, никакого тайного смысла нет, просто система так построена (совместили с антиспамом каким). Накладные расходы на проверку пользователя одинаковы, что после RCPT TO, что после DATA + .

//Loseki

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> его это лемминги с этой идеей как с флагом носятся, хотя простые арифметические выкладки ее развеивают в пыль?

Дык просим в студию... простые арифметические выкладки. А там посмотрим,
кто лемминг и где будет пыль.

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>В яндексе - самописный MTA Yamail aka мулька. :)
а очень похоже на Zmailer. В самой компании (не для бесплатной почты) вовсю используется Sendmail.

anonymous ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Exim - очень, очень, очень красивый, быстрый, гибкий MTA.

Да, он тоже с Cyrus-IMAP хорошо интегрируется. :-) По крайней мере, судя по описанию.

AS ★★★★★ ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

>Нет. Это стандартный способ. qmail_smtpd запускает suid qmailq qmail_queue, и льет в него конверт и письмо. Если тебе нужен препроцессинг до попадания в очередь писем, ты просто вставляешь между ними свой обработчик. unix-way, однако.

Это не "модульность" и не "unix-way", а идотизм. Делать pipe + fork + exec на каждое письмо - это тоже самое, что использовать cgi для web. Это медленно и дорого по ресурсам.

В отоличие от того же milter API sendmail.

> А если её убрать (ну, упала вдруг)

>qmail_smtpd запускает qmail_queue на каждую сессию.

Вот именно: __на_каждую_сессию__. Вместо того, чтобы общаться по единожды созданному persistent connection.

На дворе не 1998 год, и динозавры должны уйти.

stellar ()

Re: Вышел sendmail 8.13.6: устранена серьезная уязвимость

> > его это лемминги с этой идеей как с флагом носятся, хотя простые арифметические выкладки ее развеивают в пыль?

> Дык просим в студию... простые арифметические выкладки. А там посмотрим,
кто лемминг и где будет пыль.

Вот еще считать. Вот персонал online.de понял. Всего-то надо было, чтобы ими воспользовались хорошенько. А представляешь, что будет с кем-то помельче, если им так же воспользуются ? :-)

AS ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.