Filtrování spojení

[Vladimír Solnický]

27. 6. 2006 napsal(a) Honza Vrbata na téma ,Re: Filtrování spojení`:

> takovato a podobna reseni jsou urcite nekorektni. totez plati o ruznych

Greylisting asi jo, nestudoval jsem to, protože se mi nelíbí a tak ho 
stejně nepoužívám. Minimálně by, pokud by ho používali všichni zrušil 
rychlost doručování (a také svoji funkčnost, protože spameři by pak 
museli implementovat opakované zasílání).

> kontrolach existence a zaznamu pro polozku helo, nebo kontrola mx zaznamu v 
> obalkove hlavicce mail from. ono se totiz v rfc nerika, ze v helo ma byt fqdn 
> existujiciho pocitace, nebo ze mail from ma obsahovat existrujici adresu. 
> pokud vim jsou tam jen pozadavky syntaktickeho razu.

Tohle není pravda. Tento rozšířený omyl jsem v této konferenci vyvracel už 
v roce 2001 a tak jen přikládám svoji tehdejší reakci jako přílohu.

> cili neni zahodno provadet restrikce prijimani posty na zaklade techto veci. 
> je pravda, ze rada mta se takhle bohuzel chova.

Jelikož je to korektní, je to oprávněná kontrola a pokud to odesílatel 
porušuje, je to nefunkčnost jeho systému. Záleží pak jen na mně, jak moc 
chci přijímat od nekorektních systémů. Praxe ukázala, že přístup 
s liberálním příjímáním všeho, co se dá, funguje jen v kooperativním 
prostředí; pokud se najde dostatečně velká a vlivná skupina výrobců SW, 
která bude na toto pravidlo hřešit (a bude mít nebo rychle získá 
dostatečný podíl uživatelů svého řešení), stanou se standardy jen cáry 
papíru a tedy je nutné mít určité hranice, co se vleze do mé liberálnosti 
a co už ne. Příkladem z praxe, pokud se nepletu jsou hlavičky In-Reply-To: 
a References: v odpovědích a MS Outlook. V podstatě dnes tyto hlavičky 
nelze použít k trasování vzájemných závislostí dopisů, protože ve většině 
pošty, pokud nejde o specifické komunity, tyto hlavičky vůbec nejsou.

> jak ale rika kolega, je mozne tyto informace a udaje pouzivat jako pomocne 
> informativni hodnoty pro dalsi rozhodovani a pripadne penalizace prijimanych 
> majlu ve spojeni s dalsimi metodami, jako je ten greylist.

Jak jsem psal, kontrola parametru HELO/EHLO je čistá. O greylistingu se dá 
minimálně říci, že něco řeší jen v případě nedostatečné rozšířenosti. 
Takže je to obráceně.

S pozdravem

V. S.

P. S.  Přiložená původní odpověď do konference:


5. 11. 2001 napsal(a) Vladimír Solnický na téma ,Teoreticke doplneni...:

> Date: Mon, 5 Nov 2001 11:10:14 +0100 (CET)
> From: Vladimír Solnický <solnicky na vegacom.cz>
> To: Účastníci konference o MTA sendmail <sendmail na linux.cz>
> Subject: Teoreticke doplneni moznosti odmitnuti EHLO/HELo na zaklade domeny --
>     nazor [Re: sendmail a domena v HELO]
> 
> 31. 10. 2001 napsal(a) Dan Lukes na téma ,Re: sendmail a domena v HELO`:
> 
> DL> poradku. Nicmene, i kdyz tam napisete jakykoliv blabol, server, ktery je
> DL> v souladu s platnymi normami vas nesmi odmitnout (RFC2821, jak jsem psal
> DL> v jinem prispevku asi predevcirem).
> 
> Doplnuji kontext: Mysleno jakykoliv blabol za prikaz EHLO nebo HELO.
> Jelikoz vim, ze v RFC 821 to bylo jinak, tak jsem se dival do RFC 2821 a
> pokud jsem neco neprehledl (necetl jsem RFC souvisle cele), trak nemohu
> souhlasit -- server nesmi odmitnout klienta na zaklade toho, ze udavane
> jmeno nebo adresa IPv4 uzavrena v hranatych zavorkach neodpovida
> skutecnemu jmenu nebo adrese IP klienta (muze to pouze zaznamenat v
> systemovem deniku). Ovsem parametr prikazu EHLO/HELO je typu DOMAIN a pro
> tento typ plati:
>
>     *  The domain name given in the EHLO command MUST BE either a primary
> host name (a domain name that resolves to an A RR) or, if the host has no
> name, an address literal as described in section 4.1.1.1.
> 
> a na jinem miste:
> 
> The SMTP client MUST, if possible, ensure that the domain parameter to
> the EHLO command is a valid principal host name (not a CNAME or MX name)
> for its host. If this is not possible (e.g., when the client's address is
> dynamically assigned and the client does not have an obvious name), an
> address literal SHOULD be substituted for the domain name and supplemental
> information provided that will assist in identifying the client.
> 
> 
> Jeslize je to MUST (dle definice vyznamu tohoto slova v RFC), tak
> nedodrzeni je duvodem k chybove hlasce. Vyse uvedena vyjimka vylucuje
> chybovou reakci na uvedeni jineho *platneho* jmena, nez je moje vlastni,
> ale dle meho nazoru nijak neresi, kdyz neuvedu vubec zadne platne jmeno
> (tj. napr. bla.bla.fuj nebo [333.444.555.666] a podobne). Tudiz na
> takovyto nesmyl muze server SMTP legalne zareagovat kodemtypu 5xx ci 4xx
> (u jmen z DNS je asi 4xx dobry kod, pokud nevim, zda neni problem jen s
> vypadkem DNS).
> 
> Je to otazka spise teoreticka, ale je zajimava pro nastavovani serveru
> SMTP (jak je nastavovat korektne), takze pokud mi nekdo muzete dokazat, ze
> se myslim, budu rad, kdyz to do konference napisete.
> 
> S pozdravem
> 
> V. S.


-- 
Vladimír Solnický (Vladimir Solnicky in ASCII)
Píši pouze za sebe / Speaking for myself only ...