LINUX.ORG.RU

SMC-milter обновился до версии 2.1

 , , , ,


0

0

SMC, анти-спам e-mail фильтр, обновился до версии 2.1.

  • Добавлена поддержка SPF (Sender Policy Framework).
  • Исправлена потенциальная ошибка в алгоритме кэширования данных.
  • Добавлена перезагрузка конфигурации по сигналу 1 (SIGHUP).
  • Обновлен загрузочный скрипт для FreeBSD. Алгоритм "NS Relay" переименован в AutoSPF.
  • Устранена незначительная ошибка в коде AutoSPF.
  • Открыт сайт проекта AutoSPF (http://www.autospf.org/).
  • Алгоритм Auto-confirmation переименован в AutoSWL (Auto Sender White List).
  • Устранена критическая ошибка в greylisting-алгоритме фильтра.
  • Добавлен ряд новых опций в конфигурационный файл фильтра.
  • Незначительные изменения в значениях по умолчанию конфигурационного файла.
  • Чистка кода, оптимизация, изменения в документации. Рекомендуется обновление.

>>> Подробности



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

Мда... Теперь новым линуксойдам даже не нужно читать man mount...

Ребят, да мы попсеем!

anonymous
()
Ответ на: комментарий от anonymous

Долбануться, какие сложности!
А вообще, фильтрация по zombile и по grey делает так, что я получаю 3-4 спамерских письма в месяц.... Раньше было по 50-100 в день

anonymous
()
Ответ на: комментарий от anonymous

пипец, этот autospf сопли вообщее...

chocholl ★★
()
Ответ на: комментарий от anonymous

Ложные срабатывания в студию!

> А вообще, фильтрация по zombile и по grey делает так, что я получаю 3-4 спамерских письма в месяц.... Раньше было по 50-100 в день

А сколько человеческих писем не проходит?

Camel ★★★★★
()
Ответ на: комментарий от anonymous

Никаких сложностей. все тот же грейлист, который кстати в фильтре SMC появился раньше, чем разрекламированный и назывался просто - check delays. кое-какие обсуждения на opennet.ru должны были сохраниться еще за те годы. Так вот, изначально, когда мы еще только тестировали этот алгоритм и убеждали всех в том что его работа ничуть не противоречит rfc, стало понятно что в голом виде грейлист неработоспособен - т.е. Важные сообщения могут быть потеряны. Кто-то пошел по пути составления списка серверов, с которыми технология не работает, мы же решили автоматизировать этот процесс. Так появились алгоритмы NS Relay или AutoSPF, Auto-confirmation или AutoSWL, сейчас развивается SPF. Т.е. все эти сложности нужны только для того, что бы уменьшить процент потерь в любом почтовом фильтре. В smc потери практически отсутствуют.

rald
() автор топика
Ответ на: комментарий от rald

>>>Под Fedora 9 уже есть

ага из srpms пакетов собрал себе под Fedora 8. спасибо

anonymous
()

а я думал что smc это Марио обновился;)

papay ★★★
()

Mario не нужен.

anonymous
()

Чем оно лучше spamassassin? Последний работает отлично, после включения razor, pyzor и dcc и нескольких лет bayes-трениновки работает как часы. Тормоз, правда, тот еще..

anonymous
()
Ответ на: комментарий от anonymous

зачем путать эвристику с отлупами по косвенным признакам ?

нет ns-ов, нет MX, не обратной зоны, не вернулся после greylist - все явно указывает на спамера, до эвристики 90% спама не дойдет, что существенно сократит нагрузку на сервер.

anonymous
()
Ответ на: комментарий от anonymous

Кому нужны патенты? Копирайт стоит, лицензия GNU Free Documentation License 1.2. Отправку с родственных сетей в RFC не пропишешь. Единственное, что можно записать в rfc это то, что должна _всегда_ приниматься почта, в отношении которой срабатывает правило "отправитель с адреса somebody@host.name может отправить почту только через почтовый сервер домена host.name, который разрешается через DNS и имеет соответствующую MX запись, которая соответствует IP адресу сервера осуществившему соединение". Ну а если еще записать, что в остальных случаях прием не гарантируется и что при пересылке должны обязательно подменяться атрибуты отправителя - то вообще хорошо будет )) Только реально ли это?

rald
() автор топика
Ответ на: комментарий от rald

Вам не нужны? Не патентуйте :)Алгоритм оригинальный, почему бы и не защитить чуть более серьезно, чем GNU Free Documentation License 1.2.
Это возможные деньги в будущем...
RFC-4408 читали? SPF почти мертвая технология. Слишком сложно и при этом неэффективно. В ближайшем будущем DomainKeys будет лидирующей технологией, имхо:)
Нечто похожее (я про RFC) можно написать и для вашей технологии, чтобы можно было реализовать в других продуктах.

anonymous
()
Ответ на: комментарий от anonymous

Считаю что этот алгоритм решает только вполне конкретную проблему в конкретной ситуации и врядли имеет большое будущее (по крайней мере в таком виде в каком он сейчас). Для реализации в других проектах будет библиотека с лицензией LGPL. Если у вас есть опыт в патентовании и чутье на будущее - можно поработать вместе. Насчет DomainKeys - у меня есть не менее эффективная технология, реализуемая гораздо проще (всего лишь один дополнительный заголовок в письме), но все-таки требуется поддержка в популярных MTA и RFC документ описывающий технологию. В основных чертах думаю опубликовать на сайте autospf.org в течение лета, но вот дальше боюсь, не осилить - присоединяйтесь к проекту если есть желание. Нас вот из портов нагло выкинули с версии 1.8. Патч до 1.9 до сих пор на рассмотрении, а у нас уже версия 2.1. А ты говоришь в RFC вписаться..

rald
() автор топика
Ответ на: комментарий от rald

> Нас вот из портов нагло выкинули с версии 1.8.
С версии 1.6. ;)

Может действительно найдётся портер, который поможет пропихнуть мильтер в порты? На фре всё замечательно работает, поэтому с кодом возиться не нужно.

grepz
()
Ответ на: комментарий от rald

Библиотека под LGPL - это хорошо :)
Ждем с нетерпением :)
Похожая технология, типа адаптированной SPF используется в гугловском антиаспаме.
А вот соревноваться с DomainKeys совсем не просто :)

P.S. В любом случае, удачи вашему проекту. Он - интересный :) Пишите еще :)

anonymous
()
Ответ на: комментарий от anonymous

Кстати, я подобную по смыслу фильтрацию изобрел примерно в том же 2003-м. Работает весьма прилично, спама проползает 1% или около, и то, потому что не все гайки завернуты до упора. Правда, серых списков нет, зато есть список всех основных adsl и прочих broadband провайдеров, с клиентских машин которых и приходит основная масса спам-ботов. И автоматический white-list только в проекте.

К сожалению, до "публичной" версии доделать так и не собрался, а вот хлопцы молодцы, доделали..

anonymous
()
Ответ на: комментарий от anonymous

> В ближайшем будущем DomainKeys будет лидирующей технологией, имхо:)

Мне вот жаль, что MTA Mark умер... А ведь не один draft был на ietf.org... :-(

AS ★★★★★
()
Ответ на: комментарий от AS

MTAMark замечательная технология, а умерла как я думаю из за того, что в этом случае ответственность за некий хост X, получивший MTAMark несет администратор обратной зоны, а должен нести администратор почтового домена (зоны почтового домена), а это как правило совсем другая организация. Т.е нет связи между ip и почтовым доменом. В случае AutoSPF это решается проще - просто прописываете в зоне почтового домена тот сервер, который будет от этого домена почту слать и все )) - он разрешен (если mx - то на первом этапе проверки, если просто хост в зоне - то на второй). Ну и несете ответственность за все, что происходит в зоне почтового домена. Проблему пересылок технология не решает.

rald
() автор топика
Ответ на: комментарий от rald

> должна _всегда_ приниматься почта, в отношении которой срабатывает правило ...

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

AS ★★★★★
()
Ответ на: комментарий от rald

> а это как правило совсем другая организация. Т.е нет связи между ip и почтовым доменом.

Почему нет ? В некотором роде есть. ip же кем-то выдан и этот кто-то, как раз, обратную зону и держит (с большой степенью вероятности). Соответственно, можно сразу разоваривать про ip и MTA Mark в одном флаконе.

AS ★★★★★
()
Ответ на: комментарий от AS

В большинстве случаев ip выдан провайдером, а почтовый домен регистрируем сами. Кстати попробуй на досуге в техподдержку своего провайдера написать - "пожалуйста пропишите мне mtamark 1 в обратной зоне для сервера xxx". Думаю что ответ будет туманный в лучшем случае, а на западе ответ будет однозначный - "необучены, нет такой услуги" ( Кстати как-то в свое время не разобрался зачем нужна марка 0. По моему мнению какое-то недоразумение.

rald
() автор топика
Ответ на: комментарий от AS

...как бы отказывать не начали на обратном правиле...

А чем плохо? Больших неудобств не вижу. TSL авторизация и пиши себе наздоровье со своего сервера. Например на ICQ сервер в израиль коннектишься и не напрягает? Почему обязательно местный сервер нужен? Ширина каналов позволяет видео онлайн смотреть с другого конца материка, что и делают, а (в среднем) несколько десятков байт письмо передать - обязательно локальный smtp подавай ))))

rald
() автор топика
Ответ на: комментарий от rald

* опечатка: вместо TSL читать TLS/SSL )

rald
() автор топика
Ответ на: комментарий от rald

> Кстати попробуй на досуге в техподдержку своего провайдера написать - "пожалуйста пропишите мне mtamark 1 в обратной зоне для сервера xxx".

Это мне самому себе писать надо. :-) Я бы прописал, если бы попросили.

> "необучены, нет такой услуги"

Делаем ноги к другому провайдеру. Хотя, конечно, это не всегда легко.

> Кстати как-то в свое время не разобрался зачем нужна марка 0

на сколько помню, там был вариант, что хост точно не smtp-отправитель.
Видимо это оно. А нужность - мало ли, дополнительная фича не повредит.

AS ★★★★★
()
Ответ на: комментарий от rald

> Например на ICQ сервер в израиль коннектишься и не напрягает ?

Вообще-то напрягает. :-) Но не так чильно - объёмы не те.

> Почему обязательно местный сервер нужен ?

Во-первых, потому, что свой сервер на другом конце шарика может быть, по ряду причин, недоступен (хотя этот аргумент становится менее весомым с учётом применения smtp callback).
Во-вторых, E-Mail в 10-50-100 Мб сейчас не особенно удивителен. У нас некоторые уникумы iso слать почтой пытались одним сообщением.

AS ★★★★★
()
Ответ на: комментарий от AS

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

rald
() автор топика
Ответ на: комментарий от rald

> Для передачи больших файлов есть другие протоколы.

Мне это объяснять не надо, сам могу. :-)

> У меня максимальный размер сообщения выставлен в 8 Мб.

у 8-мегапиксельной камеры картинка 5 с хвостиком мб. А если raw ? Это из бытового.

> Пользователей более 300

300 ещё можно обучить... Особенно, если это сотрудники одной организации. А 30000 ? Нет, у нас поменше, но порядок такой. А аргумент - "мы деньги платим". И, в чём-то, они правы. Приходится искать золотую середину. :-( Ограничение на размер тоже стоит, но существенно больше 8Мб.

Беда в том, что, с подачи одной "любимой" компании, протолкнули рекламную идею о том, что компьютер - бытовая техника. Как теперь привить мысль, что на нём работать надо _учиться_, непонятно... :-(

AS ★★★★★
()
Ответ на: комментарий от AS

>Беда в том, что, с подачи одной "любимой" компании, протолкнули рекламную идею о том, что компьютер - бытовая техника. Как теперь привить мысль, что на нём работать надо _учиться_, непонятно... :-(

Это и правда бытовая техника :)
А что это была за компания?

anonymous
()
Ответ на: комментарий от anonymous

Гы-гы.. а гугловцы autospf.org забанили похоже. Вчера в поиске по autospf было страниц пять сайтов с autospf.org в топе, а сегодня одна страничка и ни одного намека на autospf.org. Не пробиться нам, не пустят. Другой интернет/овернет нужно делать. Кто профинансирует?

anonymous
()
Ответ на: комментарий от anonymous

Хе.. а кто сказал что правила для всех одни? Не вы первые, не вы последние :-)

anonymous
()
Ответ на: комментарий от anonymous

Ага. Точно. Сглазил кто-то )) Если серьезно - то я проверил, продиагностировал гуглом - он не ругается, говорит что ошибок нет и содержание ему нравится, даже sitemap ему скормил. Наверное просто у них что-то глючит )) Не бейте гугл - он хороший.

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