Moin, * Mika Fischer <[EMAIL PROTECTED]> [2003-10-18 00:04]: >Hallo, Thorsten! > >* Thorsten Haude <[EMAIL PROTECTED]> [2003-10-17 23:44]: >> Ist klar. Jetzt mal Klartext: Wir hatten eine kontroverse Diskussion >> �ber dieses Thema, mein Gegen�ber meinte, da� SMTP beinahe immer mit >> UDP benutzt wird, ich bin nach wie vor der Meinung, da� UDP allenfalls >> in skurillen Ausnahmesituationen eingesetzt wird. > >Dein Gegen�ber liegt komplett falsch. Du wohl ein bisschen, denn mir ist >�berhaupt keine Implementation von SMTP bekannt, die UDP benutzt, es >k�me mir auch ziemlich sinnlos vor...
Darum geht es nicht. Ich bin sicher, da� man SMTP auch �ber UDP schicken kann, schlie�lich hat man auch schon Brieftauben benutzt. >> Die fehlende >> �bermittlungssicherheit bei UDP w�rde von SMTP ausgeglichen werden. > >*LOL* Einen Bonuspunkt f�r Einfallsreichtum... Wieso ist das abwegig? Es gibt MOMs, die so Transaktionen abschlie�en. >> Sein Argument: Mails brauchen mal eine Minute, mal zwei Stunden, eben >> weil UDP unzuverl�ssig ist. > >Das ist kein Argument (aus verschiedenen Gr�nden)... Ein Argument nicht, aber ein Indiz. >Also in RFC2821 (ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt) steht: >----snip--- >SMTP is independent of the particular transmission subsystem and >requires only a reliable ordered data stream channel. While this >document specifically discusses transport over TCP, other >transports are possible. Appendices to RFC 821 describe some of them. >----snip--- > >Das sagt eingentlich schon alles. "a reliable ordered data stream >channel" ist UDP jedenfalls nicht. Allerdings, das ist ein handfester Beweis. Danke! >Als weitere Quelle sind wohl s�mliche Implementierungen von SMTP-Servern >und Clients zu nennen... Ne, leider ist das in diesem Gespr�ch nicht m�glich, das bis Quelltextebene runterzubrechen. >Bei Mail macht es nun �berhaupt keinen Sinn UDP zu nehmen, weil man ja >keine Mail haben will, wo die Bytes durcheinandergeraten sind und einige >fehlen. Daher m�sste man bei UDP die TCP-Eigenschaften quasi emulieren >und dann kann man eigentlich auch gleich TCP nehmen :) Klar, ich habe in der Diskussion auch mehrfach erw�hnt, da� MTAs sehr sorgf�ltig mit Mails umgehen, und da� etwas anderes als TCP f�r die Anwendung keinen Sinn macht. Wof�r TCP, wenn nicht f�r Mail? >> Bonusfrage: Warum braucht eine Mail mal eine Minute, mal eine Stunde? > >Naja, ganz so nichtdeterministisch ists ja nun meist auch nicht. >Normalerweise dauert das Versenden einer Mail vom gleichen Sender zum >gleichen Empf�nger etwa zum selben Zeitpunkt auch etwa gleich lang. Das ist aber nicht wirklich zuverl�ssig, darum kann man f�r die Diskussion annehmen, da� es unberechenbar ist. >Bei verschiedenen Sendern oder Empf�ngern oder Zeitpunkten k�nnen >verschiedene Probleme auftauchen. Davon nur mal zwei: >1) Einer der beteiligten Mailserver kann gerade ziemlich ausgelastet >sein und die Mail erstmal zur�ckstellen. Oder er ist ganz down, die Mail >wird zum Backup-MX geleitet, der erstmal wartet, bis der normale >Mailserver wieder tut. >2) Es k�nnen diverse DNS-Probleme auftreten, die f�r Verz�gerung sorgen >k�nnen. Jupp, werde ich mir mal merken. Naja, jedenfalls Danke an alle, die zu der Diskussion beigetragen haben! Ich hoffe, ich werde ihn �berzeugen k�nnen. Thorsten -- Alles ist richtig, auch das Gegenteil. - Kurt Tucholsky
pgp00000.pgp
Description: PGP signature
