Vlákno názorů k článku Šťoura: Proč zahltilo Centrum konference? od Patrick Zandl - Pokud te zajima Kodex, poslu ho emailem. Stanovisko...

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

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.

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.

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.