Пощата ми ogi@fmi.uni-sofia.bg е от 1998 г. и съм писал мейлове на доста публични места, свързани със свободния софтуер. Затова и винаги съм получавал много спам. Положението много се разрастна, откакто минах към ogi@triangle.bg, просто защото съм на собствен виртуален сървър и там нямаше никакви защити. Понеже с този адрес малко съм писал, не е в чак толкова много списъци. (Това ще се промени сериозно след тази статия .) Все пак трябваше да направя нещо бързо и то беше whitelist на всички мейлове, от които съм получавал поща и които съм ги архивирал. Всичко останало отива в Junk Крайно решение, но върши работа.

За нещастие обаче моят сървър е никой в Интернет и известни пощенски услуги ми класифицират мейловете при спама След като един сървър направо ми отказа мейла, се наложи да оправя и обратния резолвинг на адреса на виртуалния сървър. Остана обаче напр. проблемът с мейлове до брат ми, който има адрес @yahoo.com и там все още се водя спамър.

Преди няколко дена обаче случайно попаднах на уеб инструмент за генериране на конфигурация за SPF (Sender Policy Framework). Оказа се изключително лесно – просто добавяне на един запис в зоната на домейна:

triangle.bg. IN TXT "v=spf1 mx -all"

Накратко SPF позволява домейните да указват кои са пощенските сървъри на домейна. Така че ако някой заразен компютър почне да плющи спам, пощенският сървър на получателя може да забележи, че този домейн никога не би пратил поща през този Интернет адрес и направо може да откаже мейла. В горната настройка се позволява само MX-ите на triangle.bg да пращат мейлове, но синтаксисът е достатъчно мощен и напр. има конкретно изброяване на IP области, а също и делегиране към други TXT записи за още сървъри.

Добавянето на проверка към Postfix е много лесно. В Debian 5.0 (Lenny) се инсталира postfix-policyd-spf-python, добавя се ред за услугата в master.cf и едно check_policy_service към smtpd_recipient_restrictions. (Конкретно нещата са описани в README.Debian на пакета.)

Ефектът беше поразителен Десетки спамове спират още преди портата на пощенския сървър. Интересно е, че много от тези спамове са от ogi@triangle.bg (или друго случайно име) до ogi@triangle.bg

Силно насърчен, пробвах да видя какво е положението с Yahoo! Mail. Оказа се, че от Yahoo! отричат SPF и вместо това пробутват тяхното творение DomainKeys или усъвършения му и стандартизиран вариант DKIM. При тази техника избрани заглавки и тялото на мейла се подписват и така може да се разбере дали са (1) наистина пратени от този домейн и (2) дали са променяни по пътя. Винаги съм си мислел, че е някаква сложнотия като DNSSEC и трябва някой да ти подписва ключовете. Но когато реално реших да опитам, се оказа лесно Дебианският пакет dkimproxy сам генерира ключове и в README.Debian има инструкции за интеграция с Postfix и за публикуване на ключа. Отне ми известно време, докато разбера, че инструкциите за публикуване са направо грешни – ще трябва да се кърпи. Записът в зоната е нещо такова:

postfix._domainkey.triangle.bg. IN TXT "k=rsa; t=s; p=MIGf...QAB"

Интеграцията с Postfix може да изглежда малко плашеща на пръв поглед, но не е чак толкова сложна. Използват се before-queue content filter и after-queue content filter за проверяващия подписи филтър/демон dkimproxy.in, и подобна техника за подписващия мейлове филтър/демон dkimproxy.out, само че за порта submission (587).

Тръгна всичко, ама се оказа, че не върши работа, т.е. не отказва мейлове. Ако подписът е невалиден, не може да се откаже, защото напр. многото пощенски списъци, на които съм абонат, може по невнимание да променят нещо. Ако подписът е валиден, може просто да е от заразен Outlook и не мога направо да го сложа в INBOX. Единственото, което остава, е тези подписи да имат някаква тежест при пресмятането на SpamAssassin дали това е спам. За това по-късно.

Тук изскочи един проблем, за който не знаех. Той е свързан с пренасочването на поща, както ogi@fmi.uni-sofia.bg препраща към ogi@triangle.bg. Например hoho@hihi.com праща поща до ogi@fmi.uni-sofia.bg и там се препраща към ogi@triangle.bg. Обаче моят сървър вижда, че (напр.) SPF на домейна hihi.com не включва пощенските сървъри на ФМИ и според правилата трябва да откаже този мейл. И така за всичко, което е пратено до ogi@fmi.uni-sofia.bg. Решението е да не се използва традиционното препращане чрез проста смяна на получателя, а и да се сменя подателя (на envelope, не на мейла) до нещо като ogi+fw=hoho=hihi.com@fmi.uni-sofia.bg. По този начин SPF не би отхвърлило мейла (ако @fmi.uni-sofia.bg имаше SPF – сега няма). Ако мейла по някакъв начин „отскочи“ (bounce), пощенският сървър на ФМИ трябва чрез обработка на адреса да върне отскачането до оригиналния подател hoho@hihi.com.

Тази техника се нарича SRS: Sender Rewriting Scheme. Вместо да го реализирам в пощенските сървъри на ФМИ обаче, което никак нямаше да е просто, реших просто да добавя сървърите на ФМИ в белия списък на SPF, т.е. те да не се проверяват със SPF. Някой друг път, може би.

Заслужава си да се отбележи, че @gmail.com правилно препращат писма по тази схема. През цялото време тествах изпращане и получаване на поща чрез пращане от ogi@triangle.bg до ognyan.kulev@gmail.com, което препраща до ogi@triangle.bg. Сървърите на GMail връщат обратно писмото в рамките на една-две секунди и всичко става много бързо.

След тия истории се сетих за RBL: Realtime blacklist. Оказа се изключително лесно за добавяне: просто няколко reject_rbl_client към smtpd_recipient_restrictions. Избрах си да ползвам SpamCop, abuseat.org и SpamHaus. Ефектът беше потресаващ. Как изобщо съм оцелял без тази защита! Наистина няма извинение тази няколкоредова настройка да се добавя към пощенски сървър. За да оценя по-добре ефектите на SPF и RBL, първо проверява SPF. Естествено RBL отбива повече спам, но не много много повече от SPF. SPF според мен наистина си заслужава да бъде масова настройка на всички пощенски сървъри, също както далеч по-популярния RBL.

След като стана ясно, че съм нямал RBL, за никого няма да е изненада, че нямах и SpamAssassin. Разчитах на Зимбрата на ФМИ да отсява пощата до ogi@fmi.uni-sofia.bg. Там имаше няколко уловки, макар на пръв поглед всичко да изглеждаше наред.

Знаех, че новата версия 3.3 е предпочитана заради автоматичното си обновяване на правилата за определяне какво е спам, обаче в Debian 5.0 (Lenny) е версия 3.2. Затова си сложих 3.3 от backports.org и „заковах“ да използва backports за пакета spamassassin. Автоматичното обновяване обаче не е включено по подразбиране и трябва да се бърка в настройките на демона /etc/default/spamassassin, включително за да се активира и самия демон spamd.

Стандартният начин е пускане на процеси spamc от страна на Postfix, обаче на мен ми се искаше мейлът още преди да влезе в опашката да се отказва, ако има висок резултат за спам. Така стигнах до spampd, който използва същите филтри като dkimproxy от по-горе. Оказа се обаче, че spampd просто не поддържа все още такова отказване и вероятно никога няма да поддържа, защото от години не е променян. Оставих го така и вече не ми се занимаваше с други варианти като spamass-milter, особено след като последното използва някакви грозни синтаксиси, наследство от Sendmail. Друг път. Тук трябваше малко да променям стандартните портове на филтрите при получаване на мейл, защото исках първо да се изпълни филтъра dkimproxy и чак след това spampd, с идеята че SpamAssassin променя заглавки и тялото и може да обърка процеса на проверка на подписите.

На този етап се оказа, че DKIM е голямо разочарование. Подписаните писма не носят почти никаква блага тежест в SpamAssassin, т.е. реално в моята система аз не се възползвам от подписването на DKIM. Надявам се поне да помага по някакъв начин на моята изходяща поща.

Друга ръчна настройка на SpamAssassin, която според мене просто трябва да си е включена по подразбиране, е компилирането на правилата. Освен активиране на приставката, трябва да се изпълни и първо компилиране чрез sa-compile.

Оказа се, че проверките на хешовете на писмата Razor2 и Pyzor изискват допълнителни настройки, за да работят. На мен ми изглежда, че цялата документация на SpamAssassin е писана от случайни хора, които докарват нещо работещо и си пишат за частния си случай. С разни опити и грешки, смяна на права, допълнителни настройки в /etc/spamassassin/local.cf, дебъг сесии, strace, запознаване с дебъгера на python pdb и други такива, най-накрая тръгна. Не разбирам защо тези активирани по подразбиране приставки трябва толкова да се чоплят, за да тръгнат. Цената на безплатния софтуер може би.

Остава да овладея силата на самообучението чрез Bayes и евентуално техниките на ръчното класифициране на спам.

От amavisd-new не се интересувам, защото съм на Линукс

Е, това е засега. Остава да се усъвършенствам след новите вълни на спам, които ще ме удрят след тази статия