Hallo, ich sehe auf einmal (seit ein paar Tagen), daß bei allen Mails, die ich von der Liste bekomme, die Header-Zeilen mit ASCII #13#10 abgeschlossen sind, nicht aber die Leerzeile oder der Body. Mutt zeigt mir dann am Ende jeder Headerzeile ^M an. Ist das normal? Wohl eher nicht .... hat jemand eine Idee, woher das stammen könnte? Ode hab ich hier auf der Liste was überlesen? Läuft der Listenserver mittlerweile unter DOS? *scnr* Gruß, Sebastian -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.sh/faq/
Moin, * Sebastian Helms schrieb am 27 Jul 2002:
ich sehe auf einmal (seit ein paar Tagen), daß bei allen Mails, die ich von der Liste bekomme, die Header-Zeilen mit ASCII #13#10 abgeschlossen sind, nicht aber die Leerzeile oder der Body.
Mutt zeigt mir dann am Ende jeder Headerzeile ^M an.
Ich nehme alles zurück und behaupte das Gegenteil ... Ich hatte nicht gemerkt, daß mein lokaler sendmail nicht lief (fetchmail läuft i.d.R. nur im Hintergrund). Also hat fetchmail direkt an procmail ausgeliefert. Das erklärt das Problem zwar nicht, aber jetzt, wo sendmail wieder läuft, sind die ^M's weg. Trotzdem würd mich mal interessieren, ob jemand weiß, woran das liegt. Schreibt procmail die Header von LF auf CRLF auf, wenn es von fetchmail direkt aufgerufen wird? Und wieso nur dann, und nicht, wenn es von sendmail gestartet wird? Gruß, Sebastian -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.sh/faq/
* On Sat, 27 Jul 2002 at 21:21 +0200, Sebastian Helms wrote:
* Sebastian Helms schrieb am 27 Jul 2002:
ich sehe auf einmal (seit ein paar Tagen), daß bei allen Mails, die ich von der Liste bekomme, die Header-Zeilen mit ASCII #13#10 abgeschlossen sind, nicht aber die Leerzeile oder der Body.
Mutt zeigt mir dann am Ende jeder Headerzeile ^M an.
Ich nehme alles zurück und behaupte das Gegenteil ...
Ich hatte nicht gemerkt, daß mein lokaler sendmail nicht lief (fetchmail läuft i.d.R. nur im Hintergrund).
*g*
Also hat fetchmail direkt an procmail ausgeliefert. Das erklärt das Problem zwar nicht, aber jetzt, wo sendmail wieder läuft, sind die ^M's weg.
Trotzdem würd mich mal interessieren, ob jemand weiß, woran das liegt. Schreibt procmail die Header von LF auf CRLF auf, wenn es von fetchmail direkt aufgerufen wird? Und wieso nur dann, und nicht, wenn es von sendmail gestartet wird?
Ganz im Gegenteil, POP3 und SMTP sind beide CRLF-terminiert. Wie übrigens - IIRC - alle anderen telnet-basierten Protokolle auch. Ausschnitt aus RFC 2822: | Messages are divided into lines of characters. A line is a series | of characters that is delimited with the two characters | carriage-return and line-feed; that is, the carriage return (CR) | character (ASCII value 13) followed immediately by the line feed | (LF) character (ASCII value 10). (The carriage-return/line-feed | pair is usually written in this document as "CRLF".) In RCF 1939 (POP3) steht was ähnliches. Mir scheint, als würde im Normalfall sendmail die CRs entfernen. -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
On Sat, 27 Jul 2002 at 21:21 (+0200), Sebastian Helms wrote:
* Sebastian Helms schrieb am 27 Jul 2002:
ich sehe auf einmal (seit ein paar Tagen), daß bei allen Mails, die ich von der Liste bekomme, die Header-Zeilen mit ASCII #13#10 abgeschlossen sind, nicht aber die Leerzeile oder der Body.
Mutt zeigt mir dann am Ende jeder Headerzeile ^M an.
Ich nehme alles zurück und behaupte das Gegenteil ...
*g* Exakt das gleiche Problem hatte ich heute auch! Zufälle gibt's ...
Ich hatte nicht gemerkt, daß mein lokaler sendmail nicht lief (fetchmail läuft i.d.R. nur im Hintergrund).
Und die Ursache war bei mir auch dieselbe! Nur dass bei mir Sendmail Masqmail heißt und ich nicht ganz unschuldig war, d. h. Masqmail selber heruntergefahren habe. Ich dachte zwar, ich hätte es wieder gestartet aber anscheinend war dem nicht so.
Also hat fetchmail direkt an procmail ausgeliefert.
Eben. Das sieht man recht schön, wenn man Sendmail (bzw. den MTA auf Port 25) runterfährt und dann fetchmail -vvv ausführt.
Das erklärt das Problem zwar nicht, aber jetzt, wo sendmail wieder läuft, sind die ^M's weg.
Doch, eigentlich schon.
Trotzdem würd mich mal interessieren, ob jemand weiß, woran das liegt. Schreibt procmail die Header von LF auf CRLF auf, wenn es von fetchmail direkt aufgerufen wird? Und wieso nur dann, und nicht, wenn es von sendmail gestartet wird?
Interessant ist v. a. dieser Abschnitt in der Manpage zu fetchmail: The `forcecr' option controls whether lines terminated by LF only are given CRLF termination before forwarding. Strictly speaking RFC821 requires this, but few MTAs enforce the requirement it so this option is normally off (only one such MTA, qmail, is in significant use at time of writing). The `stripcr' option controls whether carriage returns are stripped out of retrieved mail before it is forwarded. It is normally not necessary to set this, because it defaults to `on' (CR stripping enabled) when there is an MDA declared but `off' (CR stripping disabled) when forwarding is via SMTP. If `stripcr' and `forcecr' are both on, `stripcr' will override. Das heißt, dass Fetchmail normalerweise die CRLF, die er über das POP-Protokoll bekommt (Netzwerkprotokolle verwenden i. d. R. \r\n als Zeilentrenner), weiterleitet, aber nur, wenn er an einen MTA sendet. Wird dagegen an einen MDA weitergeleitet, wird \r\n zu \n konvertiert. Anscheinend klappt dies aber nur, wenn man dies (d. h. Weiterleitung an Procmail) explizit in der Konfigurationsdatei angegeben wird, nicht aber, wenn der MDA als Fallback verwendet wird. Eigentlich ist das ein Bug. Der MDA sorgt dann anscheinend wieder für die Konvertierung, bevor er in die Mailbox (/var/spool/mail/...) schreibt oder an Procmail weiterleitet. Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ Machine Always Crashes, If Not, The Operating System Hangs (MACINTOSH) -- Topic on #Linux
participants (3)
-
Adalbert Michelic -
Bernhard Walle -
Sebastian Helms