[Карта]                [Начало]                [Sendmail-ссылки]                [Синтаксис]                [Типовые задачки]                  [Задачки по маршрутизации]                  [Задачки по маcкарадингу]                  [SendmailACL]                  [Spamooborona]                  [VadeRetro]                  [Regex]                  [Тонкости]                  [Недок.особен.]                  [Несущ.юзеры]                  [Прячемся!]                  [RFC1893.Цитаты]                  [ТП.Эмоции]                  [Антиспам&Разум]                  [Экзерсисы]                 


Спамооборона: впечатление, проблемы, советы.


  • A.    Другие отзывы о СО.
  • I.    Сезон 2006-2008.
  • II.    Сезон 2009.
  • III.    Сезон 2011-2012.
    Коллеги! Прочтите, пожалуйста, сначала мое обращение к вам.

    Дано: P4/XEON, 2,66GHz, 768 Mb ОЗУ; SUSE10.0; sendmail 8.13.6, 8.14.2; с июля 2006г по июль 2008г. СO 1.5, 1.7, 2.1, лицензия на 400 адресов. C 29.05.2008 2,7 Gb ОЗУ.
    Обращаю ваше внимание, что здесь речь идет о старых версиях СО. Возможно, сейчас ситуация совсем другая.

    Ежедневно antispam-средствами sendmail блокируется 60-160 тыс. соединений. Но все равно проскакивает много спама. Спамооборона позволяет идентифицировать спам и изменить тему письма для последующей фильтрации, например, локальным доставщиком почты или почтовым клиентом пользователя.

    1. Плюсы

    1. Спамооборона действительно распознает спам и помечает тему письма по вашему желанию. Вес письма можно добавлять к спам-метке темы.
    В настоящее время ежедневно спам-меткой помечается в среднем 3000 писем (от 2т до 5т). 70-80% спама имеет большой вес и поэтому уничтожается.
    До подключения дополнительных dnsbl-баз спам-меткой помечалось от 3000 до 13000 писем, в среднем 7т. ежедневно.
    За ноябрь 2007г. в наш наиболее "засвеченный" адм-ящик пришло 115 писем, распознанных СО как спам, 24 спам-письма не были распознаны при пониженном до 7 баллов весе (по умолчанию - 9). К сожалению, посчитать, сколько спам-писем для adm было уничтожено, невозможно.
    Статистика за февраль 2008г. Ежедневно
    - антиспам-средствами sendmail блокировалось 40-80т. соединений;
    - помечалось меткой спам в среднем 3-5т писем (от 2 до 9 тысяч);
    - уничтожалось (спам-вес письма набирал больше 40 баллов)в среднем 4-5 тысяч писем (от 2 до 9 тысяч).
    Февраль. Ящик adm. 173 сообщения. Из них 132 - спам. 25 пропусков спама.
    Март. 471 - 112 - 16
    Апрель. 194 - 161 - 17
    Май. 149 - 118 - 12
    Июнь. 330 - 291 - 10
    Июль. 40 - 30 - 6.

    14.05.2008. По истечении почти двух лет могу сказать, что качество фильтрации хорошее.
    Правда, есть два маленьких пунктика по наблюдениям за моей почтой:
    1) особое доверие СО питает к почте, перенаправляемой с моих mail.ru-ящиков, поэтому где-то около половины пропущенного спама в моем почтовом ящике имеет mail.ru-происхождение;
    2) дорогие коллеги, ваши сообщения, которые я прошу помечать словом "Sendmail", частенько оказываются помеченными СО спам-меткой ;), но это не беда, ведь я принимаю всю спам-почту. Видимо, сказывается наличие логов и фрагментов спам-писем в теле письма.

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

    3. Если спам-вес письма превышает определенное значение, которое можно изменять, то такое письмо можно либо отвергнуть, либо тихо уничтожить.
    Можно назначить индивидуальный пороговый вес для пользователя. Для меня это большой полюс, потому что из всех пользователей, которых обслуживает СО, около 30 человек пожелали установить личные пороги отказа (от 15 до 30), для остальных же действует значение по умолчанию (45).
    Стандартный набор (белый список, списки исключений общие и индивидуальные, etc) прилагается.

    4. В случае рассылки Спамооборона пишет в лог полный список получателей отдельной строкой spamstop'a, не ограничиваясь лаконичным "to rcpts", как это делает антивирус ДрВеб. (Да-да, я помню, что речь идет об антиспаме; но в данном пункте я всего лишь хочу указать, что для любого фильтра это плюс). Это облегчает составление отчетов пользователям.

    5. Начиная с версии 2.1 появилась возможность пропускать письмо без проверки при сбоях sp-daemon, за включение этой важной опции отвечает параметр
    general.accept_failures: 0 (отклонять), 1 (пропускать).

    6. Админам, внушающим доверие, раскрывается пара дполнительных (очень, очень и очень полезных) фич.
    Чтобы вы не подумали, что я отношусь к этой группе, скажу сразу, что узнала об этом случайно и сама ими не пользуюсь.
    Но, поверьте, фишки очень и очень нужные, важные, полезные.

    2. Минусы.

    2.1. Списки рассылок, все участники которых уже находятся в списке проверяемых пользователей, должны также быть прописаны. А это сокращает количество обрабатываемых адресов. Средствами sendmail.cf вы можете сделать списки рассылок доступными только для определенных пользователей. Но, если на этот адрес должна поступать почта без ограничений, например, если это (adm|noc|abuse|(post|host|web)master)@yourdomain.ru, то придется прописывать все в /var/yamail/mailboxes.
    31.03.2008. Нашлось решение. Но не проверялось.

    2.3. Пропуск без проверки писем, отправители которых перечислены в белом списке, не предусмотрен. СО все равно проверит письмо, просто вычтет из веса письма определенное значение (которое можно изменять). Таким образом, вес письма будет снижен, и оно не сможет попасть в разряд спама. То есть избавить СО от лишней работы не удастся.

    В этой ситуации остается попросить sendmail обходить фильтр при определенных условиях.
    Как оказалось, на sendmail-конфе это довольно распространенный вопрос.
    И хотя Claus Assmann отвечает, что это дело самого почтового фильтра, кое-какие решения все-таки имеются.

    Во-первых, это патч к sendmail milter-rrres Joe Maimon :
    "...Some of the highlights include milter lookup access for sendmail testmode, ruleset processing of milter command responses, libmilter thread locking for lookup access, more rulesets to control lookup request and more macros set for use of these rulesets. All the details, which includes much more, can be found in the Changes file..."
    README:
    "... You can configure rulesets to be evaluated by sendmail for different actions before sendmail sends the commands to the milter.
    If the ruleset resolves to $#discard or $#error, then sendmail will not send the milter command. Certain failures will also trigger sendmail to shut down processing of the milter for this message/connection, such as a lack of recipients, no mail from, connect denied and so on so forth.
    As a special case to this, resolving to $#abort will cause sendmail to cease milter processing for the duration of the message/connection, whichever it is in at the time.
    If the ruleset resolves to $#ok or anything other than mentioned previously, the command is sent to the milter. Currently, changing the data sent to the milter is not available. That might change. Make it a habit to finish the ruleset with what you were given, if you are not resolving to any of the mailers. ..."

    Кроме того есть патч к libmilter Дениса Еременко:
    "...but i want to skip spam checking by regular expressions of networks and domains. I extended sendmail and libmilter for extra command - "skip filter". The idea: milter checks controlled by some external filter which could command to skip any specific milter going after himself. Patch quite rough, but works fine for a month (avg load: about 0.5 msg/min on 2xPPro with 320M RAM). SPAM checker is amavisd-new+spamassassin ...".

    10.04.2009. Оказывается, есть замечательное решение - milter manager. Спасибо за новость, за ссылку и подробности to Павлу_из_инд_домена. У него это реально работает! Не нужно кланяться ТП! Еще одна степень свободы от ТП!

    30.03.2010. Решение для Postfix Источник ссылки - здесь.

    Пока не использую ни одно из этих решений. Мой белый список невелик. Но, если он разрастется, придется попробовать.
    Ссылки по теме "How to bypass milter...":
    [1]
    [2]
    [3]
    [4]
    [5]. 12.11.2008. Еще вопрос на эту же тему.
    >Does exist a more intelligent way in order to differentiate the e-mail flow to the milter (based on the destination address) using only a sendmail process?
    На что гуру Per Hedeland отвечает:
    Let the milter make the decision - i.e. have it tell sendmail that it "accepts" the message as soon as it has received enough info to determine that it shouldn't do any processing.
    [6]. 05.09.2009. Avoid processing invalid email addresses in milter?


    2.4. Список почтовых ящиков, которые должны проверятся СО, привязан к почтовому домену.
    То есть, если у вас почтовый сервер - mail.somedomain.ru, с ip-адресом 1.2.3.4, почтовый домен somedomain.ru, а в /var/yamail/mailboxes прописаны адреса вида:
    user1@somedomain.ru
    user2@somedomain.ru
    user3@somedomain.ru
    user4@somedomain.ru
    ....
    то почта для
    user1@mail.somedomain.ru,
    user1@[1.2.3.4], проверяться уже не будет, хотя все эти адреса (в моей конфигурации) есть не что иное, как user1@somedomain.ru

    В этом случае нужно будет добавить пару правил в конфиг
    Данные правила разрешат принимать почту на локальные домены mail.somedomain.ru & [1.2.3.4] только некоторым пользователям. Следует иметь в виду, что СО обрабатывать эти письма уже не будет.
    11.01.2008. Оказывается, из этого факта можно извлечь немножечко пользы для себя.
    16.02.2009. Пока искала решение одной ооочень интересной задачки, наткнулась на такое решение этой проблемы. Для себя отметила, что, во-первых, этот тред был создан в 2006г. почти за 2 месяца до того, как я начала пользоваться СО и столкнулась с этой же проблемой, а во-вторых, никто из гуру не ответил в стиле "с трудом представляю, кому и для чего это может быть нужно". Приятно иметь дело с людьми, которые представляют работу сисадма не понаслышке, которые стараются понять и принять ситуацию "как есть", и для которых нестандартность задачи - не повод для отказа от поиска решения. Да и вообще по жизни приятно иметь дело с генераторами идей.
    Итак, с первых же слов автора мне стало сразу ясно о каком "commercial antispam" идет речь. В обсуждении приняли участие 3 sendmail-гуру: Per Hedeland, Joe Maimon & Jose Marcio Martins da Cruz.
    Было предложено 4 решения.
    1. Отвергать почту для синонимов почтового домена - отметено автором сразу, по причине большой распространенности адресов обоих типов и участия этих адресов в многих рассылках, когда анализ mail-роботом ответа почтовика автора невозможен. Я бы от себя еще добавила, что и то, и другое есть следствие солидного возраста домена.
    2. Завести два sendmail'a на разных IP на одном сервере. Разобраться с mx-записями каждого домена (mail.anrb.ru & anrb.ru). Выбрать один из доменов основным (f.e., anrb.ru), установить именно на этот сервер СО, и именно его адреса указать Спамообороне в качестве обслуживаемых. Почту для второго домена (mail.anrb.ru) со второго сервера через virtusertable заруливать на первый сервер+CO, попутно изменяя домен адреса на anrb.ru. Как сказал Per Hedeland - это "extra ugly". От себя добавлю, что два sendmail'a на одном сервере - это хорошо, когда это действительно необходимо.
    3. Per Hedeland: "... You could conceivably do it all in one sendmail instance, and have it send the rewritten recipient back to "itself", if instead of virtusertable you used someing like:
    MODIFY_MAILER_FLAGS(`SMTP', `+k')
    LOCAL_RULE_0
    R$+<@mail.mydomain.com.>                 $#smtp $@ [127.0.0.1] $: $1<@mydomain.com.>
    It would get sent to the milter in both rounds of course - but the milter getting the u...@mail.mydomain.com addresses in the first round shouldn't be a problem, since they will not cause scanning. The bad case would be if you had a mixture of u...@mydomain.com and u...@mail.mydomain.com recipients for a single message, which would cause the message to be scanned twice (in the first round for the "original" u...@mydomain.com, in the second round for the u...@mail.mydomain.com rewritten to u...@mydomain.com). But maybe this would be very unusual ..."
    Итак, Per Hedeland предлагает менять маршрут почты, если в домене получателя указано mail.mydomain.com, отправляя ее этому же серверу ([127.0.0.1]), тому же получателю, но только домену-синониму (mydomain.com.)
    Минус в том, что, если в получателях будут значится и user@mail.mydomain.com, и user@mydomain.com, то письмо будет обработано СО дважды. Но это уже не смертельно.
    Еще один минус, уже серьезный - в error bounce messages, так в случае отказа от сообщения milter'ом забота о доставке сообщения отправителю ложится на плечи сервера-отправителя. В случае с 2 sendmail'ами отказ Спамообороной письму, пришедшему по правилу R$+<@mail.mydomain.com.>                 $#smtp $@ [127.0.0.1] $: $1<@mydomain.com.>
    приведет к формированию error bounce message на сервере автора с последующей отправкой этого сообщения исходному отправителю, которого может в природе не существовать, а это в свою очередь вызовет DoubleBounce.
    Кстати, сам автор тоже сделал важную ремарку, заменив [127.0.0.1] на [127.0.0.2], ведь СО не проверяет почту от localhost.
    4. Joe Maimon предложил свой патч milter-rrres.

    03.12.2009. Оказывается, не одну меня эта ситуация с алиасами и доменами напрягает.

    2.5. Время отклика тех.поддержки неоправданно велико. А часть моих сообщений и вовсе была проигнорирована.
    (Кстати, вирт. открытки к праздникам приходят с завидной регулярностью и вовремя :), эх, если бы еще и на вопросы так же отвечали!)
    Форума нет. Для чего он нужен? А хотя бы для того, чтобы в период супер-занятости тех. поддержки получить долгожданный ответ от доброй-души-коллеги-админа, который с описываемой проблемой сталкивался, знает как ее решить и, самое главное, имеет время и желание поделиться решением.

    3. Проблемы.

    3.1. Самоостановы.
    В предыдущих версиях СО случались самоостановы демона и самопроизвольные отказы в приеме почты sp-milter'ом.
    Иногда в случае с sp-daemon и почти всегда в отношении sp-milter это было связано с большой нагрузкой на почтовый сервер.
    С весны по зиму 2007г. эта проблема выпила немало моей кровушки, отняла немеренно сил и времени, etc ...

    Сейчас "посыпаю голову пеплом", потому что тогда я совсем упустила из виду, что средствами sendmail в определении milter можно опустить флаг F=T(или R), велев таким образом sendmail спокойно пропускать почту, когда с фильтром творится что-то неладное.
    op.me:
    "... The following flags may be set in the filter description.
         R     Reject connection if filter unavailable
         T     Temporary fail connection if filter unavailable
    If neither F=R nor F=T is specified, the message is passed through sendmail
    in case of filter errors as if the failing filters were not present..."
    У меня же был установлен флаг F=T, который при сбоях sp-milter'a отвергал почту со статусом "stat=Please try again later."
    Конечно же, беспрепятственный пропуск почты при отсутствующем флаге F привел бы к получению спама пользователями, но в любом случае это было бы лучше, нежели отказ почтовика принять почту по причине сбоя Спамообороны.
    Как я уже отметила в п.1.5 в последних версиях СО возможен пропуск почты и при сбоях демона sp-daemon.

    Так как у меня нет возможности фильтровать трафик на внешнем шлюзе, то я пыталась снизить нагрузку на сервер следующими мерами на самом почтовике:
  • средствами sendmail
    - FEATURE(`ratecontrol') - ограничение кол-ва соединений с одного ip за определенный промежуток времени;
    - FEATURE(`conncontrol') - ограничение одновременных соединений с одного ip;
    - FEATURE(`greet_pause',`3000') - требование выжидания паузы ;
  • средствами iptables
    - connlimit из пакета patch-o-matic-ng-20070605, позволяющий ограничивать количество одновременных соединений;
    - отслеживание постоянно висящих соединений с последующим блокированием ip.
    Кроме того почтовик был переведен на более мощный комп и был запущен третий mx.

    Но снизить почтовую нагрузку до уровня, который был бы по силам CO, удалось лишь после подключения 6 дополнительных dnsbl-баз либо после сокращения в 4 раза списка обслуживаемых адресов.
    При всем неодназначном отношении к "черным базам" спамеров, в моем случае это оказалось единственным спасением. Правда, вскоре выснилось, что все dial-up-адреса местных провайдеров находятся в этих базах.
    Я уже обдумывала возможность переделки одного из дополнительных mx-ов под sendmail-шлюз, который блокировал бы спам, различимый самим sendmail, и затем передавал бы на основной сервер значительно "просеянную" почту для обработки Спамообороной.
    Но решила сначала попробовать новую версию СО 2.1, третью для меня.

    На сегодняшний день (c 24 декабря 2007г.) установлена CO версии 2.1, и при значении в spam.ini general.threads=30 СО справляется с почтовой нагрузкой даже при почти полном отключении antispam-features sendmail'a.
    При этом максимальное значение nThreads за это время составило 12.

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

    04.02.2008. Дождалась. Трафик почти вернулся к предновогодним значениям, а вместе с ним вернулись и проблемы.
    Снова "здравствуйте, здравствуйте, здравствуйте вам" самоостановы демона и мильтера!
    Стало быть без ежеминутного скрипта, который проверяет в ps наличие sp-daemon & sp-milter, в этой жизни никак нельзя.
    В логах наблюдаю возросшие значения nThreads, максимальное значение составило 30. Поэтому количество тредов увеличено до 40.
    Ну и вернула в конфиг старый добрый dnsbl:
    FEATURE(`dnsbl',`bl.spamcop.net', `Spam blocked see: http://spamcop.net/bl.shtml?$&{client_addr}')
    FEATURE(`dnsbl',`list.dsbl.org', `Spam blocked (list) - see http://www.dsbl.org/')
    С этими базами практически не случается ложных срабатываний.
    И следует признаться, что терпение у меня почти иссякло. Прихожу к мысли, что нужно оставить все "как есть" и воспринимать эту проблему как неизбежное бесплатное приложение к Спамообороне.

    16.05.2008. === Вот тоже интересный вопрос: обнаружил скрипт отсутствие демона или мильтера в списке запущенных процессов, а что дальше делать? Стартовать демон/мильтер заново? А зачем? Затем, чтобы через 10 секунд снова случился самоостанов? Ведь причина самоостанова (возросший трафик) не устранена. Значит, сначала нужно уменьшить нагрузку, а потом запускать СО. Почтовую нагрузку я могу уменьшить только с помощью многочисленных dnsbl-баз. Значит скрипт, обнаружив самоостанов, должен сначала добавить в конфиг sendmail дополнительные dnsbl-базы, пересобрать конфиг, рестартовать sendmail, а затем только поднимать Спамооборону. ===

    3.2. Проблема с созданием тредов: thread_create() failed: 11, try again

    Ко всему прочему во время увеличения нагрузки на почтовик добавилась вот такая петрушка
    Feb 1 14:48:19 mail sp-milter[25183]: sp-milter: thread_create() failed: 11, try again
    Feb 1 14:48:20 mail sendmail[18466]: m119mJNN018466: Milter (sp-milter): to error state
    При этом письмо возвращается отправителю с собщением:
    ----- The following addresses had permanent fatal errors -----
    < paradise@anrb.ru >
           (reason: 554 mail.anrb.ru ESMTP not accepting messages)
    И кстати, здесь совсем не спасает ни general.accept_failures в spam.ini, ни отсутствие флага F= в строке определения фильтра в sendmail.mc.
    Опять сочиняю ежеминутный скрипт: если подобных записей за последнюю минуту больше 4, то пересобираем sendmail с включенными проверками ip источника письма в дополнительных dnsbl-базах (чтобы до sp-milter доходило поменьше почты).

    20.02.2008. Аналогичные проблемы во время пиковых нагрузок испытывает и DrWeb:
    Feb 20 17:23:06 mail drweb-smf[32127]: Dr.Web (R) Filter for sendmail ver.4.33: thread_create() failed: 11, try again
    В FAQ'е DrWeb'a я обнаружила такое объяснение похожей проблемы (все ж таки ребята молодцы, а точнее, Сергей Ахапкин большой молодец: и проблему описал, и решение не поленился-нашел :)
    "... Причина может быть в libmilter (написанной авторами sendmail). Обычно это происходит в момент, когда сервер начинает испытывать нагрузки, тогда в системных логах могут появляться сообщения вида:
    Nov 20 19:54:09 name drweb-smf: Dr.WEB Sendmail filter VER: malloc(ctx) failed (12), abort
    или
    Nov 20 19:54:09 name drweb-smf: Dr.WEB Sendmail filter VER: thread_create() failed: 11, abort
    Начиная с версии 4.30.1 мы используем модифицированную версию libmilter, а также поставляем патч для оригинальной версии sendmail-8.12.9. По-другому эту проблему, к сожалению, решить никак нельзя..."
    Действительно, в ../drweb/doc/sendmail имеется 2 патча: listener.patch (к libmilter) и патч к sendmail.
    Но все же эта ошибка имеет отношение к немного другой проблеме.

    Я же поискала по инету и обнаружила рекомендации увеличить количество открытых файловых дескрипторов. Пока экспериментирую с limit'ами, а там посмотрим ...
    Ссылки по теме:
    [1] "... libmilter checks if there is no more file descriptors available and exits after some number of errors ..."
    [2] "... If, under heavy strain on Linux, you see the message thread_create() failed: 12, abort appearing in a log file, you will need to increase the number of threads on your system (/proc/sys/kernel/threads-max), or decrease the value of --max-children. ..."
    [3]
    [4]
    [5]
    [5] DrWEb FAQ Сорри, ссылка не работает, как-нибудь найду источник.
    [6] Как удалось справиться с проблемой тредов в случае с VadeRetro
    [7] Как удалось справиться с проблемой тредов в случае с Kaspersky Antispam
    [8] Есть мнение, что частично облегчить жизнь sendmail'a при больших нагрузках позволяет уменьшение таймаута define(`confTO_COMMAND', `5m'). Значение по умолчанию - 30. А это означает, что sendmail должен ждать следующей команды от передающего сервера в течение 30 минут. Многовато для нагруженного сервера. Достаточно сделать netstat -na на таком сервере, чтобы ужаснуться количеству коннектов.
    [9] И еще есть мнение, что возможно эту проблему вызывает неграмотная сборка ядра. А я, признаюсь, как раз сама ядро собираю ... То есть, вот как разработчики данного дистрибутива ядро собрали, вот таким его и надо использовать.

    NB! 04.02.2009. Может, вам будет не так грустно, если я скажу, что судя по логам, на мои страницы СО или VR ежедневно попадают с поисковых серверов по запросу thread_create() failed в сочетании с другими фильтрами: spamassassin, greylist, etc...

    29.02.2008. Пока ничего не предпринимала, потому что подключила две ([1],[2]) новые проверки в sendmail.cf, и почтовая нагрузка сильно уменьшилась, а с уменьшением нагрузки пока пропала проблема с созданием тредов. Но, конечно, ничего вечного не бывает: скоро спамеры перестроятся, и мои проверки станут бесполезными, поэтому что-то предпринять все-равно придется.

    3.3. Отсутствие номера sendmail-процесса в строках, заполняемых СО.

    В отличие от ДрВеба СО не утруждает себя написанием номера sendmail-процесса, к которому ее записи имеют отношение.
    Это очень напрягает при разборе проблемных ситуаций и при составлении отчетов пользователям. При большом трафике "отделить мух от котлет" невозможно.
    При небольшой почтовой нагрузке запись в лог идет последовательно, сообщения, имеющие отношение к одному и тому же процессу, расположены компактно: пришло письмо - в лог записалось последовательно 16 строк.
    Версия 1.7:
    Dec 14 16:17:44 mail sendmail[20856]: lBEBHL7E020856: from=<egq@actv.ne.jp>, size=5860, class=0, nrcpts=3, msgid=<017401c75f1c$757e5450$1e01a8c0@actv.ne.jp>, proto=SMTP, daemon=MTA, relay=c14-190.actv.ne.jp [210.143.31.190]
    Dec 14 16:17:44 mail drweb-smf[20898]: [lBEBHL7E020856]: scan: the message(drweb.tmp.vmsduH) sent by egq@actv.ne.jp to rcpts is passed
    Dec 14 16:17:44 mail drweb-smf[20898]: [lBEBHL7E020856]: processing message from egq@actv.ne.jp is over
    Dec 14 16:17:44 mail sendmail[20856]: lBEBHL7E020856: Milter add: header: X-Antivirus: Dr.Web (R) for Mail Servers on mail host
    Dec 14 16:17:44 mail sendmail[20856]: lBEBHL7E020856: Milter add: header: X-Antivirus-Code: 100000
    Dec 14 16:17:44 mail spamstop[21106]: MESS_F [44932] <paradise@anrb.ru>;<consiglio@anrb.ru>;<gatling@anrb.ru>:<017401c75f1c$757e5450$1e01a8c0@actv.ne.jp>
    Dec 14 16:17:44 mail spamstop[21106]: MESS_F C 75 200 OK sh=get? [skip]
    Dec 14 16:17:44 mail spamstop[21106]: MESS_F C 86 200 OK sh=put? [skip]
    Dec 14 16:17:44 mail spamstop[21106]: MESS_F X-Spam-Status: Yes, hits=36.0 dlvr_hits=5.5 (7.0 9.0) _21106_ <paradise@anrb.ru>;<consiglio@anrb.ru>;<gatling@anrb.ru>:<017401c75f1c$757e5450$1e01a8c0@actv.ne.jp>test= [skip]
    Dec 14 16:17:44 mail spamstop[21106]: (spamstop time) took 0.255518 sec, 0.020000 CPU sec.
    Dec 14 16:17:44 mail spamstop[21106]: launch took 0.001620 sec, thread took 0.256540 sec. nThreads=1
    Dec 14 16:17:44 mail sendmail[20856]: lBEBHL7E020856: Milter change: header Subject: from =?koi8-r?B?4fLl7uThIO/m6fPv9w==?= to [SPAM:: 36.00] =?koi8-r?B?4fLl7uThIO/m6fPv9w==?=
    Dec 14 16:17:44 mail sendmail[20856]: lBEBHL7E020856: Milter add: header: X-Spam-Flag: YES
    Dec 14 16:17:44 mail sendmail[20856]: lBEBHL7E020856: Milter add: header: X-Spam-Yversion: Spamooborona 1.7.0
    Dec 14 16:17:44 mail sendmail[20856]: lBEBHL7E020856: Milter: data, discard
    Dec 14 16:17:44 mail sendmail[20856]: lBEBHL7E020856: discarded

    А в час пик данные одновременно обслуживаемых процессов перемешаны.
    На основании каких данных можно определить sendmail-процесс, к которому имеют отношение записи spamstop'a?
    Сначала я брала первую после записи from= запись spamstop'a (а именно в ней перечислены все получатели письма), как бы далеко от первой записи sendmail'a она не находилась. Но, оказалось, что в таком случае она не обязательно имеет отношение к интересующему меня sendmail-процессу. Она вполне может быть порождена другим, более поздним, процессом.
    Тогда я попробовала ориентироваться по полю msgid=<.+@.+>, так как он повторяется в строке Спамообороны. Но и тут оказалось, что иногда СО msgid не пишет вовсе. Есть предположение, что это связано с отсутствием поля msgid в таких письмах.
    Пока не доходят руки с этим разобраться окончательно. И пока нет никаких мыслей по поводу, как все-таки правильно определять, к какому sendmail-процессу имеет отношение записи СО.Будем думать дальше.

    04.02.2008.
    Поскольку в версии 2.1 не наблюдается пустых msgid, то теперь отчеты по уничтоженной СО почте составляются следующим образом:
    1. Собираются в отдельный файл записи вида spamstop.+< someuser@anrb.ru >< msgid > (поиск осуществляется именно по пользователю someuser, а не по discard'ам СО, потому что за сутки может набежать до 10 тысяч отказов, при этом на данного пользователя может прийтись не более 5 отказов).
    2. Затем из него вырезаются все msgid и по ним происходит поиск записей sendmail'a в maillog, поскольку msgid - это единственное, что объединяет конкретный sendmail-процесс и порожденный им spamstop-процесс.
    3. Нашли sendmail-процесс, вырезаем его 14-значный номер и номер spamstop-процесса из файла из п.1 в отдельный файл, связывая их таким образом между собой.
    4. Теперь формируем отчет: берем строку файла из 3п., делаем поиск по sendmail-процессам и spamstop-процессам в maillog, при этом учитываем время действия, потому что номер spamstop-процесса 5-значный, и у меня за день он может повториться раза 3-4 в разные часы. Если в полученных данных есть строка "Milter: data, discard" - записываем в лог, нет - пропускаем.

    26.05.2008.
    Обнаружилось очередное препятствие.
    Посмотрите на лог: ну и что теперь делать, если msgid не совпадают?
    Sendmail в данном случае в лог пишет msgid из Resent-Message-Id, а СО - из Message-ID:

    May 21 13:45:25 mail sendmail[7614]: m4L7jBqm007614: from=<somebox@miclibrary.ru>, size=1049252, class=0, nrcpts=1, msgid=<20080521074032.D06A13E8D7B@mail2.ibox.ru>, proto=ESMTP, daemon=MTA, relay=mail2.ibox.ru [213.248.34.8]
    May 21 13:45:25 mail spamstop[7721]:  (msg parse) took 0.001447, 0.000000 CPU
    May 21 13:45:25 mail spamstop[7721]:  (local data) took 0.000091, 0.000000 CPU
    May 21 13:45:25 mail spamstop[7721]:  (pipe timeout) took 0.012418, 0.000000 CPU
    May 21 13:45:25 mail spamstop[7721]: MESS_F  [5660] <consiglio@anrb.ru>:<212556570.20080521114039@miclibrary.ru>
    May 21 13:45:25 mail spamstop[7721]: MESS_F C         56         200         OK         sh=get? [skip]
    May 21 13:45:25 mail spamstop[7721]: MESS_F C         66         200         OK         sh=put? [skip]
    May 21 13:45:25 mail spamstop[7721]: MESS_F X-Spam-Status: No, hits=-5.1 dlvr_hits=-3.7 (7.0 9.0)    _7721_  <consiglio@anrb.ru>:<212556570.20080521114039@miclibrary.ru>       test=[skip]
    May 21 13:45:25 mail spamstop[7721]:  (spamstop pipe 0) took 0.226186, 0.000000 CPU
    May 21 13:45:25 mail sp-milter[7631]: For message from 213.248.34.8 will return ACCEPT, NO mailfrom: <somebox@miclibrary.ru>, rcpto: <consiglio@anrb.ru>
    May 21 13:45:25 mail sendmail[7614]: m4L7jBqm007614: Milter add: header: X-Spam-Ystatus: hits=-5.10
    May 21 13:45:25 mail sendmail[7614]: m4L7jBqm007614: Milter add: header: X-Spam-Flag: NO
    May 21 13:45:25 mail sendmail[7614]: m4L7jBqm007614: Milter add: header: X-Spam-Yversion: Spamooborona-2.1.0
    May 21 13:45:25 mail spamstop[7721]: launch took 0.000235 sec, thread took 0.231189 sec. nThreads=1
    May 21 13:45:26 mail drweb-smf[7632]: [m4L7jBqm007614]: scan: the message(drweb.tmp.Sxpn8r) sent by somebox@miclibrary.ru to consiglio@anrb.ru is passed
    May 21 13:45:26 mail sendmail[7614]: m4L7jBqm007614: Milter add: header: X-Antivirus: Dr.Web (R) for Mail Servers on mail host
    May 21 13:45:26 mail sendmail[7614]: m4L7jBqm007614: Milter add: header: X-Antivirus-Code: 100000
    May 21 13:45:26 mail drweb-smf[7632]: [m4L7jBqm007614]: processing message from somebox@miclibrary.ru is over
    May 21 13:45:26 mail sendmail[7723]: m4L7jBqm007614: to=<consiglio@anrb.ru>, delay=00:00:09, xdelay=00:00:00, mailer=local, pri=1079585, dsn=2.0.0, stat=Sent

    Смотрим заголовок письма:

    From somebox@miclibrary.ru  Wed May 21 13:45:26 2008
    Return-Path: <somebox@miclibrary.ru>
    Received: from mail2.ibox.ru (mail2.ibox.ru [213.248.34.8])
             by mail.anrb.ru (8.14.2/8.14.2) with ESMTP id m4L7jBqm007614
             for <consiglio@anrb.ru>; Wed, 21 May 2008 13:45:17 +0600
    Received: by mail2.ibox.ru (Postfix, from [skip] )
             id 591AF3E9571; Wed, 21 May 2008 11:40:36 +0400 (MSD)
    Received: from NTSH (unknown [e.f.g.h])
             by mail2.ibox.ru (Postfix) with ESMTP id D06A13E8D7B;
             Wed, 21 May 2008 11:40:32 +0400 (MSD)
    Date: Wed, 21 May 2008 11:40:39 +0400
    From: somebox@miclibrary.ru
    X-Mailer: The Bat! (v3.85.03) Professional
    Organization: MIC
    X-Priority: 3 (Normal)
    Message-ID: <212556570.20080521114039@miclibrary.ru>
    To: consiglio@anrb.ru
    Subject:  [skip]
    Resent-from: somebox@miclibrary.ru
    MIME-Version: 1.0
    Content-Type: multipart/mixed;
     boundary="----------B87132A720302"
    Resent-Message-Id: <20080521074032.D06A13E8D7B@mail2.ibox.ru>
    Resent-Date: Wed, 21 May 2008 11:40:32 +0400 (MSD)
    X-Spam-Ystatus: hits=-5.10
    X-Spam-Flag: NO
    X-Spam-Yversion: Spamooborona-2.1.0
    X-Antivirus: Dr.Web (R) for Mail Servers on mail host
    X-Antivirus-Code: 100000

    Тут я уже ничего поделать не могу, поэтому, когда скрипт не находит в строке лога такой же msgid, какой указывает СО, в отчет записывается предупреждение о невозможности предоставления информации по одному из писем. Если пользователь пожелает, то он может обратиться ко мне за разъяснениями и, может быть (как согласно легенде в древние времена ответили на ультиматум жители Лаконии: "Если ..." :), вручную я смогу выбрать инфу об этом письме.
    Ну и, конечно же, я не удержалась и задала вопрос на sendmail-конфе. Ждем-с.

    27.05.2008. А все-таки СО продолжает писать пустые msgid. Значит, и эту почту нельзя подвергнуть стат. обработке. Пользователю в отчет так и запишем, что по причине пропуска Спамообороной важной инфы в логе предоставить полную информацию об одном из за-discard-енных писем невозможно.


    4. Решение проблемы.

    02.06.2008. === С Новым Летом!
    29 мая добавлено 2 Gb ОП. Теперь ее объем составляет 2,7 Gb.

    Сразу были отключены 6 dnsbl-баз. CO устояла.
    Затем были отключены эти средства. СО опять устояла.
    Вчера 02.06.2008 были отключены мои собственные антиспам-рулсеты sendmail'a. А также вычищены все отказы в файле /etc/access. И тут СО показала себя молодцом. Самоостановы и проблемы с тредами не наблюдаются.

    Где взять дополнительный трафик для проверки устойчивости СО?
    На втором mx-е, на котором установлен VadeRetro, и на котором все предпроверки (iptables, access, etc) симметричны проверкам на основном почтовике, все ограничения были также удалены, а также порог отказа для VadeRetro увеличен до 3500 с тем, чтобы весь почтовый трафик безотказно доставлялся основному почтовику, нагружая его таким образом непосильной работой.
    СО держится. Максимальное значение nThreads за это время составило:
    Jun 2 14:51:13 mail spamstop[8010]: launch took 0.005057 sec, thread took 0.870197 sec. nThreads=49
    Конечно, очень жаль, что память "добралась" из г.М в г.У только в конце мая (может, мы на разных планетах?). А лето - время слабого почтового трафика, так что создать настоящие боевые условия для СО, похоже, я уже не смогу.

    Что дальше? А дальше в планах операция "Дуст".
    Анекдот в тему. Л.И.Брежнев читает доклад на съезде КПСС:
    - Товарищи! В прошлом году мы повысили цены на водку, но на благосостояние трудящихся это не отразилось.
    В этом году мы повысили цены на ковры и хрусталь, но на благосостояние народа это не отразилось.
    Мы намереваемся повысить цены на хлеб, масло, мясо и молоко, но уверены, что это не скажется на благосостоянии советских людей.
    Голос из зала:
    - А вы их дустом не пробовали?

    Что будет выступать в роли "дуста"? Буду последовательно уменьшать объем ОП.
    Для чего это нужно? Хочу выяснить минимально-необходимый объем ОП для стабильной работы СО в моем случае.
    Зачем? Ведь выбор сделан. И это не СО. А вот жадная я, и хочу за оставшиеся полтора месяца выжать из СО всю инфу, какую смогу.

    Итак. Открываем документацию и читаем:
    " ...Минимальные требования (пропускная способность — одно письмо в секунду):
    • Процессор Intel Pentium III с частотой не менее 500 MГц;
    • Оперативная память — не менее 512 МБ (1 Гб при работе с локальными шинг-лами, см. п. 0);
    • Свободное дисковое пространство — не менее 100 Мб (600 Мб при работе с локальной копией базы знаний).
    Рекомендованной конфигурацией является: Intel Pentium 4, 1,5 ГГц, 2Гб ОЗУ.
    Такой сервер сможет обрабатывать до 15 писем в секунду.
    Фактическая производительность «Спамообороны» зависит от многих факторов, в том числе от содержания писем..."

    Мне непонятно, что здесь подразумевается под одним письмом в секунду. Поэтому я буду оперировать словом "соединение". Удавшееся (stat=Sent или Milter discard, т.е. это и есть письмо, обработанное СО: благополучно доставленное или отправленное в /dev/null) или неудавшееся (обрыв соединения удаленной стороной или отлуп средствами sendmail'a, конечно, это письмо до СО дойти никак не может, но оно занимает ресурсы системы).
    Итак, при прежней конфигурации (P4/XEON, 2,66GHz, 768 Mb ОЗУ) СО начинала выпадать в осадок начиная с нагрузки на почтовик 7-8 соединений в секунду. Как правило, это был одновременный 0-1 discard СО и 7-8 неудачных соединений .

    При новой конфигурации (P4/XEON, 2,66GHz, 2768 Mb ОЗУ) СО держится и при 29 соединениях.
    За это время выявлены след. максим. значения удавшихся соединений: 7 discard'ов в секунду или 3 письма в секунду.

    05.06.08. Вчера уменьшила объем памяти на 512Mb. Сегодня случились самоостановы. Но на этот раз причина ясна.
    Jun 5 14:25:00 mail sp-milter[32529]: socket() failed Увидев в логе сообщение
    "Jun 5 14:23:52 mail spamstop[14581]: Timed out waiting for threads, nThreads=80",
    увеличила это значение до 100. Ждем-с. Эксперимент продлился 3 дня (жалко юзеров). Других эксцессов не наблюдалось.
    Лог прилагается, но четкого понимания, почему все-таки самоостанов имел место, он не дает. Скачки в количестве тредов объясняю только большим количеством неудачных соединений в данную или предыдущие секунды, но вот почему "socket() failed" случился при недавнем nThreads=69 и последующих всего 3-х обработанных СО письмах - непонятно.

    16.06.2008. Объем памяти уменьшен еще на 512Mb. Количество тредов еще с прошлого эксперимента оставалось прежним. Максимальное значение nThreads равнялось 90.
    Jun 16 17:40:58 mail spamstop[25366]: launch took 0.017828 sec, thread took 2.030854 sec. nThreads=90
    Самоостановов не наблюдалось, но "нарисовалась" старая проблема:
    Jun 17 14:26:57 mail sp-milter[591]: sp-milter: thread_create() failed: 11, try again
    Jun 17 14:26:59 mail sp-milter[591]: sp-milter: thread_create() failed: 11, try again
    Лог прилагается, но опять-таки не подтвержает инфу из документации. Количество обработанных Спамообороной писем за последние 5 секунд 0-1. Ну, чуть пораньше случалось 2-3 письма. Объем памяти составляет 1,7GB. Дока обещает, что СО будет держать до 15 писем в секунду при 2GB. Но тогда какие-то 2-3 сообщения в секунду никак не должны были вызвать проблемы при 1,7GB ОП.

    23.06.2008 Объем памяти увеличен на 256MB и составляет стандартные для рекомендаций 2GB.
    DrWeb все-таки выдал "Dr.Web (R) Filter for sendmail ver.4.33: thread_create() failed: 11, try again", sp-milter в этом замечен не был: так как DrWeb'у велено в случае сбоя передавать письмо дальше, то СО приняла сообщение и спокойно обработала его.
    Лог прилагается.
    Уверена, что если бы продолжила эксперимент, то увидела бы аналогичные проблемы при 2GB и у СО. Просто жалко пользователей.

    Операция "Дуст" закончена. Вывод: без 2GB ОП почтовые фильтры лучше не мучать.
    ===

    4.A. Странности.

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


    5. Советы .

    5.1. Если вам нужно установить СО на нескольких серверах, то вы можете провести полную установку только на одном сервере, а на остальные просто все скопировать. Ес-но, ключ должен быть индивидуальный для каждого сервера, а в /etc/spamooborona/spam.ini нужно будет исправить ip-адрес почтовика, обслуживаемые домены, м.б. списки внутренних и непроверяемых сетей, в общем, все, что индивидуально для данной системы.

    5.2. Для версии 2.3 неактуально. Вам не удастся отредактировать mc-файл через install.sh, если в /etc/mail отсутствуют hostname.mc или sendmail.mc (то есть, если ваш mc-файл имеет другое имя или расположен совсем в другом месте). В этом случае Install.sh просто не предложит "Настройку MTA (Sendmail configuration)". Тогда нужно самостоятельно отредактировать mc-файл и пересобрать конфиг sendmail'a.

    5.3. Для версии 2.3 неактуально. Install.sh похозяйничает в вашем /etc/rcN.d. Поэтому перед запуском install.sh скопируйте куда-нибудь /etc/rc.d/, после процедуры установки оставьте в /etc/rc.d/rcN.d только файлы, имеющие отношение к CO, изменив стартовый номер процесса по своему уразумению (самое главное, чтобы это было перед стартом sendmail), и копируйте сохраненную директорию обратно. Сэкономите время.

    5.4. Если при запуске sp-milter из /etc/rc.d/ система пишет: "smfi_setconn failed", то это означает, что система пытается запустить не скрипт /etc/rc.d/sp-milter, а сам демон /usr/sbin/sp-milter, поэтому попробуйте запустить фильтр так:
    ./sp-milter
    Кстати, в этом же случае sp-daemon не выдаст сообщение об ошибке, а просто тихо не отработает.

    5.5. На моей системе sp-milter не отрабатывает stop.
    Стартуя, sp-milter запускает 3 процесса. В качестве pid процесса в /var/run/sp-milter.pid записывается номер первого процесса. Соответственно скрипт sp-milter по команде stop прибивает именно его.
    Но на моей системе на самом деле ничего такого не происходит: sp-milter stop отрабатывает без каких-либо ошибок и сообщений, а sp-milter продолжает жить.
    Поэтому скрипт переписан на прибитие последнего, а именно, третьего из первоначально запущенных процессов.
    Ну и killall sp-milter отрабатывает также нормально.

    5.6. Так как для меня важно избавить СО от лишней работы, а "белый" список самой СО этого не позволяет, то для пропуска писем без проверки с определенных IP я теперь использую файл /var/yamail/intranet_zone .
    Вообще-то он предназначен для перечисления локальных сетей, почта из которых не должна проверяться.
    Но поскольку на него не накладываются ограничения по количеству сетей, то я его использую в качестве "белого" списка и для внешних IP-адресов.
    Правда, в моем случае легальная ежедневная рассылка приводит к тому, что часть почты доставляется с других mx-ов, а так как они исключены из intranet_zone, то происходит проверка почты Спамообороной. После снятия ограничений на кол-во одновременных соединений с IP источника рассылки в iptables & ConnClient(/etc/mail/access), письма из этой рассылки поступают исключительно с почтового сервера рассылки и не проверяются СО, чего я и добивалась.

    Второй способ избежать проверки письма - использовать то, что список почтовых ящиков, которые должны проверятся СО, привязан к почтовому домену. Мои собственные mx-ы выполняют роль не только почтовых серверов и ежедневно высылают массу отчетов, эту почту мне бы не хотелось проверять Спамообороной вовсе. Но так как на них СО не установлена, то я не могу включить ip-адреса mx-ов в intranet_zone. Поэтому в адресе получателей рассылок с этих серверов я указываю не почтовый домен, а полный адрес почтового хоста, таким образом эта почта проходит через СО со статусом SKIP.

    5.7. В белом списке в файле /var/yamail/whitelist нужно указывать полный адрес или домен не конвертного отправителя, а заголовочного.
    Мне никак не удавалось "обелить" домен анекдот-рассылки.
    Я ориентировалась на адрес отправителя по логу, им был anekdot-daily-return-XXX-XXXXXX=mail.ru@lists.anekdot.ru, и прописывала в белом списке домен lists.anekdot.ru ( пробовала даже такое (=)mail.ru@lists.anekdot.ru), а также полный конвертный адрес. А заголовочным отправителем является anekdot-daily-bounces@anekdot.ru, вот домен anekdot.ru и нужно было указать в белом списке.
    Кстати, если все нормально, и письмо, действительно, обелено, то в строке spamstop'a вы увидите FROM_IN_WL:

    Jan 25 09:36:14 mail spamstop[30377]: MESS_F X-Spam-Status: Dlvr, hits=5.0 dlvr_hits=52.5 (7.0 9.0) _30377_ < paradise@anrb.ru >:< 200801250400.m0P400nk060973@via.anekdot.ru > test= R3814, R512, R4903, R4845, R3577, R4862, R4852, R4853, R4849, R4850, R2056, R3298, __R4337, R4874, R92, R4224, R3297, FROM_IN_WL, R4251, R1628, R3815, __R4760, R646, R654, R662, R590, R598, R638, R632, R857, R621, R3313, R1106, R1189, R3107, __R3833, __R4341, __R1091, R1093, R1095, R1122, R4838, R4860, R1305, R4888, R537, R554
    Кстати, как показала практика, для обеления этой рассылки значения -10 в файле wl.rul мало.
    Поставила -20. Ждем-с. 26.05.2008. Так, -20 тоже мало, значит, пишем -30.
    20.02.2008. Кстати, не следует забывать включать в белый список домены, с которых приходят извещения о спаме, посылаемом из локальных сетей. Как правило, такие извещения содержат исходное спам-письмо и поэтому распознаются Спамообороной как спам. Поэтому отныне домен (скрыт) занимает в моем /var/yamail/whitelist почетное первое место.
    26.05.2008. Добавляю в /var/yamail/whitelist еще один домен (скрыт) - с этого домена также приходят уведомления о спаме из локальных сетей, а так как внутри содержится оригинал спам-письма, то эта почта помечается спам-меткой.
    06.06.2008. Ну вот появились первые ласточки:
    Return-Path: <24622@some-spam-report-domain>
    Received: from [81.200.221.17] ([81.200.221.17])
    by mail.anrb.ru (8.14.2/8.14.2) with ESMTP id m554C8ju026604;
    Thu, 5 Jun 2008 10:12:11 +0600
    Received: from [81.200.221.17] by vmx2.some-spam-report-domain; Thu, 5 Jun 2008 08:11:37 +0400
    From: =?koi8-r?B?9NLJxs/OIOnOzs/Lxc7Uyco=?= <24622@some-spam-report-domain>
    To: postmaster@anrb.ru
    [skip]
    X-Spam-Ystatus: hits=-55.3
    X-Spam-Flag: NO
    X-Spam-Yversion: Spamooborona-2.1.0
    Пишу очередные правила и обещаю не засвечивать больше "белые" адреса.
    Опираясь на следующие данные
    some-spam-report-domain text ="v=spf1 ip4:1.2.3.0/prefix -all"
    проверяем ip-адрес отправителя с доменом some-spam-report-domain

    SCheckFrom
    R$*                                    $: $(storage {From} $@ $1 $) $1
    R$*@some-spam-report-domain$*          $: < $&{client_addr} >$1@some-spam-report-domain$2
    R$*@some-spam-report-domain$*          $: $(syslog syslog:From: $1@some-spam-report-domain$2 $) $1@some-spam-report-domain$2
    R<1.2.3.4>$+@some-spam-report-domain$*  $@OK
    R<$+>$*@some-spam-report-domain$*  $#error $: 554 Forged sender address.

    5.8. Время отклика техподдержки Спамообороны составляет 1-2 суток (с учетом выходных - 3-4 дня).
    То есть, отправив вопрос в пятницу, вы вполне можете получить ответ только во вторник.
    Для справки: скорый поезд №40 добирается из Москвы до Уфы, где и разворачиваются описываемые здесь события, за 25 часов.
    Пассажирский поезд №910 топает до нас ажно 42 часа.
    Вот сколько времени до Уфы идет почтовый поезд, я не знаю, но, исходя из того, что почтово-багажный поезд "Москва-Владивосток" идет до пункта назначения 10 дней ( пламенный привет славному городу Владивосток и (особенно) его замечательным IT-специалистам   :),   могу предположить, что до Уфы почтовик добирается как раз за 3-4 дня.
    Итак, для того чтобы сделать ваш диалог максимально оперативным, информативным и эффективным, постарайтесь в первом же письме предоставить максимум полезной информации по вашей проблеме.
    Например, когда я обращалась с вопросом по поводу самоостановов демона и отлупов мильтера,
    мне нужно было предоставить след. инф-ию:
    доступ к 53, 80, 8000 портам их сервера;
    доступность сервера шинглов (через скрипт adm_so);
    доступность rbl-серверов (через скрипт adm_so);
    загрузка процессора и наличие свободной памяти;
    наличие sp-daemon&sp-milter среди запущенных процессов.

    5.9. Наш доморощенный perl-скрипт, который сам создавал почтовые сообщения и отправлял на почтовый сервер, минуя MUA, как оказалось, создавал спам-сообщения, то есть СО помечала эти письма спам-меткой.
    Скрипт делался на заказ и должен был использоваться в другой организации и в другой сети, то есть никакое "обеление" средствами СО к нему было неприменимо.
    Поскольку диалога с ТП и по этой проблеме опять не получилось, т.е. узнать, что не понравилось СО в этих письмах, не удалось, а документация умалчивает о принципах фильтрации, обращаю ваше внимание на этот факт. То есть, если вы также используете скрипты для создания почтовых сообщений, обратите особое внимание на то, понравится ли ваше "творчество" Спамообороне.
    P.S. 20.10.2008. На днях наткнулась на сайте СО на Принципы и технические методы работы с незапрашиваемой корреспонденцией, но это, скорее, общая информация, и ответ на наш вопрос она не дает.

    5B. Спрашивали? Отвечаю!

    1. Позволяют ли экономить трафик опции discard & reject?
    Нет.
    То, что в конфиге можно указать первые N-килобайт, достаточные для анализа, означает лишь то, что СО проверит именно заданное количество байт, но письмо все равно будет принято целиком.
    Этап DATA, во время которого и происходит передача тела письма, нельзя оборвать на полуслове, не вызвав тем самым повторную передачу данных. Другими словами, если во время передачи тела письма происходит сбой, нормальная почтовая система будет пытаться повторить попытку снова.
    Если был выставлен reject, то почтовик-отправитель получит заданное админом СО сообщение о невозможности доставки, если же был выставлен discard, то никто ничего не узнает - ни отправитель, ни получатель.
    Но письмо все же будет сначала принято на ваш сервер целиком!
    По поводу передачи письма на сервер yandex:
    "... Письмо не всегда передается целиком. Мы никогда не качаем мегабайтный вложения и прочее. Максимальная часть письма для передачи на анализ настраивается, по умолчанию составляет первые 64Кб..."

    2. Как попросить sendmail перенаправить почту, помеченную спам-меткой, в /dev/null?
    Никак. Sendmail не умеет перенаправлять почту на основе анализа подзаголовка Subject.
    Правда, есть возможность положить такое письмо в карантин.
    1 СПОСОБ. Это может сделать сама CO, если в spam.ini выбрать
    general.Discard: 1
    general.RejectValue: 13
    spam.score: 13
    Здесь я указываю, что почту, набравшую критический вес, подлежит уничтожать, а критический вес я приравняла к начальному спам-весу, чтобы добиться уничтожения всей спам-почты.
    Вы можете выбрать другое значение spam.score. Я в данном примере указала именно 13 потому, что все имевшиеся за 2 года ложные срабатывания не набирали больще 12.5 баллов.
    NB! Если у вас версия СО 1024, то судя по spam.ini (в нем задано лишь 5 опций, а указанные мной просто отсутствуют), вы не сможете это сделать из-за ограничений этой версии, поэтому для вас сгодится только 2 способ.

    2 СПОСОБ.
    Эта задачка может быть решена только для локальных клиентов с.п. Local Delivery Agent, id est LDA, f.e. procmail. Если письмо релеится дальше, то есть проходит через ваш почтовик транзитом, то к ней LDA не применим (если только вы не извратитесь, и не отправите предварительно такое письмо в локальный ящик с последующей отправкой по назначению).
    В /etc/.procmailrc пишем:
    LOGFILE=/var/log/procmaillog
    :0
    * ^Subject:.*SPAM.*
    /dev/null
    А для начала хорошо бы проверить (если вы до сих пор этого не знаете), какой LDA вы велели вызывать для локальной доставки sendmail'у.
    date | sendmail -Am -odi -d11.99 some_local_user
    Если вы не увидели в выводе procmail (а скорее всего обнаружили mail.local), значит, вам сначала нужно установить procmail и указать sendmail, что он (procmail) и будет LDA.
    Последнее делается так.
    define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail'))
    FEATURE(local_procmail)
    Но еще и еще раз повторюсь: sendmail этим не занимается. Он просто не умеет перекладывать/перенаправлять куда-либо почту, основываясь на содержании поля Subject. За исключением карантина. Но это само по себе не есть перекладывание почты.

    3. По поводу временных файлов Спамообороны:
    "...создается временный файл, в него записываются все заголовки письма, потом в него записывается все тело проверяемого файла, считанное из спула, потом этот файл сохраняется, потом он опять открывается, но уже для чтения, считывается за одну операцию чтения, пакуется, вливается через TCP сокет серверу. временные файлы нужны были при работе с SO через UNIX domain сокет. в данной же функции их использование - это просто результат лени разработчиков. им видимо не захотелось фукнцию оптимизировать после введения поддержки TCP сокетов..."
    "...Насчет несоздания временного файла - опыт показал что в этом месте ловить нечего. Ускорения обработки не произойдет, это не является узким местом. Неаккуратно - согласен, возможно когда-нибудь исправим. Кстати для некоторых почтовых серверов - уже так и сделано..."

    4. Как с помощью TheBat! откладывать помеченные СО письма в отдельную папку.

    6. Маниловщина. Имеет отношение к любому антиспам-фильтру. Просто не хочется заводить отдельную страницу.
    6.1 Discard - mx-ам, reject - всем остальным.

    Спамооборона позволяет отказать в приеме почты, если вес письма набрал определенное значение.
    Отказать можно "громко", выдав на этапе SMTP-диалога "Message rejected under suspicion of spam", Получив отлуп, почтовик на той стороне сам будет разбираться, что делать с этим письмом.
    Отказать можно тихо, тогда письмо, набравшее критическое значение (определяется параметром general.RejectValue) будет сразу уничтожено, а отправитель извещен об этом не будет.
    Насколько я понимаю, и в том, и в другом случае СО сначала целиком примет письмо, а потом сделает анализ первых 64Кб (определяется параметром general.Limit). То есть трафик в обоих случаях будет одинаков.

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

    Минус первого метода отказа очевиден, если почтовиком-отправителем является mx моего домена с большим весом:
    Во-первых, получив отлуп, транзитный mx должен будет сформировать уведомление о невозможности доставки письма.
    Во-вторых, если письмо пришло с несуществующего адреса, то доставить уведомление отправителю будет невозможно, о чем транзитный mx обязан будет сообщить постмастеру.
    Если учесть, что с моих mx-ов приходит 8-16т. писем в день, а максимально-допустимый вес письма набирает до 65% обработанной СО почты, то посчитайте сами, сколько лишней и даже вредной работы будет вынуждены проделать мои mx-ы.

    В этом случае был бы уместен дифференцированный отлуп, поскольку он бы позволил использовать плюс "тихого" отказа от почты.
    Если в spam.ini выбран general.Discard:0 (громкий отказ от письма) то хорошо бы было, если бы СО различала почтовый сервер отправителя, и если он _не_ _является_ транзитным mx-ом моего домена, то отвергала сообщение "с шумом", как и было заказано (general.Discard:0), в противном случае - тихо уничтожала (general.Discard:1), не нагружая таким образом мой mx ненужной работой по доставке уведомлений.

    Рекомендацию разработчиков ставить Спамооборону в этом случае на все mx-ы расцениваю как полный отрыв от российской действительности. Не хотелось бы думать, что это насмешка над российской наукой в стиле французской королевы Марии-Антуанетты: "Пусть едят пирожные...", что было сказано по поводу бедноты, требующей хлеба.

    Правда, и у этого решения свои минусы.
    1. Минус discard'a на втором mx-е: в случае ложного срабатывания отправитель письма не узнает о проблеме.
    2. Минусы reject'a на первом mx-е: если отправитель действительно отправил это письмо, то все ок.
    В противном случае опять имеем дело с "посторонним шумом":
    1) если обратный адрес существует, но отправитель это письмо не отправлял, то он получит извещение о невозможности доставки неизвестного ему сообщения, то есть станет жертвой "постороннего шума";
    2) если обратный адрес не существует, то почтовый сервер, который попытается передать мне этот спам, будет вынужден поучаствовать в double-bounced, то есть стать источником "лишнего шума".
    IMHO, оптимальное решение должно приниматься на основании распределения нагрузки между mx-ами.
    Кроме того, неплохо бы иметь трехуровневый спам-порог:
    1) от первого спам-веса до второго: доставка помеченного сообщения юзеру;
    2) от второго спам-веса до третьего: reject (то ли это спам, то ли не спам, но пусть отправитель знает о проблеме и реагирует в случае чего);
    3) от третьего и выше: discard
    Это позволило бы значительно снизить уровень "лишнего шума" при отказе от спам-почты.
    В отношении CO я бы определила эти пороги как 8:(20-30):30
    В отношении VR - 100:200:500

    6.2 Проверка достоверности спам-report-сообщений, поступающих с соответствующих сайтов.

    Если вы оказались в моем sendmail-разделе, то скорее всего вы в состоянии проверить достоверность такой рассылки.
    Но такой способ плох тем, что ip адрес источника рассылки может измениться, а , значит, от вас потребуется регулярная проверка правильных ip-адресов, чтобы не случилось ложных срабатываний. К сожалениию, реализовать проверку TXT-записей спам-report-доменов средствами sendmail.cf невозможно: вытащить из днс txt-запись мы еще сможем (с.п. спец. преобр. dns -R TXT), а вот сравнить ip-адреса релея с записью из dns без спец.патча - нет.
    Конечно, можно использовать дополнительный фильтр, но зачем занимать ресурсы системы, если эту проверку (ведь spam-report-сайтов немного) можно сделать в рамках СО?
    04.04.2009. С радостью сообщаю, что sendmail.cf умеет сравнивать IP и запись из дни и без патча: надо сначала вытащить запись из днс, а затем в LHS подставить $&{client_addr} по образу и подобию этого примера.

    6.3 Возможность выбора жесткой/мягкой фильтрации.
    Разным организациям нужен разный подход к фильтрации почтовых сообщений.
    Например, пользователи Академической Сети Республики Башкортостан "имеют право потреблять услуги данной компьютерной сети в интересах проведения научно-исследовательских и других работ в pамках основной деятельности данной организации." И только.
    Просматривая логи, полученные при сравнении VadeRetro и Спамообороны, обнаружила такое:
    Jun 4 04:04:52 mail sendmail[3476]: m53M4pC2003476: syslog:mx2:Subject:[VR:SPAM::]Maria.Sharapova.hot.pics
    Jun 4 04:04:52 mail sendmail[3476]: m53M4pC2003476: syslog:VRSpamScore:932
    Jun 4 04:04:52 mail sendmail[3476]: m53M4pC2003476: from=< nekceorn@RORACO.AT >, size=1236, class=0, nrcpts=1, msgid=<3AE4DC85-8BD5-2671-1114-3A14AA54D4C5@RORACO.AT>, proto=ESMTP, daemon=MTA, relay=www.anrb.ru [212.193.134.3] (транзитный mx, не включенный в intranet_zone)
    Jun 4 04:04:53 mail sendmail[3476]: m53M4pC2003476: Milter add: header: X-Spam-Ystatus: hits= 5.80
    Jun 4 04:04:53 mail sendmail[3476]: m53M4pC2003476: Milter add: header: X-Spam-Flag: NO
    Jun 4 04:04:53 mail sendmail[3476]: m53M4pC2003476: Milter add: header: X-Spam-Yversion: Spamooborona-2.1.0
    Jun 4 04:04:55 mail sendmail[3503]: m53M4pC2003476: to=< paradise@anrb.ru >, delay=00:00:03, xdelay=00:00:01, mailer=local, pri=31566, dsn=2.0.0, stat=Sent
    VR посчитал это письмо спамом(его вес - 932), а СО - нет. Причем неоднократно.
    Я не знаю, почему так случилось, может быть, CO вовсе не обращает внимания на тему сообщения, а тело письма было безупречно.
    Так вот. Исходя из ограничений, накладываемых на пользователей ANRB, первым делом я подумала, что раз "гора не идет к Магомету" (т.е. СО не распознает этот спам), то неплохо бы добавить это имя в спец. преобразование для проверки темы средствами sendmail.cf.
    Но таким образом я могу только отказать письму, а не изменить его тему.
    А если принять во внимание, что фамилия Шарапова имеет тюркское происхождение, то вполне возможно, что в РБ или РТ или РЧ или ... живет и спокойно работает научная сотрудница - полная тезка знаменитой спортсменки. И еще активно общается с коллегами из УНЦ или АН РБ. И, запретив сочетание "Maria.Sharapova", я могу только навредить.

    Теперь вернусь к возможности выбора степени жесткости фильтрации. Как я уже сказала, ограничения по использованию Инета, накладываемые на моих пользователей, вполне допускают фильтрацию почты по довольно жестким критериям. Я думаю, что то же самое распространяется и на другие научные и учебные учреждения. Под фильтрацией я понимаю и факт добавления спам-метки к теме письма, и discard.
    Как мне это видится:
    - в конфиге антиспам-фильтра есть дополнительный параметр, определющий степень жесткости фильтрации, с возможными значениями, скажем, 0 и 1;
    - если админ выбирает 0 - никаких дополнительных проверок не производится или никаких коэффицентов не применяется;
    -если выбирается 1 - проверяется или применяется.
    Если предположить, что СО в нынешнем ее исполнении не обращает внимания на темы сообщений, то в таком исполнении можно было бы включить проверку темы письма в жесткий вариант фильтрации. Если же все-таки СО проверяет тему, просто в случае с М.Шараповой тема потянула только на 6 баллов, то в случае жесткой фильтрации можно было бы применить некий коэффицент (1.1, 1.2, etc) к некоторым спам-критериям. Именно к некоторым. В противном случае, я могла бы просто уменьшить порог спам-веса (а он у меня и так уменьшен с рекомендуемого 9 до 7).

    6.5 Возможность обеления отправителя по секретному слову в теме письма.
    Существует возможность отказаться от проверки письма, если ip источника принадлежит /var/yamail/intranet_zone, а можно включить адрес отправителя в файл /var/yamail/whitelist, и тогда из веса письма будет вычитаться определенное значение, что значительно уменьшит вероятность попадания этого письма в разрад спама (к сожалению, отказаться от проверки такого письма невозможно).
    А хорошо бы дополнить эти два способа обеления еще и таким: если в теле письма содержится некое слово, то, в идеале, пропускать письмо без проверки или, не в идеале, вычитать из веса письма определенное значение.
    Таким образом, любой пользователь может известить своих коллег-друзей-знакомых о "пароле", и почта от этих отправителей будет проверяться с меньшим пристрастием или вовсе не проверяться.
    Этот способ хорош тем, что не требует участия постмастера в процессе обеления. Списки "общения" постоянно меняются: кто-то выбывает, кто-то меняет адрес, а кто-то только начал электронное общение с моим пользователем. Все это требует редактирования файла whitelist, а если я в отпуске?
    Набор слов, используемых для обеления, должен храниться в отдельном файле.

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

    16.12.2008. Еще одна причина. Для обратной связи со мной есть спец. ящик на mail.ru. Пока я не делаю форвард письма на свой ящик на anrb.ru, а мне приходят только уведомления о поступлении новой почты. Так как мне особо некогда "бегать" за почтой на mail.ru, то есть желание все-таки сделать форвард писем. Но! У меня ведь на почтовике VadeRetro, а в ваши сообщения часто вставлены заголовки спам-писем. А что, если ваше письмо наберет большой вес, и VR его уничтожит. Значит, мне нужно оставить требование уведомлений о поступающей почте плюс сохранять письма в своем ящике на mail.ru. А ведь я могла бы просто указать "волшебное слово" (которое, ес-но, периодически бы меняла), и ваши сообщения поступали бы без проверки.

    10.01.2009. Сотрудник института механики съездил на нефтяную конференцию в Польшу. По возвращении с глазами "6*9" он подошел ко мне и сообщил, что обменялся с коллегой email-ами, но, как водится, по дороге адрес потерял, и теперь весь в волнении, пропустит ли VR это письмо и т.д. и т.п., потому как это почти вопрос жизни и смерти. Адрес отправителя утерян - обелить его я не могу. А если бы нефтяник уехал на эту конфу с заветным словечком в кармане, да приписал бы желательную тему сообщения к своему адресу, да передал коллеге, то "не болела бы голова у дятла ..."

    10.04.2009. Так как обнаружилось замечательное решение - milter manager - которое позволяет избегать запуска milter (еще раз спасибо Павлу_из_инд_домена), то, думаю, эта задачка может быть решена самостоятельно.

    7. Заключение.

    Как-то встретилась в Сети такая притча.
    Один начинающий брокер пожаловался более опытному коллеге на то, что акции одной и той же компании неизменно обваливаются, стоит их ему купить, и резко выстреливают вверх, стоит ему их только продать. На что гуру ответил: "Молодой человек, запомните: не все акции вас полюбят ..."
    Хотя меня не оставляет впечатление, что тот гуру был прав, и что, если перенести его высказывание в сферу IT, то можно сказать, что Спамооборона меня не полюбила, все же призываю не впечатляться изложенной здесь информацией. Ведь, несмотря на пп.2.1-3.3, главным остается п.1:
    "Спамооборона действительно распознает спам и помечает тему письма по вашему желанию. "
    Примите во внимание также и то, что действие разворачивается в низкобюджетной организации с соответствующими серверами при отсутствии "умного железа", позволяющего блокировать нежелательный трафик на внешнем рубеже.

    В Сети практически нет отзывов об этом продукте, мне встретилось только одно сообщение, отмечающее аналогичные со мной проблемы при пиковых нагрузках в версии 1.5, и в то же время на opennet.ru я общалась с двумя админами, которые были абс-но довольны СО.
    Еще обсуждение.
    15.04.2008. На днях встретилось мнение, с которым я согласна почти на 100%:
    "... я как бывший администратор спамообороны могу сказать, что она, конечно, ужасна собою, когда не работает, зато когда работает, то лучше нее спам все равно никто не ловит. ну начиная со второй версии ей уже можно пользоваться..."

    А "почти" потому, что я другими антиспам-системами до сих пор не пользовалась. Вот сейчас устанавливаю Vade Retro от DrWeb, посмотрим, что получится. По крайней мере месяц назад на конференции по вопросам безопасности мне довелось пообщаться с представителем DrWeb и задать ему массу вопросов по поводу особенностей функционирования VR. Сложилось впечатление, что все или почти все, что меня не устраивает в СО, VR удалось избежать.

    02.06.2008. Ну что ж. Выбор сделан. "Прощай, король. Да здравствует король!" Что-то даже стало немножечко грустно. В принципе, Спамооборона - хороший антиспам.
    Еще появилась бредовая идея, когда кончится срок действия демо-ключа VR, попробовать установить на транзитный MX демоверсию КАС, и сравнить качество фильтрации КАС & СО. Но пока это только идея. С одной стороны, время жалко, с другой - с СО я распрощаюсь в середине июля и это последний шанс.
    01.07.2008. Очень уж захотелось сравнить SO, VR & KAS. Скачала демо-версию KAS, почитала доку, обнаружила, что управление антиспамом осуществляется через веб-интерфейс, помучилась пару деньков, пытаясь все же запустить его вручную, не получилось, махнула рукой, теперь мой энтузиазм точно закончился.
    KAV, конечно же, в своем репертуаре. За те 7 лет, что мы им не пользуемся, ничего не изменилось: накручено-наворочено, куча скриптов, модулей и конфигов, в общем, сам черт ногу сломает.

    Хотя документация в плане разъяснения принципов фильтрации неплохая. У Спамообороны этого и близко нет. Хотя догадываюсь почему.

    8. Обмен опытом.

    Мне было бы интересно узнать:
    -как вы составляете отчеты своим юзерам и как определяете принадлежность записей СО к определенному sendmail-процессу.
    -как на вашей системе ведет себя СО в часы пиковой нагрузки.

    13.05.2008. Cпасибо за ваши отклики и впечатления о СО! Прихожу к выводу, что мне нужно было это сделать(написать статью) сразу, как появились проблемы. Тогда пережить их было бы намного легче: ведь я бы по крайней мере знала, что не одна мучаюсь и ищу решение.

    9. Обращение

    15.05.2008. У меня к вам просьба. Не нужно высылать ссылку на мою статью в ТП Спамообороны.
    Во-первых, я спрашивала разрешение у ТП на публикацию статьи и показывала ее еще в середине декабря 2007г. То есть там никто ничего нового для себя не узнает.
    Во-вторых, статья написана в первую очередь для себя. Потому как помнить всю жизнь о плюсах-минусах СО я не в состоянии, а тетрадки имеют обыкновение либо теряться (привет барабашке:), либо распухать от информации настолько, что поиск становится затруднительным.
    Да и надоело наступать на одни и те же грабли: в энный раз ставлю СО, и каждый раз забываю сделать копию /etc/rc.d.
    Так что лично для меня эта статья - систематизация полученных знаний, попытка подведения итогов и отчет о проделанной работе. А не желание добиться ответной реакции от ТП.
    В-третьих, я это написала не только для себя, но и для вас:
    если бы весной 2007г., когда начались проблемы, я наткнулась бы на подобную статью, то вспомнила бы слова известной молитвы ("God grant me the serenity to accept the things I cannot change, courage to change the things I can, and the wisdom to know the difference") и отнеслась бы к этим проблемам философски: просто бы вздохнула, махнула рукой и пошла бы дальше, не тратя силы, время и нервы.
    И если кому-то моя статья и мой подход поможет вернуться в равновесное состояние :), я буду рада.
    Лично я уже почти в него вернулась и на проблемы СО смотрю с известной долей здорового пофигизма и c двух позиций:
    - а кому сейчас легко?
    - а есть что-то однозначно и значительно лучше?
    К чему и вас призываю. Наше время дорого, не так ли, а насчет нервных клеток наука до сих пор не определилась: восстанавливаются они или нет? :)

    Сезон 2009.

    10. Версия 2.3. Хроника боевых действий.

    29.04.2009. Новая версия установлена исключительно для повторного каскадного тестирования. При установке я споткнулась о:
    1) /usr/src/SO-2.3/Linux/install.sh
    2) /etc/so/adm_so
    3) /etc/so/scripts/cron_rul
    4) /etc/rc.d/init.d/sp-daemon start
    Было весело.

    07.04.09.
    1. OC SUSE. Тем не менее я скачала дистрибутив, обозначенный как решение для General Linux. Почему?
    Да потому, что от SUSE у меня только остов, все основные сервисы устанавливались самостоятельно с нужными мне опциями и т.д. и т.п. Поэтому всегда и везде, где предусмотрен вариант General Linux, я выбираю именно его. И в случае с DrWeb кстати тоже. До сих пор проблем не наблюдалось... До сих пор ... Установить СО - эт вам не фунт изюму скушать ...
    Итак, развернув tbz-архив, находим install.sh и запускаем его.
    Сначала он сказал несмертельные слова:
    * DNS Query: cso.yandex.ru...
    Note: nslookup is deprecated and may be removed from future releases. Consider using the `dig' or `host' programs instead. Run nslookup with the `-sil[ent]' option to prevent this message from appearing.
    Зато потом радостно вывалился с сообщением
    error: File not found by glob: yamail-[0-9]*.rpm
    Задавшись вопросом, зачем ему rpm, если у меня все в tbz, поднимаю руку на install.sh. Обложив скрипт промежуточным выводом, узнаю, что у меня пытается исполниться вот эта часть скрипта
    elif (which rpm >/dev/null 2>&1)
    then
    # это уже мое:
    echo RPM
    Пошерстив install.sh, обнаруживаю то, что нужно именно мне:
    elif (set | grep -q 'BASH_VERSINFO=.*slackware')
    Далее комментирую ненужное, добавляю нужно, и на выходе получаю:
    # elif (set | grep -q 'BASH_VERSINFO=.*slackware')
    elif (grep SuSE /etc/issue)
    then
    #echo Slackware
    echo SUSE
    # if (which rpm >/dev/null 2>&1)
    if (which norpm >/dev/null 2>&1)
    then
    [skip]
    else # let them chance to install Generic Linux (ага, дайте мне такой шанс!пожалуйста!:)
    echo Generic Linux
    SO_DATA=so-data
    PKG_ADD="tar xjv -C / -f"
    и так далее по тескту ...
    Далее install.sh >>report 2>&1
    (терпеть не могу, когда скрипт (скромно? нагло? безразлично?) молчит о том, что делает или не делает - догадайся, мол, сама).
    На выходе получаем такой отчет. Про последние ошибки ничего писать не буду - все и так понятно.
    Уфффф! Все! Установили!
    Спросите меня, почему я не скачала другой пакет?
    Во-первых, кризис на дворе, а это добро весит 42 MБ.
    Во-вторых, там сначала нужно зарегистрироваться. А я уже один раз зарегилась. Сколько ж можно?
    В-третьих, голова и руки для чего дадены? То, что написал один человек, другой вполне может подпортить под свои надобности.

    В заключение по поводу install.sh хочется заметить:
    если уж этой от этой windows-тенденции при установке СО (все решать за пользователя; считать, что знаешь, что у него есть и что ему нужно, лучше, чем он сам это себе представляет) никак не избавиться, то почему бы этому install.sh сначала не проверить, что именно скачал юзер, или, если уж совсем правильно, в каком именно пакете он сам находится, а потом принимать решение, чем и как это дело развертывать? Ну а если уж у юзера нет средств для развертывания именно этого пакета, то так ему сказать: "Не то ты, брат, скачал, не то ..." или "А ты знаешь, что у тебя bzip'а нет? И как мне разворачиваться прикажешь?"

    И еще ремарочка. Install.sh формирует несколько конфигов.
    adm_so.conf
    install.sh.conf
    reply.conf
    spamooborona.conf
    ?spam.ini
    Поэтому этот продукт невозможно просто развернуть из архива. Хотя у меня была мысль все-таки развернуть из архива сам-но, а недостающие конфиги запросить у знакомых СО-водов, но это было бы совсем извратом.
    Да, еще забыла сказать, что перед запуском install.sh создала /etc/mail/sendmail.mc (мой конфиг называется по-другому и лежит в другом месте), и по окончании работы скрипта получила в sendmail.mc нужную строку, определяющую sp-milter, выкинула из нее F=T и затем внесла эту запись в свой конфиг.

    Далее мне пришлось отказаться от установки CO на основном почтовике и повторить пункт 1 с уже привычными изменениями install.sh на втором MX-е (ALT 4.0).

    2-3. adm_so & cron_rul.
    Нужно скачать /var/yamail/so.dat. А это можно сделать через adm_so (опция Update setup).
    Запускаем, выбираем нужную опцию, < ENTER > - и ничего.
    Тогда идем в /etc/so/scripts, находим скрипт cron_rul. Он тоже молчаливый, то ли от скромности, то ли от пофигизма. Обкладываем его промежуточным выводом и убираем ключ q из строки
    /*) FETCH_OPTS="-mq -nd -T 60 -t 3" ;;
    На выходе получаем:
    Connecting to cso.yandex.ru|213.180.204.67|:443... connected.
    ERROR: Certificate verification error for cso.yandex.ru: unable to get local issuer certificate
    To connect to cso.yandex.ru insecurely, use `--no-check-certificate'.
    Unable to establish SSL connection.
    ALT для меня система совсем новая, я ее только "обживаю", а времени совсем нет, поэтому я пока добавляю рекомендованную опцию в строку wget, и наконец-то so.dat скачивается.
    Оставляю промежуточный вывод и не возвращаю ключ "q", направляя весь вывод в /var/log/so_update. Так я буду знать, что, когда и почему.

    4. Теперь идем в /etc/so/spam.ini и редактируем параметр general.RejectValue. Он отвечает за отказ письму при достижении спам-весом указанного значения.
    Мне нужно, чтобы вся почта, прошедшая через СО, попадала на сервер с VR, то есть чтобы ничто не reject'илось Спамообороной, и я от балды устанавливаю значение
    general.RejectValue: 4000
    Далее происходит самое интересное, здорово потрепавшее нервы.
    /etc/rc.d/init.d/sp-daemon stop
    Демон благополучно останавливается.
    /etc/rc.d/init.d/sp-daemon start
    Демон честно врет [DONE].
    В messages:
    Apr 28 14:19:08 liguria sp-daemon: sp-daemon shutdown succeeded
    Apr 28 14:19:16 liguria sp-daemon: child pid = 18882
    Apr 28 14:19:16 liguria sp-daemon: sp-daemon startup succeeded
    Вместе с тем в maillog:
    Apr 28 14:19:23 liguria sp-milter[17305]: socket connect to /var/run/sp-daemon.sock failed, errno=9
    Apr 28 14:19:23 liguria sp-milter[17305]: socket() failed
    При этом /var/run/sp-daemon.sock действительно отсутствует, а вот /var/run/sp-daemon.pid имеется, но он пустой.
    Ломаю голову и так, и эдак. Наконец переключаюсь на 12 терминал и обнаруживаю
    Apr 28 14:19:16 liguria sp-daemon[18882]: reject value out of range [9..1000]
    Ага, эту запись в maillog я просмотрела! Исправляю - запускаю - счастье наступило!

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

    А вообще хочу заметить, что вы скачаете именно то, что нужно, и SSL у вас настроен правильно, и вам не нужны нелогичные значения опций в spam.ini, так что никто кроме меня на все эти грабли наступить не может в принципе. Пишу опять-таки для себя, чтоб не забыть. На грабли с молчаливым wget я уже наступала, да вот забыла ...


    11. Требовательность к ресурсам.

    08.04.09
    Дано: P3(Katmai), 500MHz, 256 Mb ОЗУ; 512 swap, ALT4.0; sendmail 8.14.3,
    Спамооборона 2.3, unlimited.

    Почему такой слабый сервер? И не издеваюсь ли я над СО?
    Нет, нет и нет.
    В процессе установки мне пришлось отказаться от идеи ставить СО на основной почтовик, а он у нас приличный (P4/XEON, 2,66GHz, 2,7 Gb ОЗУ; SUSE10.0; sendmail 8.14.2.). Может, после праздников я еще вернусь к этому, но пока СО будет крутиться на одном из mx-ов, который подошел по версии дополнительного ПО, необходимого для работы СО. Собственно, я не ожидала от СО стабильной работы на таком слабом сервере, и полагала, что эксперимент быстро закончится. Но СО держится молодцом, и пока ни одного отказа в обслуживании не было.
    Следует заметить, что нынешняя спам-нагрузка не идет ни в какое сравнение с той, что была в прошлую мою СО-эпопею: в ноябре 2008 г. прошло сообщение об отключении одного из инет-провайдеров за распространение спама, и на своем почтовике я почувствовала снижение нагрузки, хотя многие мне говорили, что у них нагрузка быстро вернулась к прежним значениям.
    Пока что я выставила одинаковый вес обоим MX-ам, чтобы почтовая нагрузка была равномерной (см.«Русский экстрим»), а после праздников или все-таки запущу СО на основном (это самый интересный вариант), или снижу вес у второго MX-а, чтобы вся почта шла через Спамооборону.

    19. Заключение. И все-таки я выбираю VadeRetro.

    08.04.09
    Несмотря на отличный результат, который показывает в этом году CO, я выбираю VR.
    Причины здесь.




    Обратная связь
    Страница создана 18 июля 2006г. Выложена 14 января 2008г. Последнее обновление: 8 мая 2009г.
    sciurus@mail.ru (тема Sendmail обязательна, иначе я не получу быстрого извещения о письме)