Jak proti "open-relays" primym overenim

[Lubos Kaspar]

[verze v US-ASCII je ve druhe casti]

Dobrý den,

při boji proti spammingu se ukazuje, že velká část spamů
přichází z tzv. open-relays (SMTP-servery přijímající a odesílající
poštu se SMTP-obálkovou adresu odesilatele i příjemce mimo
obsluhované domény).

K jejich detekci a odmítání zpráv z nich se používají asi nejvíc
různé černé listiny, obvykle registrované v DNS jako záznamy typu
IN A, kde hostname tvoří IP-adresa otevřené SMTP-brány v rámci
domény poskytovatele černé listiny (typ a.b.c.d.black-list.tld).

To se mi nezdá nejpříhodnější:

1. závislost na nameserveru registrátora černé listiny (co dělat,
   když mu nejde: odmítnout vše asi nelze, přijmutím všeho se neguje
   účel použití);
2. neaktuálnost (opožděná registrace při nalezení open-relay nebo
   deregistrace při odstranění této vlastnosti).

Proto bych považoval za hodný uvážení následující princip, ke kterému
bych velmi přivítal názory subskribentů konference, uživatelů
sendmailu jako MTA.

Dovoluji si odhadnout, že by na internetovém MX-serveru mohlo být
užitečným ověřovat otevřenost SMTP-brány přímo při kontaktu
SMTP-klientem, a to asi takto:

- zkusit otevřít opačné SMTP-spojení: při neúspěchu pokračovat
  s výsledkem "klient není open-relay" (samozřejmě lze namítnout,
  že SMTP-přístup může být omezen a detekce nemusí být přesná);
- zkusit "helo", "mail from:" a "rcpt to:" s nějakými adresními
  doménami, které testovaný SMTP-server zaručeně nedoručuje
  (nejjednodušeji asi použít svou vlastní doménu);
  při odmítavé odpovědi typu "Relaying denied" SMTP-klienta
  přijmout, jinak ho považovat za open-relay a odmítnout.

Nesetkal se prosím někdo s takovým řešením nebo s podporou pro
takové ověření? Konkrétně by asi mělo jít o nějaká pravidla
do Scheck_rcpt (mám dojem, že v některých verzích sendmailu 
bylo i něco jako Scheck_relat), nejspíš s externí podporou.

Děkuji za příp. poznámky, upozornění na souvislosti, které jsem
neuvážil, resp. i za vysvětlení, proč je to celé nesmysl (v tom
případě se předem omlouvám za obtěžování).

S díky za pozornost
--
                                                Luboš Kašpar

-------------------------------------------------------------------

Dobry den,

pri boji proti spammingu se ukazuje, ze velka cast spamu
prichazi z tzv. open-relays (SMTP-servery prijimajici a odesilajici
postu se SMTP-obalkovou adresu odesilatele i prijemce mimo
obsluhovane domeny).

K jejich detekci a odmitani zprav z nich se pouzivaji asi nejvic
ruzne cerne listiny, obvykle registrovane v DNS jako zaznamy typu
IN A, kde hostname tvori IP-adresa otevrene SMTP-brany v ramci
domeny poskytovatele cerne listiny (typ a.b.c.d.black-list.tld).

To se mi nezda nejprihodnejsi:

1. zavislost na nameserveru registratora cerne listiny (co delat,
   kdyz mu nejde: odmitnout vse asi nelze, prijmutim vseho se neguje
   ucel pouziti);
2. neaktualnost (opozdena registrace pri nalezeni open-relay nebo
   deregistrace pri odstraneni teto vlastnosti).

Proto bych povazoval za hodny uvazeni nasledujici princip, ke kteremu
bych velmi privital nazory subskribentu konference, uzivatelu
sendmailu jako MTA.

Dovoluji si odhadnout, ze by na internetovem MX-serveru mohlo byt
uzitecnym overovat otevrenost SMTP-brany primo pri kontaktu
SMTP-klientem, a to asi takto:

- zkusit otevrit opacne SMTP-spojeni: pri neuspechu pokracovat
  s vysledkem "klient neni open-relay" (samozrejme lze namitnout,
  ze SMTP-pristup muze byt omezen a detekce nemusi byt presna);
- zkusit "helo", "mail from:" a "rcpt to:" s nejakymi adresnimi
  domenami, ktere testovany SMTP-server zarucene nedorucuje
  (nejjednoduseji asi pouzit svou vlastni domenu);
  pri odmitave odpovedi typu "Relaying denied" SMTP-klienta
  prijmout, jinak ho povazovat za open-relay a odmitnout.

Nesetkal se prosim nekdo s takovym resenim nebo s podporou pro
takove overeni? Konkretne by asi melo jit o nejaka pravidla
do Scheck_rcpt (mam dojem, ze v nekterych verzich sendmailu 
bylo i neco jako Scheck_relat), nejspis s externi podporou.

Dekuji za prip. poznamky, upozorneni na souvislosti, ktere jsem
neuvazil, resp. i za vysvetleni, proc je to cele nesmysl (v tom
pripade se predem omlouvam za obtezovani).

S diky za pozornost
--
                                                Lubos Kaspar