nicht angemeldet
SMTP: 354 End data with <CR><LF>.<CR><LF>
s. Thema. Der Punkt ist also ein Token was dem Server sagt, daß die Mail komplett ist und keine Daten mehr kommen.
Problem: Ein Absender könnte in seiner Mail einen Punkt auf eine Zeile schreiben, etwa so:
Mailtext,
MfG
.
PS: Noche was.
und tatsächlich wird das vom Server als Kommando interpretiert. D.h., daß der Text danach gar nicht beim Empfänger ankommt. Den Punkt maskieren? Quoted Printable sieht den Punkt nicht vor.
Andere Idee?
-
s. Thema. Der Punkt ist also ein Token was dem Server sagt, daß die Mail komplett ist und keine Daten mehr kommen.
Problem: Ein Absender könnte in seiner Mail einen Punkt auf eine Zeile schreiben, etwa so:
Mailtext, MfG . PS: Noche was.und tatsächlich wird das vom Server als Kommando interpretiert. D.h., daß der Text danach gar nicht beim Empfänger ankommt. Den Punkt maskieren?
-
Stimmt, es gibt mehrere Möglichkeiten.
-
Stimmt, es gibt mehrere Möglichkeiten.
Nein, das ist die einzige in SMTP und alle SMTP-Clients müssen das korrekt umsetzen, da sonst Daten verloren gehen.
-
Stimmt, es gibt mehrere Möglichkeiten.
Nein, das ist die einzige in SMTP und alle SMTP-Clients müssen das korrekt umsetzen, da sonst Daten verloren gehen.
Ja, wenn man nur SMTP betrachtet. Aber ist gibt ja auch MIME. Und damit auch mehr Möglichkeiten. In Base64 z.B. gibt es überhaupt keinen Punkt.
MfG
-
Nein, das ist die einzige in SMTP und alle SMTP-Clients müssen das korrekt umsetzen, da sonst Daten verloren gehen.
Ja, wenn man nur SMTP betrachtet. Aber ist gibt ja auch MIME. Und damit auch mehr Möglichkeiten. In Base64 z.B. gibt es überhaupt keinen Punkt.
Ein SMTP-Client, der nur Base64 kodierte Mails verschicken kann, klingt ziemlich unnütz; weiterhin ändert das nichts daran, dass der Client das laut RFC unterstützen muss.
-
Nein, das ist die einzige in SMTP und alle SMTP-Clients müssen das korrekt umsetzen, da sonst Daten verloren gehen.
Ja, wenn man nur SMTP betrachtet. Aber ist gibt ja auch MIME. Und damit auch mehr Möglichkeiten. In Base64 z.B. gibt es überhaupt keinen Punkt.
Ein SMTP-Client, der nur Base64 kodierte Mails verschicken kann, klingt ziemlich unnütz; weiterhin ändert das nichts daran, dass der Client das laut RFC unterstützen muss.
Theoretisch ja. Ist ja auch kein Problem einen DATAEND Token zu maskieren. Praktisch wird hierzu das Content-Transfer-Encoding genutzt. Base64 ist nur eines davon.
MfG
-
Nein, das ist die einzige in SMTP und alle SMTP-Clients müssen das korrekt umsetzen, da sonst Daten verloren gehen.
Ja, wenn man nur SMTP betrachtet. Aber ist gibt ja auch MIME. Und damit auch mehr Möglichkeiten. In Base64 z.B. gibt es überhaupt keinen Punkt.
Ein SMTP-Client, der nur Base64 kodierte Mails verschicken kann, klingt ziemlich unnütz; weiterhin ändert das nichts daran, dass der Client das laut RFC unterstützen muss.
Theoretisch ja.
Praktisch auch.
Ist ja auch kein Problem einen DATAEND Token zu maskieren. Praktisch wird hierzu das Content-Transfer-Encoding genutzt.
Nein, praktisch wird dot stuffing genutzt.
-
Praktisch wird man von einem Mailbenutzer auch nicht verlangen daß er nur ASCII Zeichen eingibt.
-
Praktisch wird man von einem Mailbenutzer auch nicht verlangen daß er nur ASCII Zeichen eingibt.
Nein, aber dafür gibt es standardisierte Verfahren, so dass man eine gewisse Erwartung haben kann, dass bei der Gegenseite auch ankommt, was geplant war.
-
-
-
-
Die MailClients von MS machen es ganz einfach: Sie verwenden kein CRLF sondern nur LF. Praktisch reicht es ja auch, alle CRLF Zeilenenden in LF umzuwandeln und schon ist das Problem gelöst. MfG
-
Die MailClients von MS machen es ganz einfach: Sie verwenden kein CRLF sondern nur LF.
Bullshit: „In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence.“ - https://tools.ietf.org/html/rfc5321#section-2.3.8
Praktisch reicht es ja auch, alle CRLF Zeilenenden in LF umzuwandeln und schon ist das Problem gelöst.
Jo, großartiger Plan: „The maximum total length of a text line including the <CRLF> is 1000 octets (not counting the leading dot duplicated for transparency).“ https://tools.ietf.org/html/rfc5321#section-4.5.3.1.6
-
Jo, großartiger Plan: „The maximum total length of a text line including the <CRLF> is 1000 octets (not counting the leading dot duplicated for transparency).“ https://tools.ietf.org/html/rfc5321#section-4.5.3.1.6
Deswegen ja gibt es die Erweiterungen (siehe ebenda).
-
Jo, großartiger Plan: „The maximum total length of a text line including the <CRLF> is 1000 octets (not counting the leading dot duplicated for transparency).“ https://tools.ietf.org/html/rfc5321#section-4.5.3.1.6
Deswegen ja gibt es die Erweiterungen (siehe ebenda).
Was bastelst Du da eigentlich schon wieder? Nimm MIME::Lite und gut ist.
-
Nimm MIME::Lite und gut ist.
Eben das Modul würde ich nun gerade nicht empfehlen. Internet-Mail ist überhaupt ständig in Bewegung, davon können auch die
libnetEntwickler ein Liedchen singen. Grund genug, sich mit dem Thema mal etwas näher zu befassen.MfG
-
Nimm MIME::Lite und gut ist. Eben das Modul würde ich nun gerade nicht empfehlen.
Konkret warum? Weil der Entwickler davon abrät oder weil Du ein konkretes Problem damit hast? Welches?
Internet-Mail ist überhaupt ständig in Bewegung, davon können auch die
libnetEntwickler ein Liedchen singen.Grad bei Zusammenbasteln und abschicken von E-Mails ist sau wenig Bewegung, weil man zu unendlich vielen gestörten Setups und Clients kompatibel bleiben muss.
Grund genug, sich mit dem Thema mal etwas näher zu befassen.
Jo. Mach Du mal.
-
Nimm MIME::Lite und gut ist. Eben das Modul würde ich nun gerade nicht empfehlen.
Konkret warum? Weil der Entwickler davon abrät oder weil Du ein konkretes Problem damit hast? Welches?
Es ist umständlich zu handhaben. So hab ich bereits vor Jahren (!) ein eigenes Modul entwickelt, was plattformunabhängig ist und womit man Mails wahlweise auf ein locales
sendmailpipen oder direkt per SMTP senden kann. Darüber hinaus kann mein Modul TLS wasMIME::Liteimmer noch nicht kann.Und zum Erstellen von MIME Mails braucht man kein
MIME::Litesondern eine geeignete Templating Engine.Grad bei Zusammenbasteln und abschicken von E-Mails ist sau wenig Bewegung, weil man zu unendlich vielen gestörten Setups und Clients kompatibel bleiben muss.
Vor allem plattformunabhängige Clients die kompatibel zu unterschiedlich konfigurierten Mailservern sind!
Grund genug, sich mit dem Thema mal etwas näher zu befassen.
Jo. Mach Du mal.
Aber sicher doch. Was bei eigenen Entwicklungen immer wieder schön ist: Man lernt dazu und sieht dabei wie Andere zurückbleiben 😉
-
Wie passt
So hab ich bereits vor Jahren (!) ein eigenes Modul entwickelt, was […] direkt per SMTP senden kann.
zu deiner Ursprungsfrage in diesem Thread?
-
Es gibt immer Gründe für eigene Entwicklungen! Guck Dir die
libnetan, also wie viele Module das im Einzelnen sind. Es ist natürlich Dein Problem wie Du Deinen Kunden garantieren kannst, daß diese Module erstens immer auf dem neuesten Stand sind und zweitens so zusammenspielen, daß es bei Jedem Kunden+Endkunden funktioniert.Ich habe oft genug dafür meine Hand ins Feuer legen müssen und einen hohen Preis bezahlt: Für Fehler die andere verbockt haben.
So bin ich jetzt zwar raus aus diesem Affenzirkus, habe jedoch dafür mehr als genug Zeit mal darüber nachzudenken. Und was
die Welt im Innersten zusammenhält, darüber legt auch dieses Forum Zeugnis ab mit Beiträgen von Leuten wie Du..
-
Es gibt immer Gründe für eigene Entwicklungen!
Und meistens mehr dagegen.
Guck Dir die
libnetan,Das ist jetzt das zweite Mal, dass du libnet erwähnst, aber nicht erwähnst, was das ist; ich vermute mal nicht das was ich unter dem Namen finde: https://github.com/sam-github/libnet
Es ist natürlich Dein Problem wie Du Deinen Kunden garantieren kannst, daß diese Module erstens immer auf dem neuesten Stand sind und zweitens so zusammenspielen, daß es bei Jedem Kunden+Endkunden funktioniert.
Ersterns: Wie kommst du darauf, ich oder das Unternehmen für das ich arbeite hätte Kunden, die Software von mir ausführen?
Zweitens: Ich bin mir sicher, dass Eigenentwicklungen unter den von dir beschriebenen Umständen deutlich größere Probleme hätten. Entwicklerzeit ist schließlich rar und wenn einer meiner Kollegen auf die Idee käme, SMTP neu zu implementieren, statt eine Bibliothek zu verwenden, würde ich ihm mit Sicherheit ordentlich den Kopf waschen.
So bin ich jetzt zwar raus aus diesem Affenzirkus, habe jedoch dafür mehr als genug Zeit mal darüber nachzudenken. Und was die Welt im Innersten zusammenhält, darüber legt auch dieses Forum Zeugnis ab mit Beiträgen von Leuten wie Du.
Ich würde es begrüßen, wenn du das mit dem Wegbleiben mal konsequent umsetzen würdest.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Guck mal, ob Dein Mailclient das decoden kann:
From: alf@example.com To: olf@example.com Subject: ulf Content-Transfer-Encoding: uuencode Content-Type: text/plain; Charset=utf-8 6"DAA;&QO+`H*+@H*4%,Z($%31$8*"@``das ist Unix to Unix encoded. MS Outlook Express kann damit bestens umgehen.
MfG
-
Guck mal, ob Dein Mailclient das decoden kann:
From: alf@example.com To: olf@example.com Subject: ulf Content-Transfer-Encoding: uuencode Content-Type: text/plain; Charset=utf-8 6"DAA;&QO+`H*+@H*4%,Z($%31$8*"@``das ist Unix to Unix encoded.
Und entspricht nicht dem MIME-Standard: https://tools.ietf.org/html/rfc2045#section-6.1; wenn dann muss es „Content-Transfer-Encoding: x-uuencode“ heißen. Und viel Spaß damit, aber erwarte nicht, dass das irgendwo außerhalb deines Tests erfolgreich dekodiert wird.
-
Guck mal, ob Dein Mailclient das decoden kann:
From: alf@example.com To: olf@example.com Subject: ulf Content-Transfer-Encoding: uuencode Content-Type: text/plain; Charset=utf-8 6"DAA;&QO+`H*+@H*4%,Z($%31$8*"@``das ist Unix to Unix encoded.
Und entspricht nicht dem MIME-Standard:
Das war auch nicht die Frage.
Content-Transfer-Encoding: x-uuencode
Funktioniert auch. Sogar in meinem uralt Outlook Express.
-
Guck mal, ob Dein Mailclient das decoden kann:
From: alf@example.com To: olf@example.com Subject: ulf Content-Transfer-Encoding: uuencode Content-Type: text/plain; Charset=utf-8 6"DAA;&QO+`H*+@H*4%,Z($%31$8*"@``das ist Unix to Unix encoded.
Und entspricht nicht dem MIME-Standard:
Das war auch nicht die Frage.
Dann versuche es nicht so zu präsentieren, dass weniger erfahrene Menschen auf die Idee kommen könnten, das wäre sinnvoll oder sinnvoll nutzbar.
-
Dann versuche es nicht so zu präsentieren, dass weniger erfahrene Menschen auf die Idee kommen könnten, das wäre sinnvoll oder sinnvoll nutzbar.
Was soll der Unsinn!? Ich wollte nur wissen, ob ein Mailclient mit diesem Transferencoding zurechtkommt. Das ist eine Frage die sich jeder Entwickler stellt. Selbst Entwickler bei Mozilla haben zu diesem Thema einen Case aufgemacht. Schließlich ist uuencode so alt wie unix und war die erste Erweiterung für Mail.
.
-
Was soll der Unsinn!?
Ja, genau das ist die Frage, die sich vermutlich so ziemlich alle anderen bei deinen Postings stellen.
Ich wollte nur wissen, ob ein Mailclient mit diesem Transferencoding zurechtkommt.
Da es nicht standardisiert ist, ist die Antwort darauf doch eindeutig, vielleicht, aber nicht verlässlich und die Lehre daraus ist, entweder den Standard zu ändern oder es nicht zu nutzen, wenn ich verlässliche Kommikation benötige.
Das ist eine Frage die sich jeder Entwickler stellt.
Nein, verantwortungsvolle Entwickler denken nicht darüber nach, nicht-standardisierte Verfahren zu nutzen, wenn es standardisierte gibt, die den selben Zweck ebenso gut (oder besser) erfüllen.
Selbst Entwickler bei Mozilla haben zu diesem Thema einen Case aufgemacht.
Du meinst Bug 334222, wo die Entwickler offenbar nichtmal genug Interesse hatten, das Problem nachzustellen, weswegen der Bug immer noch Unconfirmed ist?
Schließlich ist uuencode so alt wie unix
und war die erste Erweiterung für Mail.
auch nicht, z.B. https://tools.ietf.org/html/rfc680 ist deutlich älter
-
-
-
-
-
-