Qmail/postfix/sendmail [Re: anti-relay-dalsi pokus ?]

[Vladimír Solnický]

14. 6. 2000 napsal(a) Petr Novotny na téma ,Re: Qmail/postfix/sendmail [Re:...:

PN> On 14 Jun 00, at 15:55, Vladimír Solnický wrote:
PN> 
PN> > Já osobně z hlediska aplikacni vrstvy vidim jako závažny nedostatek
PN> > qmailu vuci sendmailu/postfixu to, ze aniz by ,,musel``, porusuje RFC
PN> > definujic 8BITMIME presne tim zpusobem, ktery celou snahu autoru
PN> > tohoto rozsireni ESMTP posila do haje.
PN> 
PN> Muzete prosim konkretizovat, co tim myslite? Rad bych se pokusil
PN> vysvetlit, proc qmail funguje zrovna tak jak funguje, ale vasi namitce
PN> zcela nerozumim.

Vse, co nize pisi, je moje osobni pochopeni oprislusnych RFC a chovani
prislusnych programu se vsemi z toho vyplyvajicimi dusledky.

Autori 8BITMIME jako jednoho z rozsireni pro ESMTP byli vedeni
nasledujicim pozadavkem: Umoznit zasilani osmibitovych zprav (tak, jak
jejich oznacovani zavedlo MIME v RFC 1341, 1521, a nasledovnicich) a
soucasne zabranit tomu, aby mohl byt osmibitovy dopis poskozen pruchodem
pres sedmibitovy server SMTP. Definovali proto 8BITMIME zhruba nasledovne 
(pisi s urcitymi zjednodusenimi hlavne co se tyce meznich pripadu):

Je-li server schopny 8BITMIME, muze toto deklarovat v odpovedi na
EHLO. Pote, prijme-li dopis, ktery ma v obalce BODY=8BITMIME (a uvnitr
C-T-E: 8bit) -- a jedine tehdy mu ho nekdo muze zaslat prtoze parametr
BODY= je definovan rozsirenim 8BITMIME, ma za povinnost overit, zda dalsi
zpracovatel dopisu je schopen zpracovavt osmibitove zpravy. Pro doruceni
via SMTP je to prave tehdy, kdyz dalsi server v reakci na EHLO reaguje, ze
je 8BITMIME. Potom mu muze poslat zpravu stejne, jak ji prijal. Pokdu
nasledujici prijemce neumi ESMTP, ale jen SMTP, nebo pokud umi ESMTP, ale
neumi 8BITMIME, server musi vsechny casti, ktere maji v ve strukture  
MIME C-T-E: 8bit prevest na Base64 nebo Q-P (s dodrzenim podminek, tj. Q-P
jen na typy text/* atd. -- nebo vzdy pouzit Base64). 

Vysledkem je, ze osmibitova zprava zaslana na server 8BITMIME nemuze nikdy
mit orezana nejvyssi bit, protoze bude vzdy vcas prevedena do
sedmibitoveho transportniho kodovani. Mozna nekdy zbytecne, ale nikdy
nedojde ke ztrate informace/psokozeni zpravy.

A nyni ma namitka: Pokud jsem dobre pozoroval chovani qmailu, deklaruje po
EHLO, ze je 8BITMIME, ale zpravu dal posila tak, jak ji dostal, tedy
osmibitove, aniz by overoval, ze dalsi server v rade je 8BITMIME. Dakze
bude-li dasli server v rade (napr.) cokoliv, co umi jen SMTP a tedy podle
RFC orezava nejvyssi bit, ma prijemce smulu, i kdyby pouzival MUA umejici
MIME, kde by nevadilo Q-P nebo Base64, nebo dokonce kdyby to byl jen
spooler nekde u ISP uplatnivsi se jen v pripade padu linky.

Dle meho nazoru by korektni bylo, kdyby autor qmailu bud implementoval
8BITMIME tak, jak je definovano, nebo (coz je asi autorove mentalite
blizsi) rekl, ze je to zbytecnost, ze je to nebezpecne, ze se mu to nelibi
-- a tak to neimplementoval, ale ani po EHLO nevypisoval retezec 8BITMIME.
Oba pristupy jsou korektni a podle RFC. A oba umoznuji lidem jako ja
vybrat si podle potreb -- v USA bych si mozna vybral qmail-podle-bodu-dva,
v Česku asi spise postfix (chodi tady hodne ceskych dopisu a neustale
prekodovavat zbytecne je skoda -- strojovy vykon se da pouzivat na
uzitecnejsi veci nebo ochrany). Takhle uz kvuli svym uzivatelum a jejich
prijemcum volim z modularnich programu jedine postfix.

Asi se trosku dokazi vcitit do mentality autora qmailu a peroto chapu,
proc qmail neiplementoval. Co nechapu je, proc po EHLO tvrdi opak.

V. S.

P. S.  Kdysi jsme si psal s clovekem (Barry Bouwsma bylo tusim jeho
jmeno), co pro Cesky rozhlas (davno uz tam nepracuje) delalpostovni i
jinou spravu a take tam zavedl sveho casu snad prvni implementaci 8BITMIME
(sendmail 8.7.x). Psal mi, ze se jim objem (v bajtech) zaslane ceske verze
zprav zahranicniho vysilani ČRo po svete vyrazne zmensil (bylo to,
pamatuji-li so dobre, 30-50 %). Tehdy me to prekvapilo, protoze mi
neprislo, ze cestina ma tolik znaku s diakritikou -- a take to byla
novinka, ktera se tolik nepouzivala -- nektere chyby a masove rozsireni
spammingu, ktere lidi prinutilo prejit na temer nejnovejsi verze
sendmailu, byly tehdy budoucnosti.
-- 
Mgr. Vladimír Solnický <solnicky na tmp.cz>, odd. systémové administrace ÚIT,
TMP -- Tel. montáže Praha, a. s., Šenovská 434, 182 03 Praha 8-Ďáblice, CZ,
telefón +420-2-66005154, MT +420-603-855154, telefax +420-2-66005531.
Píši pouze za sebe, ne za TMP / Speaking for myself only ...