Konference, normy a hlavicky ...

Dan Lukes DAN at obluda.kolej.mff.cuni.cz
Thu Jun 13 17:16:51 CEST 1996


Tento dopis je ponekud delsi a tyka se problemu s teorii a normami.
Omlouvam se tedy vsem praktikum, ktere teoreticke otazky nudi jakozto i
vsem ostatnim, kteri teprve po precteni zjisti, ze je dany problem
nezajima.

Zaroven doufam, ze vratim trochu tuto konferenci k puvodnimu tematu teto
konference, tedy k diskusi o siti (a kdyz ne poctem prispevku, tak
alespon bajtu :-) )

**********************************************************************
Predchozi dopis pana Snajdra me vyprovokoval otevrit tady teoretickou
diskusi k vykladu nekterych norem, ktere me uz davno nejsou jasne.
Jedna se o obsah jednotlivych polozek v hlavicce mailu a take o vzajemny
vztah (nekdy protichudnych) udaju ziskanych z hlavicku dopisu (podle
RFC822) a z hlavicky SMTP session (podle RFC821).

Jde mi jak o teoreticky vyklad uvedenych dvou norem, jednak o
porobnani se vseobecne zabehanou praxi a to zejmena u dopisu
prochazejicich konferenci ...

Takze -
    "From:" je uplne jasne - ma uvadet duchovniho otce dopisu, nekoho, kdo
by teoreticky na jeho obsah mohl mit "(c)". To muze byt i (nepojmenovana)
skupina lidi. Na tuto adresu se pak posilaji odpovedi, pokud dalsi
polozka, Reply-To:, neurci jinak.

"To:" je jeste pomerne jasne - ma uvadet primarniho adresata zpravy, a
to i po pripadnem forwardovani (sekundarni adresat je pak v "resent-
to:"). Z toho tedy naproklad podle me vyplyva, ze pokud forwarduji do
konference zpravu, ktera byla puvodne pro me, konecni prijemci by stale v
"To:" meli mit moji adresu ... - to tedy ovsem jen tehdy, pokud prijmeme
nize diskutovany nazor, ze mail je konferenci forwardovan ...
(to timto mailem hned vyzkousim, nejdriv ho poslu sam sobe a pak teprve
do konference)

Nejasnosti zacinaji u polozky sender -
    je to oznaceni accountu, ze ktereho dopis skutecne odesel
(vase sekretarka, ktera jen psala diktovany dopis, sef
skupiny).  Zaroven je to ale podle normy adresa, na kterou se pak maji
posilat zpravy administrativniho charakteru (zpravy o doruceni/nedoruceni
a.p.). V pripade rozporu se nabizeji dve varianty vykladu:
   - sender je ten, komu se maji zasilat chybove hlasky
   - sender je skutecny odesilatel dopisu

Adresace typu 1:
V prvnim pripade je (po pruchodu konferenci) sender nastaven (vetsinou)
na ownera konference. Tim je vyreseno, kam posilat zpravy o chybach.
Ztrati se vsak informace o skutecnem odesilateli (dulezite napr. pokud
From: obsahuje skupinu lidi).
Tento zpusob je v soucasne dobe preferovan vetsinou distribucnich
programu.

Adresace typu 2:
V druhem pripade je sender casto nastaven na "adresu" programu, ktery
postu rozesilal (treba LISTSERV@ ...) - tento zpusob zda se mi byti uplne
nestastny, nejen ze se ztrati udaj o skutecnem odesilateli, ale jeste
jsou chybova hlaseni zasilana stroji (RFC822 uvadi, ze v pripade, ze
postu rozesila program by se mel sender vyplnovat na "spravce" programu).
Tento zpusob pouziva treba Novellovske Mercury.

Adresace typu 3:
Podle me, ovsem existuje jeste treti mozny zpusob, ktery se ale z me
neznameho duvodu nikde nepouziva. Pritom striktne dodrzuje normy a ani
neztraci informace. Proste se rekne, ze distribucni program prijatou
postu  FORWARDUJE koncovym prijemcum. Pak by hlavicka mela krome
jasnych To, From, resent-to a resent-from polozek, take jednoznacne
obsazeneho sendera (originalni odesilatel) a resent-sendera (ten, kdo
prijima chybove hlasky jmenem LISTSERVERu resp. spravce konference).
Muze mi nekdo naznacit, co jsem prehledl a co je tomto, podle me zcela
jednoznacnem a cistem reseni spatne, ze jej nikdo  nepouziva ?

V teto souvislosti by me pak zajimal puvodni smysl vzniku polozky
Errors-To:, ktera je u adresovaciho schematu prvniho (a tretiho) typu
zcela zbytecna. Vznikla snad v dobe, kdy se vic kladl duraz na tu cast
normy, kde je sender definovan jako skutecny odesilatel dopisu a po
pruchodu konferenci zustaval nezmenen (coz prinaselo problemy s
chybovymi hlasenimi, ktere mu pak odesilateli hojne prichazely) ?
Mimochodem, nepodarilo se mi najir RFC, ktera by Errors-To: kodifikovala.
Jde tedy stale o nenormovanou, USER-DEFINED polozku ?


Pro dalsi reseni je potreba sahnout po jeste jedne norme - SMTP
protokolu, RFC 821.

V dnesni dobe se zda, ze prakticky veskera posta je dorucovana na zaklade
udaju dodanych SMTP protokolem, nikoli na zaklade udaju uvedenych v
hlavicce dopisu. Typicky, dopis skonci v mail-boxu toho, kdo byl oznacen
pomoci RCPT To: v SMTP session, nikoli v To: z hlavicky. Chyby se take
vetsinou neposilaji podle hlavicky, ale podle Mail From:.
V pripade, ze Mail From: ze SMTP a adresa pro posilani chyb v hlavicce
zpravy nesouhlasi, komu se ma poslat chybova zprava ?
A pokud se me pokusite odkazat na to, ze to zavisi od toho, jestli chyba
vznikne jeste behem SMTP session, nebo az po jejim ukonceni, protoze se
jedna o dve v podstate nezavisle vrstvy, jake chyby pri dorucivani mohou
vzniknout po uspesnem prevzeti dopisu pomoci SMTP ? (Misto na disku,
platnost adresy, vsechno se overuje hned. Na co jsem zapomel ?)

Podotykam, ze neocekavam, ze vysledkem teto diskuse bude prohlaseni,
vetsina programu je (vzhledem k norme) spatne, vsechno se musi prepsat.
Dokonce neocekavam ani vysledek "normy neodpovidaji, nebo nedostacuji
soucasnemu stavu, toz napisme novou RFC822/821, ktera kodifikuje
stavajici praxi). Take jsem dobre obeznamen s tim, jak se posta dorucuje v
praxi.
Rad bych timto dotazem vyvolal spise teoretickou diskusi na tema, proc se
praxe odchylila od kodifikovaneho stavu a jestli a cim je to zpusobeno.
(pripadne ze se neodchylila, protoze muj vyklad norem je spatny)

                Predem diky za reakce.

                                            Dan Lukes

Dan Lukes, Patkova 3/B1206, Praha 8, Czech Republic
tel +42-(2)-8551040 ext 776, E-Mail: LUKES(or Postmaster)@Menza.MFF.CUNI.CZ

Dan Lukes, Patkova 3/B1206, Praha 8, Czech Republic
tel +42-(2)-8551040 ext 776, E-Mail: LUKES(or Postmaster)@Menza.MFF.CUNI.CZ



More information about the net mailing list