Пощата ми ogi@fmi.uni-sofia.bg е от 1998 г. и съм писал мейлове на доста публични места, свързани със свободния софтуер. Затова и винаги съм получавал много спам. Положението много се разрастна, откакто минах към ogi@triangle.bg, просто защото съм на собствен виртуален сървър и там нямаше никакви защити. Понеже с този адрес малко съм писал, не е в чак толкова много списъци. (Това ще се промени сериозно след тази статия :( .) Все пак трябваше да направя нещо бързо и то беше whitelist на всички мейлове, от които съм получавал поща и които съм ги архивирал. Всичко останало отива в Junk :) Крайно решение, но върши работа.
За нещастие обаче моят сървър е никой в Интернет и известни пощенски услуги ми класифицират мейловете при спама :( След като един сървър направо ми отказа мейла, се наложи да оправя и обратния резолвинг на адреса на виртуалния сървър. Остана обаче напр. проблемът с мейлове до брат ми, който има адрес @yahoo.com и там все още се водя спамър.
Преди няколко дена обаче случайно попаднах на уеб инструмент за генериране на конфигурация за "SPF (Sender Policy Framework)":http://www.openspf.org/. Оказа се изключително лесно – просто добавяне на един запис в зоната на домейна:
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":http://www.openspf.org/SRS. Вместо да го реализирам в пощенските сървъри на ФМИ обаче, което никак нямаше да е просто, реших просто да добавя сървърите на ФМИ в белия списък на 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 не се интересувам, защото съм на Линукс :D
Е, това е засега. Остава да се усъвършенствам след новите вълни на спам, които ще ме удрят след тази статия :-)
Comments
(без заглавие)
Можеш да добавиш и greylisting (postgrey за postfix), доста спамери отказвам така, но има и своите минуси.
Какви са наблюденията ти относно DKIM за писма от теб към yahoo? Използват някакво собствено творение, подобно на greylisting и шантави rate limit-и и често пъти при изпращане на повече симултантни писма към тях режат за доста дълго време. Ако DKIM ще помогне за това съм готов да му хвърля едно око...
(без заглавие)
Само бях чувал името _postgrey_, сега го инсталирах и май наистина има ефект. За съжаление трудно се прави статистика колко реално спам е спрян от него. Все пак логиката зад тази техника е много добра и определено ще го препоръчвам на всеки.
Не мога да ти помогна за _Yahoo!_ – почти нямам общуване с тях. Както писах, за мен _DKIM_ е едно голямо разочарование, но сигурно _Yahoo!_ дават доста по-голяма тежест на _DKIM_, отколкото _SpamAssassin_ дават. Затова според мен си струва да опиташ. По-лесно е отколкото изглежда отдалече, особено ако преди това си работил с _content filters_ на _Postfix_.
За _DKIM_ мога да добавя още 2 практически неща. Филтърът за проверяване на подписи от време на време зависва и става временен отказ на мейла. Това ще да е някакъв бъг, който се проявява даже и при моите мизерни еднопотребителски обеми. Затова може направо да не се използва този филтър, и без друго той единствено добавя заглавки. _SpamAssassin_ си има собствена проверка на подписите на _DKIM_. Второто доста по-сериозно е, че се препоръчва ключовете да се сменят през известно време, между един път в месеца и един път в годината. Не съм видял написана автоматизация за това, а и е много лесно да се забрави.
Като обобщение, според мен най-ефективна е последователността на проверяване _postgrey_, _SPF_, _RBL_. Първо _postgrey_, защото е най-евтино откъм ресурси, няма _DNS_ заявки, освен за _client_name_, но това и без друго се прави от _reject_unknown_client_hostname_, което е настройка по подразбиране на _smtpd_client_restrictions_, т.е. тази _DNS_ заявка би трябвало вече да е кеширана. Второ _SPF_, защото има голяма вероятност данните за домейна на подателя да са кеширани от резолвера. Последно _RBL_, защото при спам, което е масовият случай, почти винаги прави некеширани _DNS_ заявки.
(без заглавие)
Оказа се, че най-доброто място за _postgrey_ е в края на проверките. Проблемът е, че _postgrey_ прави временни откази и затова проверките след това винаги се изпълняват, защото следваща проверка може да покаже постоянен отказ. Обаче когато _SPF_ и _RBL_ дадат постоянен отказ, спира се до там.