Здравейте,

Всеки, който се е занимавал с пощенски услуги знае що за напаст е спама и вирусите.

Аз поддържам няколко пощенски сървъра, базирани на Постфикс в комбинация с амависд-ню, кламав и спамазазин. Сериозно количество домейни в блеклиста, най-добрите сървъри за DNSBL. Проблема беше, че натоварването беше сериозно (особено спамазазина поради естеството си - Пърл скрипт), а сървърите са сериозни машинки - 2 процесорни Ксеони. Решение се намери в лицето на www.policyd-weight.org. Сървиза поддържа най-важните политики, по които оценява входящата поща преди да е СТИГНАЛА до SMTP-то. По този начин се реджектват писмата още преди да са влезли в сървъра. До тук добре - сървиза си поддържа DNSBL-ите, прави си проверки по HELO, MAIL FROM: и RCPT TO:. Напоследък обаче зачести един проблем - фирми, които са бизнес абонати на бТК. Когато пращат поща се идентифицират с обратния адрес на бТК, а не се резолват като домейна, който праща пощата (example.com към мен, но резолва връща 111-222-333-444.btc-net.bg) От там пропада проверката на полисите за МХ запис на изпращача и съответно пощата е реджектната.

Въпроса ми е - има ли възможност този обратен резолв да се реализира по друг начин, а не чрез DNS lookup. Защото варианта е да изключа проверката за проверка на МХ записа, което означава де що има спамери със собствен СМТП да ги пропускам - нещо, което разбира се не е желателно.

Предварително благодаря за вашите мнения по въпроса

Редактирано 30 ноември 200718 г. от Topper (преглед на промените)

reverce resolving е функция на DNS. Ти как очакваш това да стане по друг начин? Намери друг начин за борба със спам-а

Да, добър отговор Немо, но нали се сещаш - не върши работа.

rDNS е ясно, че е функция на DNS-a, но и команда dig рови из записите в ДНС сървърите, а връща други резултати. За това ми бе идеята.

А ти какъв полиси метод предлагаш за борба със спама (без грей листинг моля). Аз съм доволен, особено от натоварване 0.05

Да, добър отговор Немо, но нали се сещаш - не върши работа.

rDNS е ясно, че е функция на DNS-a, но и команда dig рови из записите в ДНС сървърите, а връща други резултати. За това ми бе идеята.

А ти какъв полиси метод предлагаш за борба със спама (без грей листинг моля). Аз съм доволен, особено от натоварване 0.05

Щом dig ти връща други ресултати значи някъде настройките не са наред

И кои ?

Без полиси сървъра - Постфикса е настроен с reject_invalid_hostname, reject_unknown_hostname, reject_unknown_sender_domain (както е описано в [RFC 2821] Sect. 2.3.5, [RFC 1123] Sect. 5.2.5 и [RFC 1035] Sect. 2.3.1, както и в http://www.postfix.org/uce.html ) което разрешава САМО валидни ДНС хостове по време на HELO хендшейкинга с СМТП-то, но пък не реджектва бТК домейни. Да, резонно е, защото постфикса прави при това проверка за валиден А ИЛИ МХ запис.

Това са настройките за ДНС-а на полиси сървиза:

## DNS settings

$DNS_RETRIES = 2; # Retries for ONE DNS-Lookup

$DNS_RETRY_IVAL = 2; # Retry-interval for ONE DNS-Lookup

$MAXDNSERR = 3; # max error count for unresponded queries

# in a complete policy query

$MAXDNSERRMSG = 'passed - too many local DNS-errors';

$PUDP = 0; # persistent udp connection for DNS queries.

# broken in Net::DNS version 0.51. Works with

# Net::DNS 0.53; DEFAULT: off

$USE_NET_DNS = 0; # Force the usage of Net::DNS for RBL lookups.

# Normally policyd-weight tries to use a faster

# RBL lookup routine instead of Net::DNS

$IPC_TIMEOUT = 2; # timeout for receiving from cache instance

А това са правилата:

# HIT score, MISS Score

@client_ip_eq_helo_score = (1.5, -1.25 );

@helo_score = (1.5, -2 );

@helo_from_mx_eq_ip_score = (1.5, -3.1 );

@helo_numeric_score = (1.5, 0 );

@from_match_regex_verified_helo = (1, -2 );

@from_match_regex_unverified_helo = (1.6, -1.5 );

@from_match_regex_failed_helo = (2.5, 0 );

@helo_seems_dialup = (1.5, 0 );

@failed_helo_seems_dialup = (2, 0 );

@helo_ip_in_client_subnet = (0, -1.2 );

@helo_ip_in_cl16_subnet = (0, -0.41 );

@client_seems_dialup_score = (3.75, 0 );

@from_multiparted = (1.09, 0 );

@from_anon = (1.17, 0 );

@bogus_mx_score = (2.1, 0 );

@random_sender_score = (0.25, 0 );

@rhsbl_penalty_score = (3.1, 0 );

@enforce_dyndns_score = (3, 0 );

Някаква идея ?

Ако махнеш reject_unknown_sender_domain няма ли да се оправи ситуацията или да сложиш специални правила само за обратните записи на БТК. Знам че не е идеално решение, но можеш да разчиташ след това на spamassasin да ги филтрира. Между другото това лично на мен ми звучи по-разумно (да филтрираш след пощата)

Това значи да пусна всеки домашен потребител, инфектиран с някаква буба да ми пуска писма от собствен СМТП сървър ? Не, благодаря

По-разумно да филтираш вътре пощата ли? Че защо - да поемам навътре нещо, което е потенциален спам/вирус и да разходвам процесорно време и памет, за да минават тестове през Кламав, Спамазин или Авира да го хванат? Не, благодаря. Може да направиш опит, бързо се пуска - да видиш какъв е ефекта. Да не казвам, че спама падна до под 1%. Апропо, може да тестваш с някоя голяма блеклиста за спамазазин (.cf - имам една 25мб ) и да видиш колко бавно почва да работи пощата, да не говорим, че ще си на 3-5 натоварване. А после я сложи като хеш файл в променливата на Постфикс smtpd_sender_restrictions и ще видиш как се банват пак същото количество лоши домейни, но за милисекунди. По същия начин действа и полиси демона - на етап SMTP RCPT

За такава схема говоря

Редактирано 29 ноември 200718 г. от Topper (преглед на промените)