от Пейо Попов(19-12-2005)

рейтинг (24)   [ добре ]  [ зле ]

Printer Friendly Вариант за отпечатване

1. За access политиките

Чрез аccess политиките може да се вземат решения за на дадено email съобщение на различни етапи от приемането му. Традиционно тези политики се задават в access конфигурационен файл [1]. Въпреки, че съществуването на такава политика не е задължително, а само препоръчително, то в днешните условия е наложително използването й поне за адресите за контакт относно услугите на системата.

Препоръките за тези адреси се съдържат в RFC 2142 [2] и включват адреси като postmaster, abuse, webmaster, hostmaster и други. Специално за пощенските сървъри от най-голямо значение са postmaster и abuse [3], които трябва винаги да съществуват и пощата, за които, трябва винаги да бъде доставяна без да се прекарва през допълнителни филтри. Съобщенията до тези адреси се получават и четат от администраторите на системата и аргументи, че на тях се получава предимно нежелана поща са несъстоятелни.

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

2. Делегиране на access политики

Тъй като възможностите на синтаксиса на access файла са ограничени, от версия 2.1 Postfix дава възможност решенията относно съдбата на съобщението да бъдат делегирани на външно приложение, чрез което да се имплементира по-сложна логика. Най-честите приложения, за които се използва това е имплементацията на Greylisting и проверка на SPF записите.

За тази цел Postfix имплементира протокол за комуникация между SMTP сървъра и външен сървър, който обслужва запитванията и връща отговор относно по-нататъшните действия с писмото. Заявката се състои от двойки име=стойност, всяка на нов ред и завършва с един празен ред. Отговорът от сървъра за политики е action=[ACTION] където [ACTION] може да бъде всяко действие възможно действие предвидено в access файла [1] (примерно: OK/REJECT/HOLD/WARN или друго) и също последван от един празен ред. Примерни заявка и отговор са дадени в README файла [4] от дистрибуцията на Postfix.

3. Примерна имплементация

Най-простата имплементация на такъв сървър трябва да включва код, който да парсва заявката от postfix smtp сървъра, да взима решение възоснова на параметрите на заявката и да връща обратно своя отговор.

Само за пример прилагам работещa, но съзнателно практически безполезна имплементация (в utf-8 кодиране) на такава политика, написана на perl. Тя взима IP адреса на изпращача и след серия глупави преобразувания над двоичната му репрезентация взима решение дали да приеме или откаже писмото. Политиката ми напомня по някакъв начин на световното първенство по футбол и затова съм я кръстил така. От коментарите в кода може да научите малко повече.

Сигурен съм, че вие може да напишете нещо по-добро и дори смислено.

4. Конфигурация

Заради ограниченията и най-вече скоростта на spawn демона от Postfix е добра идея да си напишем политиката така, че да се демонизира сама, но пък от друга страна това би довело до по-голям шанс от грешки и проблеми. Независимо дали сме стартирали нашия сървър за политики самостоятелно или от spawn демона, ние можем да го достъпим по inet и unix сокет (с абсолютен или относителен път в файловата система). Най-лесно и пригледно е ако използваме spawn и относителен път като добавим нещо подобно в master.cf:

mypolicy unix - n n - - spawn
user=nobody argv=/usr/bin/perl /usr/libexec/postfix/mypolicy.pl

В main.cf трябва да добавим в реда на smtpd_recipient_restrictions, след reject_unauth_destination (рискувамен оpen rely в противен случай) ред подобен на:

check_policy_service unix:private/mypolicy,

За да ограничим последствията от възможни грешки, които да забавят работата на smtp сървъра ограничаваме времето за отговор от сървъра за политики на една минута добавяйки:

policy_time_limit = 60

4. XCLIENT и тестване на политиката

Освен дебъг информацията, която изпращаме към някой от syslog facilities, може да използваме и възможността за soft bounces (подмяна на кодовете за грешки от постоянни към временни 5хх на 4хх), като добавим soft_bounce = yes в main.cf, да използваме warn_if_reject директивата в реда на ограниченията или да се възползваме от XCLIENT [6].

XCLIENT е разширение на smtp, което позволява да подаваме произволни стойности на някои от атрибутите, с цел да тестваме ограниченията, които сме наложили. Възможността за използването му трябва да се укаже изрично чрез директива в main.cf подобна на:
smtpd_authorized_xclient_hosts = 127.0.0.1. Повече за разширението може да научите от неговия README файл [6].

5. Връзки

  1. man access
  2. RFC 2142
  3. RFC 822
  4. SMTPD_POLICY_README
  5. SMTPD_ACCESS_README
  6. XCLIENT_README

6. Корекции и коментари

Всякакви корекции и коментари са добре дошли. Може да пишете тук, за да ви видят и да сте полезни на повече хора, но аз пощата (peio в peio.org) си я чета по-често.



<< Ръководство за LXR | Играй на думи >>