трънки и блогинки

Greylisting с Postgrey

Написано на: 13.08.2005 · 4 коментара

Същност на метода

Greylisting е името на още един начин за борба с нежеланата поща. Предложението за имплементация на метода се основава на наблюдението, че повечето спамъри използват нарочно създаден за целта софутер, който не опитва да изпрати едно съобщение повторно, ако то не бъде прието от първия път. Пощенските сървъри, които са създадени според спецификациите, опитват да доставят отново такова съобщение след определен период от време. Тази разлика служи за отсяване на двата типа изпращачи и в крайна сметка – за намаляване на количеството нежелана поща, което вашите потребители получават.

Метода се състои в създаване на връзки или т.нар. „триплети“, които се състоят от:

  • IP адреса на хоста, който изпраща съобщението (по подразбиране е C клас мрежата му, заради pool-овете на някои ISP)
  • Адреса на изпращача
  • Адреса на получателя

Всеки такъв триплет се счита за надежден (от гледна точка на Greylisting метода) за определен период от време, ако хоста изпращач повтори опита за изпращане на съобщението след определен период от време и всеки повторен опит ще бъде разрешен (броят на нужните успешни повторни опити може да бъде променен).

Имплементация с Postgrey
За описаната тук конфигурация е нужен Postfix версия 2.1.x или по-нова, заради check_policy_service директивата за ограничения на smtp сървъра.

От страницата на проекта може да се сдобиете с кода му или с препакетирана версия за вашата OS. Postgrey е perl скрипт и е завсисим от още няколко модула на perl, за които вероятно имате също готови пакети или със сигурност може да се сдобиете от CPAN.

Postgrey се стартира като услуга с -d опцията и комуникацията с него може да се осъществява през unix или inet сокет. При стартиране може да се укажат и броя на нужните успешни опити за доставка на съобщение, за да се счита триплета за надежден. Това става чрез –auto-whitelist-clients опицията, която по подразбиране изисква пет доставени съобщения, а аз съм решил, че и едно е достатъчно.

Друго важно решение е и мястото на greylisting проверката в реда на ограниченията, което е свързано с кода на грешката, която трябва да върне сървъра на изпращача. Поведението на postgrey по подразбиране е да бъдат проверени всички ограничения и временната грешка да бъде върната само ако съобщението е щяло да бъде прието. С опцията –greylist-action може да се укаже и твърд код за грешка 451, който ще прекрати проверката на последващите ограничения и точно в този случай мястото на директивата има значение.

Нещо, което също е добре да бъде променено е и отговорът на пощенския сървър, когато връща кода за грешка. Това може да стане с
–greylist-text опцията. Аз не съм сигурен, че самият отговор трябва да уведомява изпращача, за това че сървъра използва този метод за борба с нежеланата поща, но това е нещо, което всеки трябва да реши за себе си.

За да предпазите потребителите си от процеса си на обучение, докато ползвате предимствата на реалните условия създадени от работещ пощенски сървър е добра идея да се ползват т.нар. whitelists списъци. В postgrey те са три на брой:

  • postgrey_whitelist_recipients – ваши хостове, потребители или регулярен израз за такива, които не трябва/желаят да ползват този метод на защита.
  • postgrey_whitelist_clients – списък на изпращачи (хост, IP или регулярен израз) които имат известен проблем с тази практика. Този списък се обновява периодично и е добре да си организирате автоматизирането на обновяването му.
  • postgrey_whitelist_clients.local – локален списък на изпращачи, на които се доверяваме или за които знаем, че имат проблеми.

С малко познания по perl е възможно и да обърнем логиката на списъците и да ги направим да служат като списък на тези, за които искаме тази проверка да се прилага, което може да е още по-добра идея, когато става въпрос за такава техника и имаме ситуация, в която нови потребители и хостове за поща се добавят често. Освен това с прилагането на метода само за определени адреси или хостове може по-лесно да видим резултата от метода.

Мисля, че е подходящо напомняне да оставите адреси като вашият личен, postmaster, webmaster, abuse и подобни, за които пощата трябва да се получава извън обхвата на тези защити, ако, разбира се, вече не сте го направили с access списъка.

За активиране на проверката е нужно да включим check_policy_service unix:postgrey/socket на подходящо място сред smtpd_recipient_restrictions в main.cf:

/etc/postfix/main.cf:
smtpd_recipient_restrictions = …
check_policy_service unix:postgrey/socket,

Презареждаме конфигурацията и можем да видим как се държи пощенския сървър. Първо за хост с активиран greylisting:

220 mail.server.com ESMTP Postfix

250 mail.server.com
mail from: peio@peio.org
250 Ok
rcpt to:peio@host.with.graylisting.com
451 <peio @host.with.graylisting.com>: Recipient address rejected: Greylisted for 300 seconds (Contact postmaster@server.com if you really need to)
quit
221 Bye

И после проверка на нормалното поведение:

220 mail.server.com ESMTP Postfix

250 mail.server.com
mail from: peio@peio.org
250 Ok
rcpt to: peio@host.without.graylisting.com
250 Ok
quit
221 Bye

Postgrey включва и инструмента postgreyreport с който може да гледаме какво става в базата, да си вадим доклади и други полезни функции. Към самата база също е добре да се отнасяме с внимание, за да не загубим доверените триплети, а и защото прочетох на няколко пъти за проблеми с postgrey, при които решението включва ново инициализиране на базата.

Връзки

Категория: свободни неща

4 коментара ↓

  • Хубаво ми е, когато хората коментират. Чета внимателно всеки коментар и отговарям, когато имам какво да кажа.

  • borj на 15.08.2005г. в 11:22ч.

    Това се твърди, че работи, но има един съществен (според мен) недостатък – лаг-а който се получава. Ако е пуснат auto whitelist – първия мейл от даден получател няма да бъде доставен при първия опит, а ако е изключен – за всеки мейл ще пропада първата доставка. А дори и да е пуснат auto whitelist, ако интервала за който се whitelist-ват изпращачите е по-голям от честотата с която изпращат – същия ефект.

  • пейо на 15.08.2005г. в 12:05ч.

    Напълно си прав, разбира се. Този тип защита може да доведе до забавяне на едно съобщение с до един час и предполагам за нас и много други това е напълно недопустимо. Затова и акцентирах на whitelisting-а толкова, и също така и на обръщането на логиката им.

    Както се сещаш, обаче, има типове клиенти, които приемат спама лично, а и живеят по едно друго време, за които такава защита е уместна.

    Аз си заделих няколко домейна за експерименти с Greylisting-а и засега резултатите са доста добри, ако имаме количеството нежелана поща за критерий. Почти около 85-90% по-малко от „некадърния“ спам се спря, въпреки, че някои по-целеви писма си минават без проблем.

    Но си помисли, че това забавяне може да изиграе положителна роля, като се има предвид скоростта на разпращане на спама и все по-малкия интервал на влизане на такива изпращащи в rbl и rhbl листите.

  • borj на 15.08.2005г. в 12:15ч.

    да, със сегашните техники на спамърите ефективноста му със сигурност е висока. искаше ми се да го внедря, но при нас пощата се иска „моментала“ :)) затова сега SPF+RBL проверка.

  • пейо на 15.08.2005г. в 12:18ч.

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