SMTP Header Größe

Status
Nicht offen für weitere Antworten.
T

Tho82

Gast
Hallo,

wollte mal nachfragen, ob von euch einer weiss, wie groß der Header des SMTP Protokolls ist. Also im Endeffekt will ich über ein Netzwerk, das rund 6,5 kbit/s durchsatz hat, E-Mails versenden. Wieviele bit braucht das SMTP-Protokoll, ohne die Buchstaben für Text, Betreff, Empfänger und Absender?

Also kurz gefasst, wieviele Bit hat eine leere E-Mail, die per SMTP versendet wird, mindestens?

Vielen Dank :)

Gruß Tho
 
T

Tho82

Gast
Um mein Problem genauer zu erläutern:

Ich überlege, ob ich das SMTP-Protokoll zum Austausch von Nachrichten benutze oder mir ein eigenes, kleineres Protokoll in XML zum übertragen von Daten entwickle wie z.B.:

Code: 
<msg sender="mysend" recipient="myrec" time="1212234234">
  <header>myheadline</header>
  <body>mytext</body>
</msg>

Diese Nachricht würde zur Übertragung nun rund 150 Zeichen = 150 Byte = 1200 bit haben. Wieviel bit würde denn nun die Übertragung per SMTP haben? Sicherlcih mehr oder?

Vielleicht kann mir nun jemand weiterhelfen..

Gruß Tho[/code]
 
T

tuxedo

Gast
Mit SIMON hast du, *überleg* *rechen*

11 byte SIMON-Header
+ 8 Byte für die Identifikation der Remote-Methode
+ 4 Byte für die Länge des Remoteobjekt-Namens
+ 1 Byte für den Remoteobjektnamen selbst (mindestens 1 Byte, höchstens so lang wie du das Remoteobjekt nennen willst)
+ 4 Byte für die Längenangabe des Sender
+ 4 Byte für die Längenangabe des Empfängers
+ 8 Byte für den Timestamp
+ 4 Byte für die Längenangabe der Headline
+ 4 Byte für die Längenangabe des Bodys
----------
= 48 Byte Overhead die gesendet werden
= 384 Bit

;-)

Gruß
Alex
 
T

Tho82

Gast
alex0801 hat gesagt.:
Mit SIMON hast du, *überleg* *rechen*

11 byte SIMON-Header
+ 8 Byte für die Identifikation der Remote-Methode
+ 4 Byte für die Länge des Remoteobjekt-Namens
+ 1 Byte für den Remoteobjektnamen selbst (mindestens 1 Byte, höchstens so lang wie du das Remoteobjekt nennen willst)
+ 4 Byte für die Längenangabe des Sender
+ 4 Byte für die Längenangabe des Empfängers
+ 8 Byte für den Timestamp
+ 4 Byte für die Längenangabe der Headline
+ 4 Byte für die Längenangabe des Bodys
----------
= 48 Byte Overhead die gesendet werden
= 384 Bit

;-)

Gruß
Alex
Zum Vergrößern anklicken....

Hi, erstmal danke...
versteh ich leider nicht.. hast du mir vielleicht irgend ne internetquelle, wo ich den minimum header eines SMTP-Protokolls sehen kann bzw. wie sich der minimale header zusammensetzt?
 
T

tuxedo

Gast
>> versteh ich leider nicht..

Liegt daran, dass du noch nicht in meine Signatur geschaut hast.


>> hast du mir vielleicht irgend ne internetquelle, wo ich den minimum header eines SMTP-Protokolls sehen kann bzw. wie sich der minimale header zusammensetzt?

Sorry, da müsste ich auch erst suchen. Da kannst du dann aber gleich selbst suchen ;-)
Der SMTP-Header sollte eigentlich recht klein sein.
Grund:

Google mal nach "telnet + smtp". Da findest du Anleitungen wie du via Telnet eine Email an einen SMTP Server übermitteln kannst. Da gibts nicht wirklich viel zu tippen, soweit ich mich da noch erinnern kann. Ergo: Minimaler header.

Zumal: SMTP gabs schon, da gabs noch keine 6,5kbit Verbindungen ... Hatte SMTP schon mit 1,2Kbit in Benutzung. Gehen tut das. Ist nur die Frage ob's im heutigen Zeitalter der 12907235MB großen Dateianhänge noch Spass macht.

Was ich damit sagen will: Die Email ist sicherlich ein (sehr viel) vielfaches größer als der Header, so dass der Header wohl zu vernachlässigen ist...

- Alex
 
G

Guest

Gast
alex0801 hat gesagt.:
>> versteh ich leider nicht..

Liegt daran, dass du noch nicht in meine Signatur geschaut hast.


>> hast du mir vielleicht irgend ne internetquelle, wo ich den minimum header eines SMTP-Protokolls sehen kann bzw. wie sich der minimale header zusammensetzt?

Sorry, da müsste ich auch erst suchen. Da kannst du dann aber gleich selbst suchen ;-)
Der SMTP-Header sollte eigentlich recht klein sein.
Grund:

Google mal nach "telnet + smtp". Da findest du Anleitungen wie du via Telnet eine Email an einen SMTP Server übermitteln kannst. Da gibts nicht wirklich viel zu tippen, soweit ich mich da noch erinnern kann. Ergo: Minimaler header.

Zumal: SMTP gabs schon, da gabs noch keine 6,5kbit Verbindungen ... Hatte SMTP schon mit 1,2Kbit in Benutzung. Gehen tut das. Ist nur die Frage ob's im heutigen Zeitalter der 12907235MB großen Dateianhänge noch Spass macht.

Was ich damit sagen will: Die Email ist sicherlich ein (sehr viel) vielfaches größer als der Header, so dass der Header wohl zu vernachlässigen ist...

- Alex
Zum Vergrößern anklicken....

D.h. du denkst dass des evtl sogar kleiner ist als mein XML-Entwurf, richtig?
 
T

tuxedo

Gast
Ich denke du solltest ncht spekulieren, sondern googlen, am besten mal nach "smtp + telnet" oder "how to send email by telnet".

Und ja, dein XML-Ansatz ist sicherlich größer als das SMTP-Protokoll. Damals, als das erfunden wurde, musste man noch bytes sparen und konnte sich den "Luxus" von Klammertags und Co. nicht leisten. Da hatte man noch so Modems wo man den Telefonhörer draufklemmen musste und nahezu jedes Bit einzeln hörbar übertragen wurde ...

- Alex
 
G

Guest

Gast
alex0801 hat gesagt.:
Ich denke du solltest ncht spekulieren, sondern googlen, am besten mal nach "smtp + telnet" oder "how to send email by telnet".

Und ja, dein XML-Ansatz ist sicherlich größer als das SMTP-Protokoll. Damals, als das erfunden wurde, musste man noch bytes sparen und konnte sich den "Luxus" von Klammertags und Co. nicht leisten. Da hatte man noch so Modems wo man den Telefonhörer draufklemmen musste und nahezu jedes Bit einzeln hörbar übertragen wurde ...

- Alex
Zum Vergrößern anklicken....

Jetzt hab ichs kapiert. Also ich habe ein Gerät A, auf diesem läuft ein SMTP-Server. Dieser Server ist über ein Drahtloses Netzwerk (6,5kb/s) mit einem Gerät B verbunden. Effektiv werden leider nur rund 2,4 kb/s übertragen. Auf Gerät B läuft ebenfalls ein SMTP-Server.
So, nun will ich vom Gerät A eine E-Mail auf Gerät B übertragen. Dafür erstelle ich eine Nachricht auf Gerät A und dessen SMTP-Server. Dieser Überträgt die Nachricht dann wie folgt:

Code: 
Received: from x.y.test
   by example.net
   via TCP
   with ESMTP
   id ABC12345
   for <mary@example.net>;  21 Nov 1997 10:05:43 -0600
Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>

Hello

D.H. die Nachricht hätte grob geschätzt 500 Zeichen = 500 Byte = 4000 bit. Habe ich die Übertragung per SMTP richtig verstanden?
 
T

Tho82

Gast
AlArenal hat gesagt.:
Telnet und SMTP?

Ziemlich umständlich.. Ich werfe mal RFC 2821 in den Raum.
Zum Vergrößern anklicken....

Hmm dieses Dokument habe ich mir schon angesehen, aber ich verstehe nicht ganz. Ist dort beschrieben, wie zwei SMTP Mailserver miteinander kommunizieren oder?
 
T

tuxedo

Gast
AlArenal hat gesagt.:
Telnet und SMTP?

Ziemlich umständlich.. Ich werfe mal RFC 2821 in den Raum.
Zum Vergrößern anklicken....

Naja, ich weiß es zwar nicht, aber ich bezeifle dass in dem sicherlich unendlich langen RFC Dokument drin steht: "Der Overhead für den eine Email beträgt XX bytes". Und wenn, dann ist das sicher nicht einfach zu finden. Der Tipp mit Telnet war nur dazu gedacht zu verdeutlichen, wie klein der Overhead ist, und nicht um programmatisch "telnetartig" Mails zu verschicken. Dafür gibts genug APIs die einem die Arbeit abnehmen.

- Alex
 
G

Guest

Gast
tuxedo hat gesagt.:
AlArenal hat gesagt.:
Telnet und SMTP?

Ziemlich umständlich.. Ich werfe mal RFC 2821 in den Raum.
Zum Vergrößern anklicken....

Naja, ich weiß es zwar nicht, aber ich bezeifle dass in dem sicherlich unendlich langen RFC Dokument drin steht: "Der Overhead für den eine Email beträgt XX bytes". Und wenn, dann ist das sicher nicht einfach zu finden. Der Tipp mit Telnet war nur dazu gedacht zu verdeutlichen, wie klein der Overhead ist, und nicht um programmatisch "telnetartig" Mails zu verschicken. Dafür gibts genug APIs die einem die Arbeit abnehmen.

- Alex
Zum Vergrößern anklicken....

In dem Netzwerk werden viele Messages hin und her gehn. D.H. aufgrund der niedrigen Bandbreite will ich die Messages eben so klein wie möglich bekommen. Im Endeffekt könnte man sagen, ich will was ähnliches wie einen SMS Austausch implementieren.

Ist es Blödsinn, ein eigenes Messaging-Format bzw Messaging-System zu implementieren?
 
T

tuxedo

Gast
>> Ist es Blödsinn, ein eigenes Messaging-Format bzw Messaging-System zu implementieren?

Es ist blödsinn ohne handfeste Zahlen was den Overhead betrifft zu spekulieren was besser oder schlechter ist.
 
T

Tho82

Gast
tuxedo hat gesagt.:
>> Ist es Blödsinn, ein eigenes Messaging-Format bzw Messaging-System zu implementieren?

Es ist blödsinn ohne handfeste Zahlen was den Overhead betrifft zu spekulieren was besser oder schlechter ist.
Zum Vergrößern anklicken....

Naja wenn bei SMTP rund 500 Buchstaben = 500 Bytes übertragen werden dann ist dies wohl mehr als bei meiner Methode mit 50 oder 100 Buchstaben?!?
Ich habe zur Größe des Headers folgendes Dokument gefunden:

projects.puremagic.com/greylisting/whitepaper.html

Dort steht folgendes:

Average SMTP delivery attempt overhead: 500 bytes

Ob dies wirklich eine seriöse Quelle ist kann ich nicht beurteilen, aber es würde meine Schätzung von rund 500 Zeichen bestätigen?!?
 
T

tuxedo

Gast
500 Bytes kann ich nicht nachvollziehen. Habs eben mal in Telnet probiert:

nas:~# telnet my.mail.server 25 <--- Aufruf von Telnet
Trying xxx.xxx.xxx.xxx ... <--- Ausgabe von Telnet bzgl. dem Verbindungsaufbau
Connected to my.mail.server. <--- Ausgabe von Telnet bzgl. dem Verbindungsaufbau
Escape character is '^]'. <--- Ausgabe von Telnet bzgl. dem Verbindungsaufbau
220 my.mail.server <--- Antwort vom SMTP Server
HELO my.mail.server <--- Meine Eingabe
250 my.mail.server <--- Antwort vom SMTP Server
MAIL FROM: alex@my.mail.server <--- Meine Eingabe
250 Ok <--- Antwort vom SMTP Server
RCPT TO: alex@my.mail.server <--- Meine Eingabe
250 Ok <--- Antwort vom SMTP Server
DATA <--- Meine Eingabe
354 End data with <CR><LF>.<CR><LF> <--- Antwort vom SMTP Server
Hello World. <--- Meine Eingabe
. <--- Meine Eingabe
250 Ok: queued as 813A04883DA <--- Antwort vom SMTP Server
QUIT <--- Meine Eingabe
221 Bye <--- Antwort vom SMTP Server
Connection closed by foreign host. <--- Ausgabe von Telnet bzgl. dem Verbindungsabbau
Zum Vergrößern anklicken....

Wenn ich das durchrechne, hab ich einen reinen Text Overhead von 68 Bytes in der Senderichtung (da ist mein SIMON ja in der Tat ein "i-Tupfer" sparsamer, wenn man den Verbinungsaufbau und Lookup des Remoteserverobjekts außen vor lässt). Was jetzt fehlt die die Betreff-Zeile. Aber die reisst's auch nicht mehr raus, so dass man auch nur annähern in die 500 Bytes Zone vordringt.

Das ist jetzt das Minimalbeispiel gewesen. Gibt sicher noch "komplexere" Arten mit SMTP eine Mail zu senden (z.B. wenn man Verschlüsselung verwendet oder so).

- Alex
 
A

AlArenal

Top Contributor
Worauf Alex wohl eher hindeuten woltle war, dass du keine spezifischen Anforderungen gestellt hast. Du orakelst herum, was wieviele Bytes an Traffic verursacht, aber du selbst machst aus der Leitungfskapzität keine Angaben darüber, wieviele Mails du versenden willst.

Grundsatz sollte immer sein, zunächst eine Lösung zu schaffen, die die eigentliche funktionelle Aufgabe erfüllt. Danach kann man im Testbetrieb analysieren und optimieren. Clever ist, wer also die Anwendungslogik in der Anwendung von der Transportschicht abkapselt, so dass diese ggf. einfach (mglw. sogar dynamisch) ersetzt werden kann.

Ob du nun SMTP nutzt, oder dir was in HTTP strickst, oder SIMON, oder Samson, oder Elke, (...) sollte keine Rolle spielen.
 
A

AlArenal

Top Contributor
Aber mal so als Gedankenanstoß:

RFC 821 stammt aus dem Jahr 1982. Wer von euch erinnert sich noch an die damals üblichen Verbindungsraten? ;-)
 
T

tuxedo

Gast
jupp, ich zitier mich deshalb nochmal selbst:

Und ja, dein XML-Ansatz ist sicherlich größer als das SMTP-Protokoll. Damals, als das erfunden wurde, musste man noch bytes sparen und konnte sich den "Luxus" von Klammertags und Co. nicht leisten. Da hatte man noch so Modems wo man den Telefonhörer draufklemmen musste und nahezu jedes Bit einzeln hörbar übertragen wurde ...
Zum Vergrößern anklicken....

300 Baud waren da absolut keine seltenheit ...

- Alex
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
ruutaiokwu ständig "sender address rejected: improper use of smtp" bei smtp-client Netzwerkprogrammierung 4
C SMTP-Host automatisch ermittlen Netzwerkprogrammierung 15
C Socket Kommunikation mit SMTP-Server Netzwerkprogrammierung 4
F Java SMTP Server Netzwerkprogrammierung 9
S SMTP Server per Telnet ansprechen Netzwerkprogrammierung 11
0din SMTP Client - readline problem Netzwerkprogrammierung 4
T imap (oder pop3/smtp) - client mit Java entwickeln Netzwerkprogrammierung 2
B Sendefehler bei SMTP Netzwerkprogrammierung 17
K Mit Java-MailAPI dir Verfügbarkeit eines SMTP-Servers prüfen Netzwerkprogrammierung 4
D Timeouts ohne Ende bei SMTP und FTP Netzwerkprogrammierung 3
M SMTP-Mail Netzwerkprogrammierung 2
G POP vor SMTP Netzwerkprogrammierung 4
E smtp Zugriffsproblem mit Java Mail API Netzwerkprogrammierung 3
krgewb HTTP Authorization header Netzwerkprogrammierung 12
H HTTP Header Response kann nicht ausgelesen werden Netzwerkprogrammierung 4
F Timestamp aus IP-Header auslesen Netzwerkprogrammierung 2
F IP-Header manipulieren Netzwerkprogrammierung 2
G Socket + HTTP Header Netzwerkprogrammierung 2
A java.io.StreamCorruptedException: invalid stream header Netzwerkprogrammierung 2
C invalid stream header Netzwerkprogrammierung 2
A StringCorruptedException: invalid String header Netzwerkprogrammierung 2
J Größe von DatagramPacket Netzwerkprogrammierung 3
M Eingehender ByteBuffer mit unbestimmter Größe Netzwerkprogrammierung 2
L Größe einer Datei auslesen die im Netz liegt Netzwerkprogrammierung 4
Kr0e MTU Größe wichtig? Netzwerkprogrammierung 3
E Größe der Datei vor Download ermitteln Netzwerkprogrammierung 3
clemson Größe einer Heruntergeladenen Datei Netzwerkprogrammierung 10

Ähnliche Java Themen

Aktuelle Jobs

Neue Themen


Oben