🚀 go-pugleaf

hh> Von : hannes@flinx.hotb.sub.org (Mo, 28.09.92 23:27)
hh> Name: Hannes Deeken
hh> Box : Me, organized? You're kidding!
hh> MId : <1a80t1INN193@flinx.hotb.sub.org>
hh> RId : <A48740@MS.maus.de>

hh> Wie um alles in der Welt kommst Du denn darauf, dass SMTP (RFC 821) und die
hh> Definition des Message-Formats inhaerent zusammengehoeren?

Ich kann hier auf die Schnelle die Quelle nicht mehr wiederfinden, aber ich
meine, das waere eine Aussage der Autoren gewesen.

Immerhin als Anhaltspunkt:

----
   RFC 821
                     SIMPLE MAIL TRANSFER PROTOCOL
                           Jonathan B. Postel
                              August 1982
                     Information Sciences Institute
                   University of Southern California
                           4676 Admiralty Way
                   Marina del Rey, California  90291
                             (213) 822-1511
---
     RFC #  822
     Obsoletes:  RFC #733  (NIC #41952)
                        STANDARD FOR THE FORMAT OF
                        ARPA INTERNET TEXT MESSAGES
                              August 13, 1982
                                Revised by
                             David H. Crocker
                      Dept. of Electrical Engineering
---

... beide sind im selben Monat herausgekommen. Oder:


---
RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989

   MAIL REFERENCES:


   [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
        1982.

   [SMTP:2]  "Standard For The Format of ARPA Internet Text Messages,"
        D. Crocker, RFC-822, August 1982.

        This document obsoleted an earlier specification, RFC-733.

   [SMTP:3]  "Mail Routing and the Domain System," C. Partridge, RFC-
        974, January 1986.

        This RFC describes the use of MX records, a mandatory extension
        to the mail delivery process.

   [SMTP:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
        February 1988.
---

hh> Man kann ja wohl ohne Probleme ueber eine SMTP-Verbindung beliebiges
hh> schicken. Und man kann, ebenfalls ohne Probleme, Messages, die RFC 822
hh> entsprechen, ueber beliebige Verbindungen schicken.

Das ist natuerlich richtig. Analog kann man mit einem Brotmesser auch
Menschen toeten und mit einer Guillotine Brot zerkleinern. Nichtsdestotrotz ist
das bei der Erfindung des Brotmessers niemandes Intention gewesen :-)

hh> Ich verstehe nicht, was an RFC822 *schwer* zu implementieren ist. Ok, es

Nochmal ein Zitat aus RFC 1123:

---
   5.2  PROTOCOL WALK-THROUGH

      This section covers both RFC-821 and RFC-822.

      The SMTP specification in RFC-821 is clear and contains numerous
      examples, so implementors should not find it difficult to
      understand.  This section simply updates or annotates portions of
      RFC-821 to conform with current usage.

      RFC-822 is a long and dense document, defining a rich syntax.
      Unfortunately, incomplete or defective implementations of RFC-822
      are common.  In fact, nearly all of the many formats of RFC-822
      are actually used, so an implementation generally needs to
      recognize and correctly interpret all of the RFC-822 syntax.
---

hh> Aber ich komme ja auch aus der RFC-Welt ;-)

Ich eigentlich auch :-)

hh> Wofuer, um Himmels Willen, brauchst Du hier RFC 821? SMTP ist ein

Hmm. Die ganze Diskussion hier fing damit an, dass ZConnect keine Analogie zu
RFC 821 enthielt, nur zu 822, und dass die RFCler das fuer ein schwerwiegendes
Problem hielten ...

hh> Transport- protokoll, so wie UUCP oder meinetwegen auch ZModem. Das hat
hh> doch mit dem Nachrichten*inhalt* nix zu tun.

Schwerer Fehler: SMTP entspricht NICHT ZModem. TCP entspricht ZModem. SMTP
befasst sich nicht damit, wie ich Daten fehlerfrei von Rechner A nach Rechner B
bekomme, sondern damit, wie ich *Mail* von Rechner A nach Rechner B bekomme.
Etwa so wie rmail statt UUCP.

hh> Envelopes _sind_ essentiell.

Klar. Envelopes sind das, was RFC 821 beschreibt :-)

RFC 822 erwaehnt Envelopes (leider) MIT KEINEM WORT!

MfG Kai