Názory k článku Šťoura: Proč zahltilo Centrum konference?

Pokud te zajima Kodex, poslu ho emailem. Stanovisko Radary.cz jsme dostali emailem a je v clanku zapracovano a vychazi se z nej. V tom nevidim problem - predpokladame implicitne, ze posilate vase stanovisko proto, aby bylo pouzito pri tvorbe clanku.

Patricku, docela by me "redakcni kodex" Mobil serveru zajimal - v clanku RadioMobil versus Radary.cz - spor pokračuje Michael Novak hned v prvnim odstavci pise "Dnes vám přinášíme oficiální stanoviska serveru Radary.cz a společnosti RadioMobil ohledně problému, který nastal při zakázání serveru Radary.cz na SMS centru mobilního operátora Paegas. "

Co je ovsem zajimave, zatimco oficialni prohlaseni Radiomobilu jsou v clanku obsazena, nase ani jedno.

Pokud si RFC pozorne prectete, zjistite, ze From: v hlavicce by sice melo ukazovat na spravce mail serveru,
ale ze nemate sebemensi moznost zjistit, zda nejaka adresa je ci neni adresou zminovaneho spravce.

Nechci jiz dale virit prach,
nemohu si vsak odpustit poznamku: obecne nelze spolehat na to, ze v hlavicce bude mailer-daemon ci postmaster - rfc hovori o osobe zodpovedne za spravu MTA, takze by tam klidne mohlo misto postmaster byt martin.zedek@netcentrum.cz.

dodrzime vsak slovo a budeme tam davat obvyklejsi:
postmaster@centrum.cz

I ja se domnivam, ze vse podstatne bylo receno...

ad 1) pokud radeji pouzivate vice programu, kde kazdy dela jen neco, nikdo vam nebrani takove reseni pouzivat. zbytecne si tak ale pridavate praci, kdyz chcete funkcnost takoveho konglomeratu rozsirit. pandora je v teto oblasti resenim komplexnim, ktere lze jednoduse rozsirit.
ad 2) myslim, ze jsem jasne uvedl v teto diskuzi, ze chyba je i na strane pandory. vice viz. bod 3
ad 3) o nutnosti dodrzovat RFC jsem nediskutoval, coz jste po dvojnasobnem cteni cele teto diskuze uz konecne mohl pochopit. pandora byla dnes okolo poledne opravena dle RFC, takze myslim, ze z nasi strany zde je snaha standardy dodrzovat a priznavam, ze autor pandory v tomto udelal botu a taky mu to bude receno.
nicmene k cele situaci se zacyklenim by nikdy nedoslo, kdyby mailer daemon centra odesilal maily s chybami o prekrocene quote s odesilatelem MAILER-DAEMON@centrum.cz nebo postmaster@centrum.cz (jak delaji vsichni mailer daemoni, ktere znam) a nikoli <uzivatel_u_ktereho_doslo_k_chybe>@centrum.cz, coz odporuje doporuceni RFC. hlavni chyba lezi ovsem na pandore.
ad 4) viz. bod 3.

s pozdravem,
Michal Vitecek

btw: ted jsem dostal mail od spravce centra, kde pise, ze se budou ridit doporucenim RFC a chovani sveho mailer daemona upravi. pandora byla opravena tak, aby se dle RFC chovala. myslim, ze jiz nema smysl dale o tomto problemu diskutovat, protoze obe strany priznaly a opravily chybu na svem poli.

Pan Vitecek narazi na skutecnost, ze v inkriminovany den byla v chybovych dopisech od nas v hlavicce adresa uzivatele (v obalce byl Mailer-daemon). Chci byt korektni, pripoustim tedy, ze v hlavicce mailu by mela byt adresa postmastera, uplne presne receno osoby, ktera je spravcem MTA. jak rika rfc:

The From field of the message header of the DSN SHOULD contain the address of a human who is responsible for maintaining the mail system at the Reporting MTA site (e.g. Postmaster), so that a reply to the DSN will reach that person.

Pripoustim tedy, ze tim, ze jsme tam dali adresu uzivatele jsme se sice neridili doporucenim rfc, nicmene jsme tim nemohli zpusobit ono cykleni. Prioritu ma adresa v obalce zpravy.

V zajmu korektniho dodrzovani rfc tedy prekonfigurujeme nas system tak, aby do hlavicky mailu o nedostatku mista daval adresu postmaster@centrum.cz

Martin Zedek

Opravdu nerozumim, co se mi snazite rict. Postupne:

1. To, ze Pandora dela i neco jineho, jeste neznamena, ze nejde vyjit z existujiciho a funkcniho baliku.

2. To, ze Pandora dela i neco jineho, jeste neznamena, ze rozesilani posty musi delat spatne.

3. RFC se dodrzovat museji, a opravdu nevim, proc o tom vy nebo pan Zandl diskutujete. Chova se Centrum presne podle RFC? Chova. Vraci bounce na adresu v MAIL FROM:? Vraci. Ma bounce podle RFC821 posilat kamkoliv jinam? Nema. Takze je chyba u vas, a mate ji resit, nikoliv blokovat Centrum.

4. Kdo jeste si podle vas neudelal domaci ukol? Precetl jsem si tu diskusi dvakrat, abych si byl jist, ze mi nic neunika. Nerozumim vasemu tvrzeni, ze "autor pandory nebyl jediny, kdo [dle me] neudelal domaci ukol" - zkuste mi to, prosim, vysvetlit.

kdyby pandora byla jen o spravovani mailing-listu, mel byste pravdu a asi bychom pouzili jiny software.
pandorinou hlavni praci je rozesilani a prijem mailu - to je prava. ale nedela jen to, a proto bylo nutne napsat vlastni software. dale vam doporucuji precist si me dalsi prispevky, protoze autor pandory nebyl jediny, kdo dle vas neudelal domaci ukol.

Michal Vitecek

to je ale omyl: pokud by vratil chybovy kod 5xx, tak i v pripade, ze mail pujde pres relay, bude vse v poradku - neuspel totiz MAILER-DAEMON nebo postmaster na relayi a zprava o nedorucitelnosti se sice dopravi zpet na adresu konference, ale pandora tyto zpravy zpracovava a do konferenci se tyto nikdy nedostanou.
problem je tedy i na strane centra, ktere by melo tyto chybove maily odesilat od sveho MAILER-DAEMONA a nikoliv od uzivatele, se kterym ma problemy nebo okamzite vracet kod 5xx (v pripade, ze je to mozne).

Michal Vitecek

to vse je sice hezke - ovsem mailer centra se nechova v techto pripadech standardne: zpravu s chybou sice posle na odesilatele, jez je uveden v MAIL FROM v obalce, nicmene jako odesilatele neda (jak je standardem) sebe (tj. MAILER-DAEMON, ci postmaster) ale uzivatele, kteremu quota dosla.
kdyby se tedy choval i on standardne, k zacykleni by nemohlo dojit i v pripade, ze pandora spatne vyplnovala MAIL FROM v obalce.

Michal Vitecek

Tak jsem to zkousel a mate pravdu, omlouvam se za desinformaci.
Opravdu to vrati 250 (queued) a mail o chybe se vygeneruje extra.
Myslel jsem si, ze to tak je, protoze mi na jednom serveru, kde je qmail pripojeny k databazi, staci vratit z toho programu, co to uklada do db navratovy kod 100 a na stderr vysypat chybovou hlasku a qmail uz se sam postara o odeslani hlaseni o chybe (na rozdil od sendmailu, kde se mi toto nepodarilo zajistit).

Vzhledem k tomu, ze existuje onelist.com, ktery ma problem plne vyresen, nikdy zadne RFC neporusil, zadne mail-loopy nevytvari, a zpracovava o rad ci dva vyssi objem dat, nez Pandora, rekl bych, ze si tvurci Pandory zapomneli udelat domaci ukol.

Bod 2, jak ho zde pan Zandl uvadi, je NESMYSL. Pokud programatori Pandory nejsou schopni do MAIL FROM: uvest neco jineho nez konferenci, tak si nezaslouzi pracovat na problemu ani zadarmo. Instalace qmail/ezmlm-idx/MySQL zabere asi dve hodiny, kontrola funkcnosti asi den, a problem je beze zbytku vyresen. (Neni ani potreba se RFC-bounce zpravami zabyvat, nebot je ezmlm zpracovava automaticky.) Tuto instalaci zvladne kazdy, kdo zna prikazy "tar", "vi", "patch", "make" a "less".

Skutecne me pristup pana Zandla zarazi.

Prominte, ze to reknu tak ostre, ale kdyz tomu nerozumite, tak do toho nemluvte. qmail pri vstupu mail pouze ulozi do fronty a indikuje uspech. Jakekoliv zkoumani, komu mail dorucit, a jestli treba nepretekly quoty, nasleduje nekdy pozdeji.

Opravdu verim, ze ani free konference se neprogramuji bez problemu. Take chapu, ze v hlavicce mailu chcete uvadet "From: konference@pandora.cz". Nicmene rec byla o OBALKOVEM from (MAIL-FROM), ktere zcela jiste muzete nastavit na jakoukoli jinou adresu, na kterou se budou vracet chybove hlasky a ktera nebude zpusobovat cykleni mailu - namatkou me napada treba adresa cloveka, ktery konferenci zalozil a ktery je veden jako jeji spravce. Tuhle adresu normalni uzivatel nikdy neuvidi, takze z hlediska chovani systemu to neni zadny problem. A jestli je to pro vas "technicky" problem, tak je to pouze vase chyba, protoze standardy jsou od toho, aby se (alespon castecne) dodrzovaly.

Pak ale nemá Pandora na Internetu co dělat.

Od toho jsou RFC, aby byla zaručena interoperabilita.

Je nesmysl vymýšlet proprietární řešení, když existuje všemi dodržovaný standard.

A je pak velmi neseriózní psát na Pandoře:

"Upozornění pro uživatele serveru Centrum CZ
V pátek (17. 3. 2000) dopoledne jsme byli nuceni dočasně zakázat všechny adresy z domény centrum.cz. Tento server vracel do našeho systému zcela proti RFC standardu chybová hlaení o přeplnení e-mailových účtů svých uživatelů. "

Nepopiram, ze Pandora ma davat do hlavicky podle RFC neco, co nedava. Rikam ale taky podruhe, ze neni technicky mozne, aby to tam davala - koho zajima proc, nechte emailuje.

Tzn. je treba najit jine reseni - do te doby nelze na Centru zpravy z Pandory prijimat, abychom predesli dalsim zahlcenim. Funguje to vsude jinde, myslim, ze i pro Centrum se reseni najde.

Naopak, u qmailu se da e-mail zpracovavat jeste v dobe, kdy je otevrene spojeni (takze se da vratit chyba typu "pretekla quota" nebo "uzivatel neexistuje").

Není nadto přesvědčit se na vlastní oči.
Tak jsem se přihlásil do testovací konference tk@pandora.cz a co nevidim - v SMTP obalce je skutecne chybne uvedeno tk@pandora.cz.

Takže je chyba jednoznačně na straně Pandory, a zběsilé výkřiky na titulní straně Pandory, že centrum nedodržuje RFC jsou úplně mimo.

Pro názornost uvedu, jak vypadá hlavička mailu přišlého z Pandory:
(vypustil jsem "received" řádky)

Return-Path: <tk@pandora.cz>
(to je ta chyba)
MIME-Version: 1.0
Date: Thu, 23 Mar 2000 21:28:12
From: "ryston@razdva.cz - Testovaci konference" <ryston@razdva.cz>
Reply-To: "Konference Testovaci konference" <tk@pandora.cz>
To: "=?iso-8859-2?q?=DA=E8astn=EDci_konference_Testovaci_konference"_?=<tk@pandora.cz>
Subject: test
Message-ID: <153172@pandora.cz>
X-Sender: Pandora.cz
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit

Z meho pohledu bych tomu vytknul ještě tři věci:
- zkomolenou adresu odesílatele (proti citovanému RFC)
- 8bit - to kódování nemají některé servery rády
- diakritika v To:

A teď se podívejme na to, jak vypadá hlavička z poměrně renomované a hlavně velké konfrerence linux-kernel:

Return-path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
(ano, to je správně)
From: Pete Zaitcev <zaitcev@metabyte.com>
Message-Id: <200002120627.WAA04690@ns1.metabyte.com>
Subject: Patch to 3c59x.c
To: linux-kernel@vger.rutgers.edu
Date: Fri, 11 Feb 2000 22:27:52 -0800 (PST)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
X-Orcpt: rfc822;linux-kernel-outgoing-dig

Takže je tam dalšími řádky pojištěno, že nedojde ke smyčce. Jako poslední instance je to X-loop.
"Precedence: bulk" by mělo zajistit, že zprávy z konfrerence mají nízkou prioritu.

Nebo domácí konference:

Return-path: <pmail-cz-admin@fee.vutbr.cz>
From: xxxx
To: pmail-cz@fee.vutbr.cz
Subject: Re: Znovu forward
Reply-To: pmail-cz@fee.vutbr.cz
Sender: pmail-cz-admin@fee.vutbr.cz
Errors-To: pmail-cz-admin@fee.vutbr.cz
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: diskuse uzivatelu programu Pmail/WinPmail <pmail-cz.fee.vutbr.cz>
X-BeenThere: pmail-cz@fee.vutbr.cz
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by boco.fee.vutbr.cz id UAA8747

nebo

Return-path: <owner-netinfo-l@majordomo.vol.cz>
X-Authentication-Warning: majordomo.vol.cz: majordom set sender to owner-netinfo-l@vol.cz using -f
From: xxxxx
To: netinfo-l@vol.cz
Sender: owner-netinfo-l@vol.cz
Precedence: bulk
Reply-To: netinfo-l@vol.cz

nebo tady na Lupe:
Return-path: <owner-isp@lupa.cz>
From: xxxx
To: isp-l@lupa.cz
Subject: Re: ISP: Info o providerovi
Sender: owner-isp@lupa.cz
Precedence: bulk
Reply-To: isp-l@lupa.cz

Nebo konference bezici na ezmlm:

Return-path: <redhat-cz-return-439-petr=ryston.cz@linux.cz>
Mailing-List: contact redhat-cz-help@linux.cz; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: redhat-cz@linux.cz
Delivered-To: mailing list redhat-cz@linux.cz
From: xxxx
To: redhat-cz@linux.cz
Subject: ANNOUNCE: RH6.1cz final

Je uz to konečně jasné? Copak tvůrci Pandory, a že ten projekt existuje už nějakou dobu, se neumějí poučit?

I v nasem zajmu je tuto situaci co nejdrive vyresit.
Jiz minuly tyden jsme tento problem vyresili
pozastavenim zasilani zprav o zaplneni schranky.
Nyni je rada na Pandore a to aby zasilala v obalce zpravy adresu spravce konference a nikoliv adresu konference, jak cinila doposud.
Pevne verim, ze v soucasne chvili neexistuje duvod, proc by meli byt uzivatele Centra z Pandory vyrazeni (jak je uvedeno na titulni strance pandory)

Jako jeden ze zucastnenych jsem si se zajmem procetl clanek. Nejsem programator a tak mi dovolte jen laicke postrehy k problemu.

1) cloveka docela zamrzi, ze Lupa nechala misto pro vyjadreni pouze jedne strane. Rekl bych, ze to neni bezny postup, vypada to dost divne a Marek Antos na mne zna mobil i email. Pokud si nejste jisti, jak korektne postupovat pri psani clanku, mohu poskytnout nas redakcni Kodex.

2) ani programovani free konferenci neni tak jednoduche, jak by se zdalo. Predevsim nemuzeme z technickych duvodu dat do te hlavicky adresu odesilatele, musi tam zustat adresa konference. Vsude jinde to funguje, jen na Centru se objevil problem minuly patek a pretrvava, proto jsme blokovali posilani emailu smerem na Centrum.

3) dalsim prikladem netriviality free konferenci je Markem Antosem navrhovany hlidac mail bombingu. Mame ho a nepouziva se. duvod: lide, kteri pisi emaily offline a pak je odesilaji najednou, byly vyhodnoceni jako spameri a zablokovani. A takovych lidi je stale velke mnozstvi.

Zaver: situace se nepohne, dokud se programatori Centra a Pandory nedohodnou. U nas vule je.

Nikoli. MTA nemá povinnost hlásit nedoručitelnou poštu už při přijímání pošty a spousta populárních MTA (mám dojem, že např. qmail) se tak nechová. Nehledě na to, že netuším, jak by to změnilo situaci. Pokud by ochrana před chybovými maily byla zabezpečena jen při odesílání, musel by odesílač předpokládat, že vždy hovoří s cílovým MTA, což nemusí být pravda - na cestě může být zcela legálně relay a potom chybové hlášky dostanete pouze ve formě mailu, zkrátka proto, že tertia non datur.

Navratovy kod 552 je sice hezka vec, ale cela vec je bohuzel ponekud slozitejsi.

Nemam sice tuseni o tom, jak je prijem mailu implementovany na serveru Centrum, ale da se predpokladat, ze prijem pomoci SMTP obstarava nejaky program, ktery maily pouze ulozi do fronty. Odtud se pak presouvaji do databaze - a teprve pri tomto presunu se zjisti, ze uzivateli pretekla quota. Co s tim? Neni jina moznost, nez poslat mail s chybou, protoze spojeni, po kterem by byvalo slo vratit status 552, jiz davno neexistuje. To je vsak pouze implementacni detail, mozna to tak opravdu je, mozna neni, na tom prilis nesejde. Existuji totiz minimalne dva duvody, proc odpoved 552 nic neresi...

Za prve, co kdyz dany mail prichazi vice adresatum na danem serveru? Nejprve prijde seznam RCPT-TO, tedy adresy, na ktere se ma dopis dorucit. Pritom jeste neni mozne detekovat preteceni quoty, nebot neni znamo, jak dlouhy mail bude. Pak se precte vlastni mail a muze dojit k tomu, ze nekterym adresatum se do schranky vejde, ale jednomu ne. Jak nyni vratit chybovou hodnotu? SMTP protokol bohuzel nedovoluje v tomto miste specifikovat chybu pouze pro nektere adresaty. Takze neni jina moznost, nez poslat nazpet automaticky generovany mail s popisem chyby.

A za druhe, coz je jeste zavaznejsi, odpoved 552 vubec nepomuze! Jestlize server vrati "552 quota exceeded", SMTP agent (klient), ktery se snazil mail na dany server poslat, stejne vygeneruje chybovy mail na adresu odesilatele puvodni zpravy. Do tohoto mailu napise, ze obdrzel chybovou odpoved 552. Takze mail odesilateli je poslan stejne, pouze je anglicky a odeslany z jineho mista.

Takze kritizovat je sice pekne, ale bylo by dobre si navrhy dobre promyslet a predstavit si vsechny nasledky. Ono totiz provozovat freemailovy server je mnohem slozitejsi, nez by se na prvni pohled mohlo zdat... ;-)

Martin Kacer.

chyba je samozrejme i na strane pandory a jejimu autorovi to taky bude receno, az bude dostupny.
nicmene stale nechapu postup centra, ktery se zcela vymyka standardnimu chovani: pokud uzivateli dojde misto, mel by jejich mailer daemon vyhodit kod 552 ci 4xx dle RFC821 a ne odeslat mail odesilateli s tim, ze tomuto uzivateli dosla quota. kdyby se tedy centrum chovalo podle standardu, nedoslo by k temto problemum.

Michal Vitecek

Oni správcové Centra jsou dost pohodoví lidé. Posílal jsem jim několik dopisů, ale ani na jeden neodpověděli. Holt, co je jim po běžných uživatelích, že? I když jejich mail-daemon likviduje hlavičky přeposlaných dopisů, není důvod se znepokojovat. :-)

Omlouvam se, necetl jsem clanek dost pozorne. Pokud to skutecne je tak, jak to pisete vy, je chyba jednoznacne na strane Pandory.

Ale presne tohle delame!

Ja tedy nechci byt stoural, ale odpoved z Centra je velmi nepresna. Vsechny bounces se podle RFC821 MUSEJI posilat na adresu uvedenou v MAIL FROM: casti SMTP konverzace! Pokud se nejaky poblazneny mailer-daemon pokousi bouncovat zpravu na adresu uvedenou v RFC822 hlavicce, jen si koleduje o problemy - jak ostatne prave tento pripad dokazuje.

Jeste jednou opakuji, i pro ty natvrdlejsi spravce: Bounce se posila na adresu uvedenou v MAIL FROM:, nikoliv na adresu uvedenou ve From: ci Errors-To:!

Je bohuzel smutne, ze spravci freemailu nemaji prilis moc potuchy o platnych RFC. A je mozna skoda, ze Lupa pretiskne jejich vyjadreni, aniz by se pokusila o oponenturu jejich tvrzeni.