Использование блэклистов

[ack]

В последнее время наблюдаю увеличение количества мейл-серверов, на которых настроены блэклисты (CBL, Spamcop, etc).
Не кажется ли уважаемым администраторам этих серверов, что ставить такую важную функцию, как приём писем, в зависимость от сервисов, которыми управляет неизвестно кто и неизвестно с какими целями, немного неправильно?

[visual]

В последнее время наблюдаю увеличение количества мейл-серверов, на которых настроены блэклисты (CBL, Spamcop, etc).
Не кажется ли уважаемым администраторам этих серверов, что ставить такую важную функцию, как приём писем, в зависимость от сервисов, которыми управляет неизвестно кто и неизвестно с какими целями, немного неправильно?

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

[ack]

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

Я не про эффективность, а про те требования, которые они предъявляют к почтовым релеям. Получается так, что выполняя стандарты, я ещё должен выполнять требования владельцев блеклистов, чтобы моя почта доходила к тем, к кому она должна дойти.
Пусть это личное дело администратора - доверять блеклистам или нет. Пусть он свою личную почту блеклистит.
Почему должны страдать остальные пользователи почтовой системы?

[SlyF0X]

Я не про эффективность, а про те требования, которые они предъявляют к почтовым релеям. Получается так, что выполняя стандарты, я ещё должен выполнять требования владельцев блеклистов, чтобы моя почта доходила к тем, к кому она должна дойти.
Пусть это личное дело администратора - доверять блеклистам или нет. Пусть он свою личную почту блеклистит.
Почему должны страдать остальные пользователи почтовой системы?

Требования к почтовым релеем у них самые нормальные и случайно в списки блэк-листов не попадают.
А только в случае спам рассылки, рассылки вирусов или открытого релея и блек-листы в этом случае косвенно помогают боротся со всей против распростронения всей этой "нечести" методом "естественного отбора".
А остальные пользователи почтовой системы которая "попала" страдают не от блек-листов , а от спама вирусов и кривых рук администратора.
Такова уж реальность текущего положения дел в электронной почте что объем нежелательной почты если не превышает то уж точно сопастовим с объемом полезных писем, и это еще при том что против "спамеров" борятся всеми возможными способами. Очевидно что протокол SMTP разработанный в начале 80-х уже сейчас совершенно не адекватен и мне кажется уже скоро назреет тот критический момент когда пользоватся им будут в основном только для рассылки спама и вирусов.

[ack]

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

Если бы только.
На самом деле не так. Один из моих серверов постоянно попадает в блэклист, хотя он не открытый релей и не спам-сервер. Единственная возможность, которую я вижу чтобы мой сервер не попадал в блэклист - это отключение отсылки сообщений о недоставке почты вообще. Т.е. я должен в нарушение RFC резать все автоматические ответы - это рекомендуют владельцы блэклистов ( http://spamcop.net/fom-serve/cache/329.html ). А то, что пользователь не будет знать когда сообщение доходит до адресата, а когда - нет, это владельцев блэклистов не волнует.
По моему мнению, использование блэклистов - это моветон, который говорит о том, что администратор не способен бороться со спамом более адекватными способами.

[AdVv]

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

Согласно статистике спам составляет около 90% от общего почтового траффика ;(

[never hood]

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

Совершенно правильная рекомендация. Она обсуждалась милллионы раз.
Совершенно неоправданно отвечать об ошибке нелегитимному отправителю (такому как спам-робот или вирус) иначе количество сообщений об ошибках может возрасти многократно. Как админ (а я полагаю это так) вы должны себе это ясно представлять. Нарушение старого RFC в данном случае есть требование современных реалий и оно совершенно не вредит нормальной почте.
В протоколе SMTP есть масса возможностей, которые на сегодняшний день не используются именно по причине их опасности с точки зрения спам-атак. Именно такими ограничениями и расширениями и происходит эволюция данного сервиса.
Скажу более, отсеивание спама по блэк-листам необходимо, но даже его не достаточно. Поэтому реальный сервер в дополнение к блэклистингу применяет еще несолько способов отсеивания спама (грейлистинг и пр.).

[ack]

Совершенно правильная рекомендация. Она обсуждалась милллионы раз.

Совершенно правильных рекомендаций не бывает.
И у данной рекомендации есть свои недостатки.
Приведу пример. Положим, в организации есть центральный SMTP-сервер, который не раскладывает почту в локальные папочки пользователей, а пересылает её другим серверам. Естественно, центральный сервер как правило не знает какой из пользователей есть на каждом из нижестоящих серверов, не знает переполнен ли ящик пользователя и вообще не в курсе что нижестоящий сервер намерен с этим письмом сделать. Т.е. в процессе приёма сообщения центральный сервер не может обнаружить и обработать ошибку, как это требуют владельцы блеклистов. Положим, нижестоящий сервер обнаруживает ошибку "пользователь не зарегистрирован" и отвечает центральному "550 ...". И что в этой ситуации может сделать центральный сервер. Сообщить об ошибке отправитель необходимо, это не только требование RFC, это ещё и требование здравого смысла. А как? Связь с отправителем уже потеряна. Следовательно, единственный способ в данной ситуации сообщить об ошибке отправителю - это письмо от MAILER-DAEMON.

Совершенно неоправданно отвечать об ошибке нелегитимному отправителю (такому как спам-робот или вирус) иначе количество сообщений об ошибках может возрасти многократно. Как админ (а я полагаю это так) вы должны себе это ясно представлять.

Как узнать, что оправитель нелегитимный? Поделитесь секретом.

Нарушение старого RFC в данном случае есть требование современных реалий и оно совершенно не вредит нормальной почте.

РФЦ от старости актуальность не теряет. Пока ещё нет нового стандарта...

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

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

[never hood]

Совершенно правильных рекомендаций не бывает.
И у данной рекомендации есть свои недостатки.
Приведу пример. Положим, в организации есть центральный SMTP-сервер, который не раскладывает почту в локальные папочки пользователей, а пересылает её другим серверам. Естественно, центральный сервер как правило не знает какой из пользователей есть на каждом из нижестоящих серверов, не знает переполнен ли ящик пользователя и вообще не в курсе что нижестоящий сервер намерен с этим письмом сделать.

Внедрите в вашей организации LDAP-каталог и пусть ваши сервера (как это необходимо) имеют информацию о наличии пользователей, их блокированности, заполненности ящиков и т.д.
Отсутствие данного механизма - не недостаток SMTP, а недоработка админа (или архитектора системы).

Как узнать, что оправитель нелегитимный? Поделитесь секретом.

Так, как это делают сервера в настоящее время. При приеме письма, на этапе получения адреса отправителя сервер инициирует "отправку" письма отправителю и если удаленный сервер согласится принимать такое "письмо", то данный сеанс заканчивается, а первый продолжается.
Не сложно, но весьма эффективно.

РФЦ от старости актуальность не теряет. Пока ещё нет нового стандарта...

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

Грейлистинг - ваще чудо. Особенно некоторые его воплощения. Не спорю, что для некоторых может даже грейлистинг - это нормально. Но ставить его на корпоративные мейл-серверы - это насколько надо ненавидить клиентов фирмы?

Ни один способ фильтрации - не догма и должен применяться с учетом условий внедрения.
Для кого-то грейлистинг - благо, для кого-то - помеха. Всему есть цена, можно оплачивать время ожидания, а можно время чистки ящиков от мусора...

Единственная адекватная защита от спама - это фильтры. Тем более что есть бесплатные, которые при должной настройке отсеивают большой процент спама.

Ну, так все о чем мы с вами толкуем и есть фильтры!
Ни блэклистинг, ни грейлистинг не есть компонент почтового протокола, это дополнительные надстройки сервера. Это и есть фильтры. Их действительно много. Выбирайте сообразно вашим обстоятельствам и требованиям.
Оценивайте и делитесь здесь своим опытом!

[ack]

Внедрите в вашей организации LDAP-каталог и пусть ваши сервера (как это необходимо) имеют информацию о наличии пользователей, их блокированности, заполненности ящиков и т.д.
Отсутствие данного механизма - не недостаток SMTP, а недоработка админа (или архитектора системы).

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

Так, как это делают сервера в настоящее время. При приеме письма, на этапе получения адреса отправителя сервер инициирует "отправку" письма отправителю и если удаленный сервер согласится принимать такое "письмо", то данный сеанс заканчивается, а первый продолжается.
Не сложно, но весьма эффективно.

Сомневаюсь в эффективности. Не вижу никаких препятствий для спаммеров в отправке положительного ответа на попытку передать письмо. К тому же даже легальный релей не обязан пересылать письма в обратном направлении.

Жизнь многообразнее. Даже если нет нового стандарта есть старый с комплектом поправок и рекомендаций.
В конце концов, вас никто не заставляет не следовать стандарту!

Лучше смтп пока ничего не придумано. Несмотря на всю его ублюдочность. Есть несколько официальных предложений по его улучшению. Блэклисты в чисоло официальных улучшений  не входят.

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

Мы говорим о вреде блеклистинга? Тогда при чем тут развитие, гигантские шаги и прочий пафос?

[never hood]

Мы говорим о вреде блеклистинга? Тогда при чем тут развитие, гигантские шаги и прочий пафос?

нет, я (и не только) говорил о его пользе!
Вам хотелось услышать мнение? вы его услышали!
у вас есть что-то конструктивное, что может помочь вам в вашей "тяжелой" ситуации?
если да, реализуйте!
и нечего поднимать пустой флейм. Во все времена проблемы сервера были проблемами его админа.
Ничего не изменилось до сего дня...

Тема закрыта

[ack]

нет, я (и не только) говорил о его пользе!
Вам хотелось услышать мнение? вы его услышали!

Я прежде всего хотел услышать: чем руководствуются админы, выбирая не самый лучший с некоторой точки зрения способ фильтрации спама. Почему именно блеклист? Это лень? Или это настройки по умолчанию MTA, в которых некогда было разбираться?

и нечего поднимать пустой флейм. Во все времена проблемы сервера были проблемами его админа.

ОК. Сформулирую задачу в этом контексте. То, что письма (неспамовые) с одного сервера отвергаются другим сервером по блэклисту - это проблемы первого сервера или второго? Нужен аргументированный ответ.

[visual]

Если бы только.
блэклист - это отключение отсылки сообщений о недоставке почты вообще. Т.е. я должен в нарушение RFC резать все автоматические ответы - это рекомендуют владельцы блэклистов (

если сообщение по какой-то причине не может быть доставлено, например нет такого пользователя, то какого извините хрена слать письмо в обратную сторону, если все можно аккуратно сделать на уровне SMTP сессии, вернув код ошибки? совершенно аналогично с другими причинами недоставки почты, будь то переполнение ящика, или наличие заразы в письме. это головная боль релея отправителя, как-то извещать своего пользователя о невозможности доставки, но никак не твоего релея. пример внутреннего документооборота, который был приведен в качестве примера выглядит странно, если постоянно валятся ошибки из-за неправильно адресации или переполненности почтового ящика, то это ошибки дизайна системы. про валидацию получателя на нижестоящих по иерархии smtp серверах тебе совершенно правильно сказали, LDAP самое правильное решение. ну а если ящики постоянно забиты, то явно сайзинг системы был плохо сделан.

[visual]

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

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

ОК. Сформулирую задачу в этом контексте. То, что письма (неспамовые) с одного сервера отвергаются другим сервером по блэклисту - это проблемы первого сервера или второго? Нужен аргументированный ответ.

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

[ack]

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

Понял, согласен.

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

На счёт "пара-тройка" раз - это только официальная статистика по самым известным почтовым сервисам.
Эффективность оценивается не только по количеству отфильтрованного спама, но ещё и по количеству ложных срабатываний. В последнем блэклисты впереди планеты всей, т.к. они действуют по принципу военного хирурга: если где-то болит, это "где-то" надо ампутировать. Любая вшивенькая районная сетка, через релей которой были прокачаны тонны спама, занесётся в блеклист. Соответственно, ни один обычный пользователь этой сетки в течение некоторого времени не сможет отправить своё письмо на тот сервер, где настроен блеклист. Скажите, разве это не ложное срабатывание? Ведь пользователь не шлёт спам.
Используя блеклисты, админ ставит свой сервер в зависимость от внешнего сервиса, следовательно увеличивает риск атаки на отказ в обслуживании, т.к. внешний сервис курируют совершенно чужие люди, и невозможно предугадать что им в следующий момент придёт в голову. Прецеденты были.

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

Согласен.

[never hood]

Любая вшивенькая районная сетка, через релей которой были прокачаны тонны спама, занесётся в блеклист.

И это есть веская причина справедливого попадания в блэклит. И это не ложное срабатывание!

Соответственно, ни один обычный пользователь этой сетки в течение некоторого времени не сможет отправить своё письмо на тот сервер, где настроен блеклист. Скажите, разве это не ложное срабатывание? Ведь пользователь не шлёт спам.

Может он и не шлет спам, но админ у него - полный @#$%^! И его решение проблемы должно быть - сменить админа, если через администрируемый этим "товарисчем" сервер прошли тонны спама,  а тот пеняет на блэклисты!

Используя блеклисты, админ ставит свой сервер в зависимость от внешнего сервиса, следовательно увеличивает риск атаки на отказ в обслуживании, т.к. внешний сервис курируют совершенно чужие люди, и невозможно предугадать что им в следующий момент придёт в голову. Прецеденты были.

Значит у вас не было предусмотрено поддержания непрерывности сервиса. То есть, опят-таки, косяк админа. На сервере используется, как правило, не один блэклист (у меня четыре-пять). Для каждого из них определен тайм-аут на сессию и действие в случае недоступности сервера блэклиста. Даже если все блэклисты отомрут, что крайне маловероятно, сервер не будет стоять. Может немного потеряет в производительности, но даже такой потерей производительности он будет защищать своих клиентов от спама (в определенном смысле, конечно).

[ack]

И это есть веская причина справедливого попадания в блэклит. И это не ложное срабатывание!

Нет уж, это именно классический пример ложного срабатывания: система приняла за спам неспамовое сообщение (только потому что оно пришло с определённого ip-адреса).
У вас наверно есть своё определение ошибок первого и второго рода?

Значит у вас не было предусмотрено поддержания непрерывности сервиса. То есть, опят-таки, косяк админа. На сервере используется, как правило, не один блэклист (у меня четыре-пять). Для каждого из них определен тайм-аут на сессию и действие в случае недоступности сервера блэклиста. Даже если все блэклисты отомрут, что крайне маловероятно, сервер не будет стоять. Может немного потеряет в производительности, но даже такой потерей производительности он будет защищать своих клиентов от спама (в определенном смысле, конечно).

Если блеклистовый сервис отомрёт - это полбеды. А если он начнёт блокировать нормальные релеи направо и налево? Не буду вдаваться в возможные причины, но, согласитесь, есть такая вероятность.
Т.е. опять имеем классическую угрозу доступности информации, особенно если мэйлсервер отвергает почту на основе блеклиста.

[never hood]

. (жирная точка).
Тема закрыта. Если вы так не считаете, перечитайте все, что вам было сказано.

[ack]

. (жирная точка).
Тема закрыта. Если вы так не считаете, перечитайте все, что вам было сказано

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

[stranger]

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

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

ИМХО, блеклисты очень нехорошее решение, так как все-равно порождает дополнительный трафик на проверку... Более того многие блеклисты начинают зарабатывать за счет того, что в лист попадаешь бесплатно, а чтобы убрать нужны деньги... ИМХО это очень плохой признак...
И не бывает непробиваемых систем, особенно у юзверей - подхватит какой-нибудь комп трояна и все через релей потом прошло... И мне потом нужно будет проверять все блеклисты, занесли мой комп или нет?

Я в своей системе использую трехуровневую защиту... greylisting, clamav и spamassassin... Все достаточно неплохо работает, хотя и тут есть проблемы... И никаких блеклистов... Отсеивает все это достаточно большое количество спама...