Еще одно правило для SpamAssassin'a

В продолжение темы предыдущей статьи. Еще один "популярный" в последние дни спам предлагает базы с частной информацией. Subject письма произвольный, и приходят эти письма с произвольных адресов. Пока все эти адреса не попали в блок-листы, SpamAssassin пропускает эти письма. К счастью, спаммеры снабдили свои письма весьма необычным заголовком X-Mailer:

X-Mailer: Sendmail 8.12.11/8.12.11

Прокол со стороны спаммеров! Благодаря такому уникальному заголовку, этот спам легко отсеять с помощью следующих правил для SpamAssassin'a:

header MAILER_SENDMAIL X-Mailer =~ /^Sendmail 8\.12\.11\/8\.12\.11/
describe MAILER_SENDMAIL Spammy X-Mailer header
score MAILER_SENDMAIL 2.5

P.S. 26.12.2007. Похоже, отправители этих писем уже попали в блок-лист SpamCop, и теперь в дополнительном правиле нет необходимости.

Спам на букву "i"

Последнее время мы часто получаем новую разновидность спама. Это сообщения на русском языке на такие темы как "защита конфиденциальной информации предприятия", "защита коммерческой тайны", "Тренинг по продажам" и проч., причем доставляются они как будто через легальный сервер Yahoo. Не знаю как спаммеры это делают, но в результате SpamAssassin пропускает эти сообщения, т.к. единственный тест, который на них срабатывает - BAYES_99. Хоть это и очень важный тест, все равно его одного не достаточно. (Иногда возникает желание поднять score этого теста до 5.4, как это было в SpamAssassin'e версии 2, но я все же думаю, разработчики выбрали score 3.5 не зря - false positives никому не нужны).

К счастью, этот спам можно отсеять благодаря его странной особенности - subject всех этих сообщений начинается с латинской буквы i. В нераскодированном виде начало subject'а всегда выглядит так:

=?Windows-1251?Q?i_=

Никто в здравом уме не будет делать такой subject. Поэтому достаточно добавить в конфигурационный файл SpamAssassin'a (обычно /etc/mail/spamassassin/local.cf) следующие строки (здесь должно быть 3 строки, начинающихся со слов header, describe и score, но ваш браузер может их разбить в неудачном месте):

header SUBJECT_STARTS_WITH_I Subject:raw =~ /^ *=\?Windows-1251\?Q\?i_=/
describe SUBJECT_STARTS_WITH_I Subject has a common spam pattern
score SUBJECT_STARTS_WITH_I 2.5

и спам на букву "i" будет успешно отфильтрован.

P.S. 26.12.2007. Похоже, отправитель этих сообщений уже попал в блок-лист SpamCop, и в дополнительном правиле теперь нет необходимости.

P.S. 06.02.2008. Этот тип спама возвращается, причем теперь subject может начинаться не только на i, но и на точку. Обновленное правило:

header SUBJECT_STARTS_WITH_I Subject:raw =~ /^\s*=\?Windows-1251\?Q\?[i\.]_=/
describe SUBJECT_STARTS_WITH_I Subject has a common spam pattern
score SUBJECT_STARTS_WITH_I 2.5

Delivery failure to Exchange public folder

I set up a new public folder in our Exchange server to receive emails from external SMTP server. The intent was to store emails from customers for management perusal. As the folder was going to contain sensitive business information, I allowed access to it to management group only. Unfortunately, the delivery to the folder failed - the email was returned to sender with no explanation. Exchange server's event log showed nothing, but when I increased Exchange logging level, the following cryptic message showed up in the log:

The following call : EcLocallyDeliverMsg2 to the store failed. Error code : 1238 (Message-ID <046e01c83c04$e24bbfd0$5101a8c0@csltd.intranet> will be NDR'd). MDB : 87b7cb4d-7e6b-47fa-be39-85b0d7995226. FID : . MID : . File : C:\Program Files\Exchsrvr\Mailroot\vsi 1\Queue\NTFS_e1be85a401c83c0400000024.EML.

Well, that didn't clarify much. A quick internet search turned up this Microsoft KB article: http://support.microsoft.com/kb/873393, but that definitely was not my case.

Giving the issue more thought, I realized that in attempt to secure the access to the folder as much as possible I went a little too far by disallowing any access to Anonymous users. Now, when an external SMTP server submits an email to Exchange server, this is anonymous access as far as Exchange server is concerned. Thus the attempt to submit a message to the public folder is denied! The solution was to allow "Contributor" access to the Anonymous user.

The bottom line is that if an Exchange public folder is to receive email from an external SMTP server, Anonymous users should be allowed "Contributor" access.