🚀 go-pugleaf

Robert Richard George 'reptile' Wal wrote:
> 
> a.dom.com          - jaki¶ tam host
> b.dom.com          - inny host z zainstalowanym sendmailem
> c.dom.com          - CNAME do a.dom.com
> 
> Je¶li wysy³am list z b.dom.com przez "sendmail me@a.dom.com", a w
> nag³owkach stoi jasno:
> 
> To: cos@c.dom.com
> 
> to sendmail na b.dom.com przepisuje mi bezczelnie nag³ówek na:
> 
> To: cos@a.dom.com

Uzywanie aliasow w smtp jest nielegalne; niektore (wiekszosc) MTA
zamieniaja aliasy (w kopercie) na 'prawdziwe' nazwy przed dostarczeniem
poczty, sendmail przepisuje tez naglowki...


> Niby nic, ale w tej konkretnej sytuacji stanowi³o to jednak ró¿nice. Ja siê
> zatem zapytywujê, jak zmusiæ tego p...nego sendmaila, ¿eby nie rusza³ tego,
> co nie jego, bo u¿ytkownik ma zawsze mieæ ostatnie zdanie! Czyli, krótko
> mówi±c ,,dlaczego on mi przepisywa³ te nag³ówki tam gdzie nie pownien i jak
> tego w przysz³o¶ci unikn±æ''.

Zamiast CNAME uzyc A, tzn:

a.dom.com. IN A 1.2.3.4
b.dom.com. IN A 5.6.7.8
c.dom.com. IN A 1.2.3.4


i ew. wymienic MTA :)

________________________________________________________________________
    Artur Skawina     Received unsolicited commercial e-mail constitutes
http://linux.base.org    a request for site hacking to test security

Robert Richard George 'reptile' Wal <reptile@address.in.sig> pisze, co następuje:

> Niby nic, ale w tej konkretnej sytuacji stanowiło to jednak różnice.
> Ja się zatem zapytywuję, jak zmusić tego p...nego sendmaila, żeby
> nie ruszał tego, co nie jego, bo użytkownik ma zawsze mieć ostatnie
> zdanie! Czyli, krótko mówiąc ,,dlaczego on mi przepisywał te
> nagłówki tam gdzie nie pownien i jak tego w przyszłości uniknąć''.

Niech mnie TS poprawi, jeśli się mylę, ale zdaje się, że wystarczy w
sendmail.mc dopisać

FEATURE(nocanonify)

i ponownie wygenerować sendmail.cf

--a
   ___ ___   -------------------------------------------------------
  / _ | _ )   Artur "Archie" Bartnicki      praca: (0-71)  48 82 70
 / __ | _ \   mailto:archie@insert.com.pl   dom  : (0-601) 79 88 72
/_/ |_|___/  -------------------------------------------------------

Prayers are always answered; the answer is usually "NO!".

Artur Skawina (linux@base.org) wrote on Wed, 11 Feb 1998 05:11:16 +0100:
AS> Robert Richard George 'reptile' Wal wrote:
>> 
>> a.dom.com          - jakiś tam host
>> b.dom.com          - inny host z zainstalowanym sendmailem
>> c.dom.com          - CNAME do a.dom.com
>> 
>> Jeśli wysyłam list z b.dom.com przez "sendmail me@a.dom.com", a w
>> nagłowkach stoi jasno:
>> 
>> To: cos@c.dom.com
>> 
>> to sendmail na b.dom.com przepisuje mi bezczelnie nagłówek na:
>> 
>> To: cos@a.dom.com

AS> Uzywanie aliasow w smtp jest nielegalne; niektore (wiekszosc) MTA

Wiesz że dzwonią, ale nie wiesz w którym kościele :-)
Owszem, jeżeli gdzieś jest w DNS wpisane:

	c.dom.com	IN CNAME	a.dom.com

To NIE MOŻNA użyć c.dom.com po prawej stronie rekordu MX, np:

	b.dom.com	IN MX 10	c.dom.com ; ZLE!!!

natomiast poza tym, nie ma niczego nielegalnego w używaniu aliasów
(tzn. CNAME) w poczcie.  Aby to jednak działało, zgodnie z odpowiednimi
RFC, podczas dokonywania "kanonizacji" adresów i określania dokąd tę
pocztę dostarczyć, każdy taki adres jest przepisywany na kanoniczny,
czyli w tym przypadku - a.dom.com.

AS> zamieniaja aliasy (w kopercie) na 'prawdziwe' nazwy przed dostarczeniem
AS> poczty, sendmail przepisuje tez naglowki...

>> Niby nic, ale w tej konkretnej sytuacji stanowiło to jednak różnice. Ja się
>> zatem zapytywuję, jak zmusić tego p...nego sendmaila, żeby nie ruszał tego,

FEATURE(nocanonify) może pomóc, ale jako efekt uboczny, za to buć
może psując inne rzeczy (zależnie od konkretnej konfiguracji), natomiast
warto zajrzeć do cf/README, by znaleźć:

confDONT_EXPAND_CNAMES  DontExpandCnames
	[False] If set, $[ ... $] lookups that do DNS based lookups do
	not expand CNAME records.  This currently violates the published
	standards, but the IETF seems to be moving toward legalizing this.
	For example, if "FTP.Foo.ORG" is a CNAME for "Cruft.Foo.ORG", then
	with this option set a lookup of "FTP" will return "FTP.Foo.ORG";
	if clear it returns "Cruft.FOO.ORG".  N.B.  you may not see any
	effect until your downstream neighbors stop doing CNAME lookups
	as well.

Co m.in. oznacza, że przepisywanie CNAME dzieje się u WYSYŁAJĄCEGO MTA,
a nie tylko odbierającego, więc w efekcie - nie ma sposobu na wyłaczenie
tego, dopóki nazwa zdefiniowana jest przez CNAME.

>> co nie jego, bo użytkownik ma zawsze mieć ostatnie zdanie! Czyli, krótko
>> mówiąc ,,dlaczego on mi przepisywał te nagłówki tam gdzie nie pownien i jak
>> tego w przyszłości uniknąć''.

Powinien, powinien. :-)

AS> Zamiast CNAME uzyc A, tzn:

AS> a.dom.com. IN A 1.2.3.4
AS> b.dom.com. IN A 5.6.7.8
AS> c.dom.com. IN A 1.2.3.4

Owszem, ale wówczas trzeba także samemu zadbać o to, by nazwa c.dom.com
znalazła się w klasie w, czyli 'Cw c.dom.com', bo inaczej może się okazać,
że poczta zacznie być odbijana z 'local configuration error'.

AS> i ew. wymienic MTA :)

Na takiego, co nie spełnia RFC?  I na wszystkich komputerach na świecie?
Bo IMHO to nie pomoże :-)

-- 
 _________
(_   _' __) Tomasz R. Surmacz *-* Work:(071)3202636, tsurmacz@ict,pwr,wroc,pl
  |  (__  \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *--* Home: ts @wroc,apk,net
  |__(____/ For PGP key finger tsurmacz@cyber.ict,pwr,wroc.pl *-* irc: TomekS

Tomasz Surmacz wrote:
> 
> AS> Uzywanie aliasow w smtp jest nielegalne; niektore (wiekszosc) MTA
> 
> Wiesz ¿e dzwoni±, ale nie wiesz w którym ko¶ciele :-)

RTFRFC


> AS> i ew. wymienic MTA :)
      ^
> 
> Na takiego, co nie spe³nia RFC?  I na wszystkich komputerach na ¶wiecie?
> Bo IMHO to nie pomo¿e :-)

"i", a nie "lub"

________________________________________________________________________
    Artur Skawina     Received unsolicited commercial e-mail constitutes
http://linux.base.org    a request for site hacking to test security

Artur Skawina (linux@base.org) wrote on Wed, 11 Feb 1998 23:06:06 +0100:
AS> Tomasz Surmacz wrote:
>> 
>> AS> Uzywanie aliasow w smtp jest nielegalne; niektore (wiekszosc) MTA
>> 
>> Wiesz że dzwonią, ale nie wiesz w którym kościele :-)

AS> RTFRFC

Oświeć mnie, dyletanta, dlaczegóż to pisanie na adres tsurmacz@news.ict.-
pwr.wroc.pl (CNAME okapi.ict.pwr.wroc.pl), które jakby nie było, *jest*
używaniem aliasów w smtp, ma być nielegalne?

>> AS> i ew. wymienic MTA :)
AS>       ^
>> 
>> Na takiego, co nie spełnia RFC?  I na wszystkich komputerach na świecie?
>> Bo IMHO to nie pomoże :-)

AS> "i", a nie "lub"

Skoro wymienić IN CNAME na IN A (co jest warunkiem koniecznym
*I WYSTARCZAJĄCYM*), to po cóż jeszcze 'I' MTA?

-- 
 _________
(_   _' __) Tomasz R. Surmacz *-* Work:(071)3202636, tsurmacz@ict,pwr,wroc,pl
  |  (__  \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *--* Home: ts @wroc,apk,net
  |__(____/ For PGP key finger tsurmacz@cyber.ict,pwr,wroc.pl *-* irc: TomekS

Tomasz Surmacz wrote:
> 
> Artur Skawina (linux@base.org) wrote on Wed, 11 Feb 1998 23:06:06 +0100:
> AS> Tomasz Surmacz wrote:
> >>
> >> AS> Uzywanie aliasow w smtp jest nielegalne; niektore (wiekszosc) MTA
> >>
> >> Wiesz że dzwonią, ale nie wiesz w którym kościele :-)
> 
> AS> RTFRFC
> 
> Oświeć mnie, dyletanta, dlaczegóż to pisanie na adres tsurmacz@news.ict.-
> pwr.wroc.pl (CNAME okapi.ict.pwr.wroc.pl), które jakby nie było, *jest*
> używaniem aliasów w smtp, ma być nielegalne?

"Pisanie" na adres <tsurmacz@news.ict.pwr.wroc.pl> i dostarczenie emaila
do <tsurmacz@okapi.ict.pwr.wroc.pl> to sa dwie rozne rzeczy. Jesli uzyty
jest SMTP to <tsurmacz@news.ict.pwr.wroc.pl> nie moze [1] wystapic jako
argument MAIL FROM lub RCPT TO.


> >> AS> i ew. wymienic MTA :)
> AS>    ^
> >>
> >> Na takiego, co nie spełnia RFC?  I na wszystkich komputerach na świecie?
> >> Bo IMHO to nie pomoże :-)
> 
> AS> "i", a nie "lub"
> 
> Skoro wymienić IN CNAME na IN A (co jest warunkiem koniecznym
> *I WYSTARCZAJĄCYM*), to po cóż jeszcze 'I' MTA?

Bo pytanie brzmialo "dlaczego on mi przepisywał te nagłówki tam gdzie 
nie pownien i jak tego w przyszłości uniknąć".

Jesli to rzeczywiscie sendmail przepisywal te naglowki (a nie jakis
FE/MUA), to wymiana MTA na taki, ktory nie modyfikuje _tresci_ emaila
(a tylko ew. 'poprawia' koperte) moze pomoc w przyszlosci [2].

artur


[1] przynajmniej nie powinien :)

[2] _formalnie_ [3] uzywanie aliasow w naglowkach tez jest
    nielegalne, ale w tym przypadku nie ma to zadnego znaczenia
    (naglowki nie sa uzywane podczas dostarczania poczty, a maja
    znaczenie tylko dla MUAs); zreszta <tsurmacz@okapi.ict.pwr.wroc.pl>
    tez jest nielegalnym adresem w/g [3] :)

[3] RFC0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982.
     (Also STD0010) (Status: STANDARD)


________________________________________________________________________
    Artur Skawina     Received unsolicited commercial e-mail constitutes
http://linux.base.org    a request for site hacking to test security

Fri, 13 Feb 1998 03:48:15 +0100, Artur Skawina na pl.comp.mail.mta napisał:
>[2] _formalnie_ [3] uzywanie aliasow w naglowkach tez jest
>    nielegalne, ale w tym przypadku nie ma to zadnego znaczenia
>    (naglowki nie sa uzywane podczas dostarczania poczty, a maja
>    znaczenie tylko dla MUAs); zreszta <tsurmacz@okapi.ict.pwr.wroc.pl>
>    tez jest nielegalnym adresem w/g [3] :)
>
>[3] RFC0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982.
>     (Also STD0010) (Status: STANDARD)

może jeszcze napiszesz dlaczego (poza faktem aliasowania)
tsurmacz@okapi.ict.pwr.wroc.pl jest nielegalne? (bo sugerujesz że i
dla innych powodów...)

-- 
Ziemek Borowski                 http://faq-bot.usenet.pl/ 

On 98.02.13 Artur Skawina pressed the following keys:

> Bo pytanie brzmialo "dlaczego on mi przepisywał te nagłówki tam gdzie 
> nie pownien i jak tego w przyszłości uniknąć".
> 
> Jesli to rzeczywiscie sendmail przepisywal te naglowki (a nie jakis
> FE/MUA), to wymiana MTA na taki, ktory nie modyfikuje _tresci_ emaila
> (a tylko ew. 'poprawia' koperte) moze pomoc w przyszlosci [2].

O żesz Ty... No trzymajcie mnie bo nie zdzierżę! Zapewniam, że nie jestem
,,użytkownikiem quake'a' :) Sprawdziłem wszystko, er-te-ef-ema-łem długo
zanim polazłem zadawać głupie[1] pytania, wyedytowałem sobie ~/Mailbox, do
którego żaden MUA się nie dotykał, jeno mój qmail. Dodatkowo
przeprowadziłem kilka testów, żeby sprawdzić, na którym komputerze działa
się podmiana. Działa się na komputerze wysyłającym, na którym był sendmail.
Qmail takich rzeczy nie robił. I o to mi chodzi, że Sendmail raczej nie
powienien ruszać nagłowków, bo mu do niczego potrzebne nie są. Nie mam
pojęcia po jaką cholerę przepisuje nagłowki, które w żaden sposób nie biorą
udziału w transporcie poczty (chyba, że jako pasażer :). Kiedyś na systemie
z sendmailem z .cf-ami rozbabranymi poza granicę dobrego smaku działy się
jeszcze ciekawsze rzeczy, bo przepisywał nagłowki listów _przechodzących_
przez niego. To znaczy listy, które przechodziły przez niego w świat z
polem

>From: reptile@b.com

miały przepisywane to pole na

>From: reptile@a.b.com

kiedy używałem tego komputera jako smtp_smarter_host. Akurat nie stanowiło
to różnicy, bo MX-y do obu domen wskazywały na ten sam komputer, ale
wkurzało :)

Moje doświadczenie mówi mi, że więcej kłopotu z tym ,,feature'' niż
pożytku z niego płynącego. Nagłówki to zabawka, która ma cieszyć
odbiorcę listu[2], a MTA pownna interesować jedynie koperta. Ale nic to,
qmail takich rzeczy mi nie robi, więc kiedy już pewnego dnia zarżnę
ostatnią kopię sendmaila w mojej okolicy, przestanę się tym martwić :)

A jeśli idzie o rozwiązanie mojego problemu, to leżało ono dość blisko
sugerowanych kroków, ale nie dokładnie tam, gdzie wskazywaliście. Celem
ćwiczenia było uzyskanie wirtualnego hosta pocztowego, który realizuje się
na innym hoście i po przeanalizowaniu dogłębnie zagadnienia doszedłem do
wniosku, że powinno to być realizowane podobnie jak domena UUCP. Więc
wywaliłem CNAME i wstawiłem na DNS:

c	IN	MX 10	a

Od tamtej chwili ruszyło od kopa i żadne MTA mi się nie
wpier^H^H^H^H^Hczepia :))

Gadzinka

[1] czyt. banalne

[2] patrz moje nagłowki :)

-- 
                                 mailto:reptile@pdi.net :)
                  Women are more complicated than PC... :(
          Look into my headers and you'll see who I am. :)

Artur Skawina <linux@base.org> wrote:
: Tomasz Surmacz wrote:
: > >> AS> Uzywanie aliasow w smtp jest nielegalne; niektore (wiekszosc) MTA
: > >>
: > >> Wiesz że dzwonią, ale nie wiesz w którym kościele :-)
: > 
: > AS> RTFRFC
: > 
: > Oświeć mnie, dyletanta, dlaczegóż to pisanie na adres tsurmacz@news.ict.-
: > pwr.wroc.pl (CNAME okapi.ict.pwr.wroc.pl), które jakby nie było, *jest*
: > używaniem aliasów w smtp, ma być nielegalne?

: "Pisanie" na adres <tsurmacz@ news.ict.pwr.wroc.pl> i dostarczenie emaila
: do <tsurmacz@ okapi.ict.pwr.wroc.pl> to sa dwie rozne rzeczy. Jesli uzyty

Owszem.

: jest SMTP to <tsurmacz@ news.ict.pwr.wroc.pl> nie moze [1] wystapic jako
: argument MAIL FROM lub RCPT TO.

Może.  Tyle, że pierwszy MTA, jaki taki list przetwarza, poprzerabia
wszystkie CNAME na 'the only one true name', czyli w tym przypadku
ts@news.ict... na ts@okapi.ict...

: Jesli to rzeczywiscie sendmail przepisywal te naglowki (a nie jakis
: FE/MUA), to wymiana MTA na taki, ktory nie modyfikuje _tresci_ emaila
: (a tylko ew. 'poprawia' koperte) moze pomoc w przyszlosci [2].

każdy MTA to robi, bo tak właśnie to musi działać.  Jakby tak nie
było, to poczta mogłaby sobie krążyć do upadłego, a p rzy najmniejszych
problemach z DNS (który na skutek keszowania wcale nie musi wszędzie dawać
identycznych danych) hosty docelowe nie rozpoznawałyby swoich własnych
(CNAME-owanych) nazw.

: [1] przynajmniej nie powinien :)

nic nie stoi na przeszkodzie.

: [2] _formalnie_ [3] uzywanie aliasow w naglowkach tez jest
:     nielegalne, ale w tym przypadku nie ma to zadnego znaczenia

Niby dlaczego?  Poproszę dokładny numerek RFC i numer linii lub rozdziału.

:     (naglowki nie sa uzywane podczas dostarczania poczty, a maja
:     znaczenie tylko dla MUAs); zreszta <tsurmacz@okapi.ict.pwr.wroc.pl>
:     tez jest nielegalnym adresem w/g [3] :)

Coś ci się z okazji 13. w piątek poprzestawiało czy co?  Że niby jak?
To jaki powinien być poprawny?  tsurmacz@[156.17.42.30]?

: [3] RFC0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982.
:      (Also STD0010) (Status: STANDARD)

RFC 821 nic nie mówi na temat tego co jest, a co nie jest poprawnym
adresem w RCPT TO: ani w MAIL FROM:, a już w szczególności *dokładnie
nic* w nim nie ma na temat CNAME...  Nie mówi też nic o nagłówkach --
tego dotyczy RFC822.

Szczerze ubawiony,

Tomek

-- 
 _________
(_   _' __) Tomasz R. Surmacz *--* Work:(071)320-2752 tsurmacz@ict.pwr,wroc.pl
  |  (__  \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *---* Home: ts @wroc,apk,net
  |__(____/ For PGP key finger tsurmacz@asic.ict,pwr,wroc.pl *---* irc: TomekS

Ziemek Borowski wrote:
> 
> >    znaczenie tylko dla MUAs); zreszta <tsurmacz@okapi.ict.pwr.wroc.pl>
> >    tez jest nielegalnym adresem w/g [3] :)
> >
> >[3] RFC0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982.
> >     (Also STD0010) (Status: STANDARD)
> 
> może jeszcze napiszesz dlaczego (poza faktem aliasowania)
> tsurmacz@okapi.ict.pwr.wroc.pl jest nielegalne? (bo sugerujesz że i
> dla innych powodów...)

Powyzej jest wyraznie napisane, ze w/g obowiazujacego obecnie stdu
SMTP czyli rfc821 :) [1]


artur

[1] Wymaga on, aby kazdy 'element' domeny wystepujacej jako argument
    komend SMTP mial co najmniej trzy znaki...

________________________________________________________________________
    Artur Skawina     Received unsolicited commercial e-mail constitutes
http://linux.base.org    a request for site hacking to test security

Robert Richard George 'reptile' Wal wrote:
> 
> On 98.02.13 Artur Skawina pressed the following keys:
> 
> > Bo pytanie brzmialo "dlaczego on mi przepisywał te nagłówki tam gdzie
> > nie pownien i jak tego w przyszłości uniknąć".
> >
> > Jesli to rzeczywiscie sendmail przepisywal te naglowki (a nie jakis
> > FE/MUA), to wymiana MTA na taki, ktory nie modyfikuje _tresci_ emaila
> > (a tylko ew. 'poprawia' koperte) moze pomoc w przyszlosci [2].
[...]
> Qmail takich rzeczy nie robił. I o to mi chodzi, że Sendmail raczej nie
> powienien ruszać nagłowków, bo mu do niczego potrzebne nie są. Nie mam
> pojęcia po jaką cholerę przepisuje nagłowki, które w żaden sposób nie biorą
> udziału w transporcie poczty (chyba, że jako pasażer :). Kiedyś na systemie
[...]
> pożytku z niego płynącego. Nagłówki to zabawka, która ma cieszyć
> odbiorcę listu[2], a MTA pownna interesować jedynie koperta. Ale nic to,

Amen :)


> A jeśli idzie o rozwiązanie mojego problemu, to leżało ono dość blisko
> sugerowanych kroków, ale nie dokładnie tam, gdzie wskazywaliście. Celem
[...]
> wywaliłem CNAME i wstawiłem na DNS:
> 
> c       IN      MX 10   a

Oba rozwiazania sa dobre [1] [3] jesli 'host' ma sluzyc tylko do poczty.


artur


[1] chociaz sa programy nazywajace sie "MTA" [2], ktore nie akceptuja
    poczty od/do hostow, ktore nie maja zadnego MXa; wiec MX moze byc
    lepszy A, bo pozwala na wspolprace z takimi "MTA".

[2] np _podobno_ nowsze wersje smail, ale osobiscie nie sprawdzalem.

[3] uzycie MX zmniejsza tez troche ruch DNS.

________________________________________________________________________
    Artur Skawina     Received unsolicited commercial e-mail constitutes
http://linux.base.org    a request for site hacking to test security

Tomasz R. Surmacz wrote:
> 
> : jest SMTP to <tsurmacz@ news.ict.pwr.wroc.pl> nie moze [1] wystapic jako
> : argument MAIL FROM lub RCPT TO.
> 
> Może.  Tyle, że pierwszy MTA, jaki taki list przetwarza, poprzerabia
> wszystkie CNAME na 'the only one true name', czyli w tym przypadku
> ts@news.ict... na ts@okapi.ict...

Nie moze. Istnieja MTA (Message Transfer Agent) i MUA (Mail User Agent).
"Kanonizacja" adresow jest zadaniem MUA, powinno to nastapic _przed_
transportem wiadosci via SMTP. Analogicznie 'przepisywanie' naglowkow
jest takze zadaniem MUA, i nie powinno byc robione przez MTA.
W niektorych sytuacjach granica MUA/MTA moze byc rozmyta (np gdy "MUA"
faktycznie to FE (Front End) MTA), ale zasada powinna byc ta sama.
Czyli np OK jest przepisywanie naglowkow przez MTA jesli wiadomosc _nie_
zostala odebrana via SMTP, ale pochodzi z innego zrodla; natomiast
ingerencja w _naglowki_ wiadomosci odebranej poprzez SMTP nie powinna
miec miejsca (naglowki powinny byc tylko dodawane (Received etc), a
koperta _moze_ byc poprawiona, aby ulatwic zadanie innym MTA (i
uzytkownikom, bo alternatywa bylaby odmowa dostarczenia wiadomosci
wogole)).


> : Jesli to rzeczywiscie sendmail przepisywal te naglowki (a nie jakis
> : FE/MUA), to wymiana MTA na taki, ktory nie modyfikuje _tresci_ emaila
> : (a tylko ew. 'poprawia' koperte) moze pomoc w przyszlosci [2].
> 
> każdy MTA to robi, bo tak właśnie to musi działać.  Jakby tak nie

Robi to np sendmail, nie robi np qmail. Poprawnie dzialajacy MTA (nie
dotyczy GW) nie ingeruje w zawartosc wiadomosci, o ile to nie jest konieczne.


> było, to poczta mogłaby sobie krążyć do upadłego, a p rzy najmniejszych

Naglowki nie biora wogole udzialu w dostarczeniu poczty. [1]


> problemach z DNS (który na skutek keszowania wcale nie musi wszędzie dawać
> identycznych danych) hosty docelowe nie rozpoznawałyby swoich własnych
> (CNAME-owanych) nazw.
> 
> : [1] przynajmniej nie powinien :)
> 
> nic nie stoi na przeszkodzie.

oprocz stdu SMTP :) [2]


> : [2] _formalnie_ [3] uzywanie aliasow w naglowkach tez jest
> :     nielegalne, ale w tym przypadku nie ma to zadnego znaczenia
> 
> Niby dlaczego?  Poproszę dokładny numerek RFC i numer linii lub rozdziału.

Prosze bardzo, nie jestes pierwszy; nawet moge ci zacytowac odp kawalek :) :
----------------------------------------------------------------------
rfc822> A domain-ref must be THE official name of a registry, network,
rfc822> or  host.   It  is  a  symbolic  reference, within a name sub-
----------------------------------------------------------------------


> :     (naglowki nie sa uzywane podczas dostarczania poczty, a maja
> :     znaczenie tylko dla MUAs); zreszta <tsurmacz@okapi.ict.pwr.wroc.pl>
> :     tez jest nielegalnym adresem w/g [3] :)
> 
> Coś ci się z okazji 13. w piątek poprzestawiało czy co?  Że niby jak?
> To jaki powinien być poprawny?  tsurmacz@[156.17.42.30]?

tsurmacz@[156.17.42.30], a nawet tsurmacz@#2618370590 sa poprawnymi
adresami w SMTP, tsurmacz@okapi.ict.pwr.wroc.pl _formalnie_ nie jest :)
[dlaczego juz pisalem w innym poscie, jest to zreszta jednoznacznie
 opisane w rfc821]


> : [3] RFC0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982.
> :      (Also STD0010) (Status: STANDARD)
> 
> RFC 821 nic nie mówi na temat tego co jest, a co nie jest poprawnym
> adresem w RCPT TO: ani w MAIL FROM:, a już w szczególności *dokładnie
> nic* w nim nie ma na temat CNAME... 

Hmm, albo mamy rozne wersje rfc821, albo ktorys z nas 'czyta inaczej'... :^)

[dla unikniecia wszelkich nieporozumien: powyzsze to zart. RFC0821
 _zawiera_ poprawna skladnie komend SMTP [RFC0821: 4.1.2. "COMMAND SYNTAX"],
 przed kontynuacja tej dyskusji proponuje ja najpierw dokladnie
 przestudiowac :) (a takze fragmenty zacytowane w [2])]
 

> Nie mówi też nic o nagłówkach --
> tego dotyczy RFC822.

Owszem, wiec ponizej patch do mojego poprzedniego postu w tym watku :) :
--------------------------------------------------------------------------
- [2] _formalnie_ [3] uzywanie aliasow w naglowkach tez jest
+ [2] _formalnie_ [2a] uzywanie aliasow w naglowkach tez jest
      nielegalne, ale w tym przypadku nie ma to zadnego znaczenia
      (naglowki nie sa uzywane podczas dostarczania poczty, a maja
      znaczenie tylko dla MUAs); zreszta <tsurmacz@okapi.ict.pwr.wroc.pl>
      tez jest nielegalnym adresem w/g [3] :)
+
+ [2a] RFC0822 Standard for the format of ARPA Internet text messages. D.
+       Crocker. Aug-13-1982. (Also STD0011) (Status: STANDARD)
  [3] RFC0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982.
       (Also STD0010) (Status: STANDARD)
--------------------------------------------------------------------------

> Szczerze ubawiony,

Rzeczywiscie ta dyskusja powinna znalezc sie na pl.listserv.chomor-l etc,
ale obawiam sie, ze % ubawionych czytelnikow bylby znacznie mniejszy :) 


artur


[1] moga byc wykorzystane przez MUA do skontruowania koperty.


[2] OK, wiec jak dla 'czytajacych inaczej' :) :
--------------------------------------------------------------------------
rfc821> Whenever domain names are used in SMTP only the official names are
rfc821> used, the use of nicknames or aliases is not allowed.

rfc821> Hosts are generally known by names which are translated to
rfc821> addresses in each host.  Note that the name elements of domains
rfc821> are the official names -- no use of nicknames or aliases is
rfc821> allowed.
--------------------------------------------------------------------------

Wystarczy, czy jeszcze przetlumaczyc na polski? ;)


________________________________________________________________________
    Artur Skawina                        All MTA designers are arrogant.
http://linux.base.org                    Goes with the territory... :)

Artur Skawina <linux@base.org> wrote:
: Tomasz R. Surmacz wrote:

: > :     (naglowki nie sa uzywane podczas dostarczania poczty, a maja
: > :     znaczenie tylko dla MUAs); zreszta <tsurmacz@okapi.ict.pwr.wroc.pl>
: > :     tez jest nielegalnym adresem w/g [3] :)
: > 
: > Coś ci się z okazji 13. w piątek poprzestawiało czy co?  Że niby jak?
: > To jaki powinien być poprawny?  tsurmacz@[156.17.42.30]?

: tsurmacz@[156.17.42.30], a nawet tsurmacz@#2618370590 sa poprawnymi
: adresami w SMTP, tsurmacz@okapi.ict.pwr.wroc.pl _formalnie_ nie jest :)

Żeby były poprawnymi, to jeszcze musiałoby się dać na taki adres
dostarczyć pocztę, a gwarantuję ci, że na tsurmacz@#2618370590 się nie
da :-)  Ale to tak na marginesie...

...

: + [2] _formalnie_ [2a] uzywanie aliasow w naglowkach tez jest
:       nielegalne, ale w tym przypadku nie ma to zadnego znaczenia
:       (naglowki nie sa uzywane podczas dostarczania poczty, a maja
:       znaczenie tylko dla MUAs); zreszta <tsurmacz@ okapi.ict.pwr.wroc.pl>
:       tez jest nielegalnym adresem w/g [3] :)
:
: [2] OK, wiec jak dla 'czytajacych inaczej' :) :
: --------------------------------------------------------------------------
: rfc821> Whenever domain names are used in SMTP only the official names are
: rfc821> used, the use of nicknames or aliases is not allowed.
:
: rfc821> Hosts are generally known by names which are translated to
: rfc821> addresses in each host.  Note that the name elements of domains
: rfc821> are the official names -- no use of nicknames or aliases is
: rfc821> allowed.
: --------------------------------------------------------------------------

: Wystarczy, czy jeszcze przetlumaczyc na polski? ;)

Przetłumaczyć.  A raczej wytłumaczyć co ci się nie podoba w nazwie
okapi.ict.pwr.wroc.pl?  Bo może ja mam inny DNS, albo już nie wiem co...
Na wszelki wypadek podaję jak to widać u mnie, bo być może małe zielone
pożeracze pakietów po drodze robią jakieś przekłamania i u ciebie widać
coś innego?

44 okapi:~> host -t any okapi.ict.pwr.wroc.pl.
okapi.ict.pwr.wroc.pl   A       156.17.42.30
okapi.ict.pwr.wroc.pl   MX      okapi.ict.pwr.wroc.pl
okapi.ict.pwr.wroc.pl   MX      lart.ict.pwr.wroc.pl
okapi.ict.pwr.wroc.pl   HINFO   "SUN"   "UNIX"
okapi.ict.pwr.wroc.pl   WKS     156.17.42.30 tcp ( daytime smtp time nntp )
okapi.ict.pwr.wroc.pl   WKS     156.17.42.30 udp ( daytime time name )

-- 
 _________
(_   _' __) Tomasz R. Surmacz *--* Work:(071)320-2752 tsurmacz@ict.pwr,wroc.pl
  |  (__  \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *---* Home: ts @wroc,apk,net
  |__(____/ For PGP key finger tsurmacz@asic.ict,pwr,wroc.pl *---* irc: TomekS

Tomasz R. Surmacz wrote:
> 
> : > :     znaczenie tylko dla MUAs); zreszta <tsurmacz@okapi.ict.pwr.wroc.pl>
> : > :     tez jest nielegalnym adresem w/g [3] :)
> : >
> : > Co¶ ci siê z okazji 13. w pi±tek poprzestawia³o czy co?  ¯e niby jak?
> : > To jaki powinien byæ poprawny?  tsurmacz@[156.17.42.30]?
> 
> : tsurmacz@[156.17.42.30], a nawet tsurmacz@#2618370590 sa poprawnymi
> : adresami w SMTP, tsurmacz@okapi.ict.pwr.wroc.pl _formalnie_ nie jest :)
> 
> ¯eby by³y poprawnymi, to jeszcze musia³oby siê daæ na taki adres
> dostarczyæ pocztê, a gwarantujê ci, ¿e na tsurmacz@#2618370590 siê nie
> da :-)  Ale to tak na marginesie...

Zawsze myslalem, ze o poprawnosci lub nie- decyduje std, a nie to
czy jakas implementacja jest z nim w pelni zgodna... :) Ale to tak
na marginesie :)

[Przeciez _cala_ ta dyskusja jest o jednym przypisie, ktory mial
 mial na celu jedynie pokazanie, ze dzisiaj nie mozna doslownie
 interpretowac niektorych RFC, ktore byly pisane 15+ lat temu, obowiazuja,
 nie sa poprawione, mimo ze  niektore ich wymagania sa absurdalne;
 i praktycznie wszystkie MTA je ignoruja :) ]


> : --------------------------------------------------------------------------
> : rfc821> Whenever domain names are used in SMTP only the official names are
> : rfc821> used, the use of nicknames or aliases is not allowed.
> :
> : rfc821> Hosts are generally known by names which are translated to
> : rfc821> addresses in each host.  Note that the name elements of domains
> : rfc821> are the official names -- no use of nicknames or aliases is
> : rfc821> allowed.
> : --------------------------------------------------------------------------
> 
> : Wystarczy, czy jeszcze przetlumaczyc na polski? ;)
> 
> Przet³umaczyæ.

_Ten_ (powyzszy) cytat byl odpowiedzia na pytanie dlaczego uzywanie
CNAMEs w SMTP jest nielegalne (i komentarzem do "nic nie stoi na 
przeszkodzie" i "RFC 821 nic nie mówi na temat [...], a ju¿ w 
szczególno¶ci *dok³adnie nic* w nim nie ma na temat CNAME").

Nie sadzie, zebym musial go tlumaczyc (jesli sie myle to chetnie
to zrobie), a nie ma on nic wspolnego z 'legalnoscia' adresu
o ktorym byla mowa.


>  A raczej wyt³umaczyæ co ci siê nie podoba w nazwie
> okapi.ict.pwr.wroc.pl? 

Mi - nic :) (no, moze jest troche za dluga ;^) )

Przeciez za kazdym razem zaznaczam, ze _formalnie_ jest nielegalna :)
[tzn jesli wystapi w SMTP]
Dlaczego? - Skladnia podana w rfc821 (# rozdzialu byl w poprzednim
poscie) wymaga aby kazdy 'element' (czlon) domeny skladal sie z
przynajmniej trzech znakow. Czyli _wszystkie_ cTLD sa 'nielegalne' 
w SMTP... :) IOW _kazdy_ adres np konczacy sie na .pl, .se, .de etc.

Chodzilo o to, ze o ile wystapienie aliasow w naglowkach tez
w zasadzie jest 'nielegalne' (odp cytat z RFC0822 byl w poprzednim
poscie), to nie ma zadnych _technicznych_ przeciwskazan, ani
koniecznosci modyfikacji naglowkow przez MTA.  MTA moze
zignorowac ten kawalek RFC (i tak _kazdy_ [1] MTA ignoruje niektore
inne, mniej lub bardziej absurdalne, wymagania, przyklady powyzej).

Ta 'nielegalnosc' aliasow w naglowkach jest powodem, dla ktorego
sendmail przepisuje te naglowki, a pierwotne pytanie brzmialo (m.in.): 
"dlaczego on mi przepisywa³ te nag³ówki" - przepisuje bo tego wymaga
 ^^^^^^^^
RFC0822 (w zasadzie wymaga od MUA, ale sendmail stara sie 'poprawic'
po 'broken' MUAs).


> Bo mo¿e ja mam inny DNS, albo ju¿ nie wiem co...
> Na wszelki wypadek podajê jak to widaæ u mnie, bo byæ mo¿e ma³e zielone
> po¿eracze pakietów po drodze robi± jakie¶ przek³amania i u ciebie widaæ
> co¶ innego?

nie sprawdzalem :)


artur


[1] przynajmniej sie nie spotkalem z takim co by odmowil dostarczenia
    poczty, i to nawet jesli ktorys czlon domeny skladal sie z tylko
    jednego znaku :)

________________________________________________________________________
    Artur Skawina                        All MTA designers are arrogant.
http://linux.base.org                    Goes with the territory... :)