3com system/management/alertNaime, skontao sam da 3com sw apsolutno ne postuje RFC822 tj RFC2821. Evo dump-a sesije koju je pravio 3com switch prilikom konektovanja na mail server kako bi "poslao" mail:
[session start]
tcpserver: pid 18480 from 172.16.1.60
tcpserver: ok 18480 0:172.16.1.200:25 :172.16.1.60::2070
18480 > 220 mx1.server.com ESMTP^M
18480 < HELO [172.16.1.200]^M
18480 > 250 mx1.server.com^M
18480 < Mail From:<[email protected]>^M
18480 > 250 ok^M
18480 < RCPT TO:<[email protected]>^M
18480 > 250 ok^M
18480 < DATA^M
18480 > 354 go ahead^M
18480 < From:[email protected]^M
18480 < Subject:Event from 3Com SuperStack 3^M
18480 < To:[email protected]^M
18480 < cc:^M
18480 < ^M
18480 < From device 3Com SuperStack 3 (172.16.1.60):
18480 <
18480 < This is a generic test alert.
18480 <
18480 < ^M
18480 < .^M
18480 > 451 Bare LFs in SMTP check^M
tcpserver: end 18480 status 256
tcpserver: status: 1/50
18480 > [EOF]
[session end]
Sto prakticno znaci da apsolutno ne postuju RFC, sto se moze videti ovde:
ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt
Citat:
The custom of accepting lines ending only in <LF>, as a concession to
non-conforming behavior on the part of some UNIX systems, has proven
to cause more interoperability problems than it solves, and SMTP
server systems MUST NOT do this, even in the name of improved
robustness. In particular, the sequence "<LF>.<LF>" (bare line
feeds, without carriage returns) MUST NOT be treated as equivalent to
<CRLF>.<CRLF> as the end of mail data indication.
Sve ovo ne bi bilo tako interesantno da nisam pisao 3com support-u od kojeg sam dobio odgovor ne samo da su svesni tog problema, vec da ih uopste ne interesuje da ga rese, i savetuju mi da koristim ili Sendmail ili M$ proizvode s obzirom da oni "rade" kako treba. Za nas koji koristimo Qmail, Postfix i ostale "lose" mta ... mozemo da se slikamo :)
Citat:
Yes, there is such a problem with some mail servers which strictly follows
recommendations (take a look on the e-mail bellow) Unfortunately, some people told me that there is no chance to expect some changes from the division responsible for 4400. The only one solution is to use 3Com Network Supervisor or Director's e-mail
nonfiction instead of 4400 one.
recommendations (take a look on the e-mail bellow) Unfortunately, some people told me that there is no chance to expect some changes from the division responsible for 4400. The only one solution is to use 3Com Network Supervisor or Director's e-mail
nonfiction instead of 4400 one.
Citat:
This is a problem with strict compliance to SMTP standards. It has been around for years if I remember right. However, Sendmail and others like Microsoft do not have an issue with this Line Feed (LF) problem. They just do not care about them and therefore the LF are not treated (the mail is treated as normally and delivered);
This is not the case of Qmail among others.
This is not the case of Qmail among others.
Eto, reko da podelim sa vama, cisto da neko ne lupa glavu posle sto mu to ne radi.
[Ovu poruku je menjao stinger dana 25.08.2005. u 11:15 GMT+1]
