Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #5453 > unrolled thread

Messageheader im Body

Back to article view | Back to de.comm.software.mailserver

Contents

  Messageheader im Body lrz1035@rsli.de (Volker Englisch) - 2016-09-13 14:39 +0000
    Re: Messageheader im Body "Juergen P. Meier" <nospam-1984@jors.net> - 2016-09-14 03:29 +0000
      Re: Messageheader im Body lrz1035@rsli.de (Volker Englisch) - 2016-09-14 06:02 +0000
        Re: Messageheader im Body "Juergen P. Meier" <nospam-1984@jors.net> - 2016-09-14 06:56 +0000
          Re: Messageheader im Body Nomen Nescio <nobody@dizum.com> - 2016-09-14 10:25 +0200
            Re: Messageheader im Body Nomen Nescio <nobody@dizum.com> - 2016-09-14 12:09 +0200
            Re: Messageheader im Body "Juergen P. Meier" <nospam-1984@jors.net> - 2016-09-15 03:39 +0000
          Re: Messageheader im Body lrz1035@rsli.de (Volker Englisch) - 2016-09-14 16:01 +0000
    Re: Messageheader im Body Thomas Gohel <gohel@basicguru.de> - 2016-09-14 17:21 +0200
      Re: Messageheader im Body lrz1035@rsli.de (Volker Englisch) - 2016-09-14 16:55 +0000

#5453 — Messageheader im Body

Hallo!

Ich bin mir nicht sicher, ob ich die richtige NG erwischt habe, ggf.
bitte umleiten.

Ab und an finde ich Mails im Posteingang, die so aussehen wie
angehängt. Als MTA läuft bei mir ein Sendmail, als MUA mutt. Aber auch,
wenn ich mir das Ganze in pine ansehe, sieht es genauso verhackstückt
aus. Es sieht aus, als sei der ganze Header zum Body "gerutscht".

Als eigentlichen Absender bekomme ich in mutt foo@bar präsentiert, das
Subject ist leer.

Irgendeine Idee, wer für das Verhäckseln des Headers verantwortlich
sein könnte? Wenn es mein MTA ist - woher könnte das kommen? Btw., es
ist kein Spam.

--------------------------------- cut -------------------------------

   From SRS0=z96n=VB=gmx.de=YYY.Xxxxxxxx@mx.kontent.com Tue Sep 13
   16:10:10 2016 Received: from meinhost.example.com (localhost [127.0.0.1]) by
   meinhost.example.com (8.14.4/8.14.4) with ESMTP id u8DEAAI7048174 for ; Tue, 13
   Sep 2016 16:10:10 +0200 (CEST) (envelope-from
   SRS0=z96n=VB=gmx.de=YYY.Xxxxxxxx@mx.kontent.com) Received: (from
   uucp@localhost) by meinhost.example.com (8.14.4/8.14.4/Submit) with UUCP id
   u8DEAAh0048173 for xx@meinhost.example.com; Tue, 13 Sep 2016 16:10:10 +0200
   (CEST) (envelope-from SRS0=z96n=VB=gmx.de=YYY.Xxxxxxxx@mx.kontent.com)
   Envelope-to: xx@meinhost.example.com Received: from mx003.kontent.com
   (mx003.kontent.com [81.88.40.23]) by mail.example.com with esmtps id
   1bjo6W-00046D-Ab; Tue, 13 Sep 2016 15:50:28 +0200 Received: from
   mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher
   DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate
   requested) by mx003.kontent.com (Postfix) with ESMTPS id C9C63179012C
   for ; Tue, 13 Sep 2016 15:50:25 +0200 (CEST) Received: from
   [79.207.72.215] by 3capp-gmx-bs42.server.lan (via HTTP); Tue, 13 Sep
   2016 15:50:25 +0200 MIME-Version: 1.0 Message-ID: From: "YYY Xxxxxxxx"
   To: "Volker Englisch" Subject: Aw: Anfrage Content-Type: text/html;
   charset=UTF-8 Date: Tue, 13 Sep 2016 15:50:25 +0200 Importance: normal
   Sensitivity: Normal In-Reply-To: <57D54B59.2030909@example.com> References:
   <57D54B59.2030909@example.com> X-UI-Message-Type: mail X-Priority: 3
   X-Provags-ID: V03:K0:SWvZ8f9CjJB2Lp9PiVblhCV6spgSoZVOXNNBkSjYIQl
   tyUpCmbgofGgDErsbgTbJrj+omTmywt1q3eKOH9yu1YPm0uRu0
   yYuoLHc8cYc0EyXyRnFnDOSG/ToPTpBI9KFPuq5IbrsQTf7wv2
   sxE//I9gyidhOE0yJZvJUY4yWe37QHfVStAGnAdcJCy7oJJjcd
   EXa5QOe0u/25GpJSJM0g6ZY5e5Hh/9l74ok+oGvbaCpb0xO1nx
   R6hM3Rma0EQyaTCJ49tPq3jdGR8xTTJ8y8H/yqxrXFOlXfW09S 47jeBU=
   X-UI-Out-Filterresults:
   notjunk:1;V01:K0:2jlaXMPLySU=:V6TLDQEj8Q/w9hpiMAAMM3
   TCEZ/XRLjdlFTk7+YrbVvSAfxNRYOGpWQNPfxgEkApgbW3Xfh8Uk8JS6uzGy2fKlij2NwrR
   15
   DQZoRS2Jp5dAHKbl3Hj3aaEIlsyeJTa+ZFTmHgXv1t4uHnR6VDu7WPfpPVLRP02kSa5oWJv
   Qx
   ry1x5HYyTOYiZft1WuXSDTA2XruFuyJg/SqNmySFDrohmbKNujvBAFeizKNv08U1/17Q5dk
   +c
   C6DEeBLtkMvs304aqwDrY946NvTlm2DIlItJjH3ZESDtaQgBTeA6VqmRCQwOaRkWXo8fnS1
   BZ
   R5XARBpvGhZpn9rtsYOH2YyDERX8nW6rPM5//QSM648B9DL5T0Ph0fF2cvtVBola8NcXjRS
   9v
   M3wLBf+V3lYzWIhDmXPY549NKXTtzcbWdBgH9x5NJTeldOOMwSU8v4SKriaftug7gWorq7B
   UJ
   v8gtwY3hKPgwiDv7TJbxUvYUexRBFpegE+3JzNw5aTcdwnwMhngJoWV+vNFN5jjZ1WTqwCg
   69
   wf0JqY1guWbxzae7mU11LUmkF/1MDiEdS5W8ryUGxkjip7b/s91AsUA3TOLTHa0tZBLI0fG
   yF fiZsXdSMwuRCCN/lv8l6CKEUDzxr+AmRxm

   [Jetzt kommt der richtige Body im Klartext]

[toc] | [next] | [standalone]

#5454

Volker Englisch <lrz1035@rsli.de>:
> Ich bin mir nicht sicher, ob ich die richtige NG erwischt habe, ggf.
> bitte umleiten.
>
> Ab und an finde ich Mails im Posteingang, die so aussehen wie
> angehängt. Als MTA läuft bei mir ein Sendmail, als MUA mutt. Aber auch,
> wenn ich mir das Ganze in pine ansehe, sieht es genauso verhackstückt
> aus. Es sieht aus, als sei der ganze Header zum Body "gerutscht".
>
> Als eigentlichen Absender bekomme ich in mutt foo@bar präsentiert, das
> Subject ist leer.

RFC 822: eine Leerzeile trennt Header vom Body.

> Irgendeine Idee, wer für das Verhäckseln des Headers verantwortlich
> sein könnte? Wenn es mein MTA ist - woher könnte das kommen? Btw., es
> ist kein Spam.

Was sagt denn das Logfile deines Receiving MTA zu dieser Mail? Taucht
auch nur ein Element des Headers-im-Body in dessen Statusmeldungen
auf? (Das dortige Subject:, die Message-ID, From:/To:)
Falls ja: Dann wird die Mail auf dem WEg zwischen MTA und MUA vermurkst.
Falls nein: Dann kommt sie so zerhackstueckelt schon bei dir an und du
musst das Problem an den Abwaelzen, der im Received:-Header deines
echten Mailheaders von deinem MTA als einliefernder Server
identifiziert wurde.


-- 
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems.  (Bruce Schneier)

[toc] | [prev] | [next] | [standalone]

#5455

Juergen P. Meier schrieb:
> Volker Englisch <lrz1035@rsli.de>:
>> Ab und an finde ich Mails im Posteingang, die so aussehen wie
>> angehängt. Als MTA läuft bei mir ein Sendmail, als MUA mutt. Aber auch,
>> wenn ich mir das Ganze in pine ansehe, sieht es genauso verhackstückt
>> aus. Es sieht aus, als sei der ganze Header zum Body "gerutscht".
>>
>> Irgendeine Idee, wer für das Verhäckseln des Headers verantwortlich
>> sein könnte? Wenn es mein MTA ist - woher könnte das kommen? Btw., es
>> ist kein Spam.
> 
> Was sagt denn das Logfile deines Receiving MTA zu dieser Mail? Taucht
> auch nur ein Element des Headers-im-Body in dessen Statusmeldungen
> auf? (Das dortige Subject:, die Message-ID, From:/To:)

Das Envelope-From sieht irgendwie merkwürdig aus:

| Sep 13 16:10:10 rsli sendmail[48173]: u8DEAAh0048173:
| from=SRS0=z96n=VB=gmx.de=yyy.XXXXXXX@mx.kontent.com, size=3706,
| class=0, nrcpts=1,
| msgid=<trinity-96fda309-e869-4265-9366-60a7ad4d15d4-1473774625559@3capp-gmx-bs42>,
| proto=UUCP, relay=uucp@localhost

| Sep 13 16:10:10 rsli sm-mta[48174]: u8DEAAI7048174:
| from=<SRS0=z96n=VB=gmx.de=yyy.XXXXXXX@mx.kontent.com>, size=3932,
| class=0, nrcpts=1,
| msgid=<trinity-96fda309-e869-4265-9366-60a7ad4d15d4-1473774625559@3capp-gmx-bs42>,
| proto=ESMTP, daemon=IPv4, relay=localhost [127.0.0.1]

| Sep 13 16:10:10 rsli sendmail[48173]: u8DEAAh0048173:
| to=xx@example.com,
| ctladdr=SRS0=z96n=VB=gmx.de=yyy.XXXXXXX@mx.kontent.com (66/66),
| delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=33706,
| relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (u8DEAAI7048174
| Message accepted for delivery)

| Sep 13 16:10:10 rsli sm-mta[48175]: u8DEAAI7048174:
| to="|/usr/local/bin/procmail", ctladdr=<xx@example.com> (1000/1000),
| delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=34170, dsn=2.0.0,
| stat=Sent

> Falls ja: Dann wird die Mail auf dem WEg zwischen MTA und MUA vermurkst.

Zugestellt wird die Mail durch Procmail. 

> Falls nein: Dann kommt sie so zerhackstueckelt schon bei dir an und du
> musst das Problem an den Abwaelzen, der im Received:-Header deines
> echten Mailheaders von deinem MTA als einliefernder Server
> identifiziert wurde.

Zählt der merkwürdige Envelop-From schon als zerhackstueckelt?

V*

[toc] | [prev] | [next] | [standalone]

#5456

Volker Englisch <lrz1035@rsli.de>:
> Das Envelope-From sieht irgendwie merkwürdig aus:
>
>| Sep 13 16:10:10 rsli sendmail[48173]: u8DEAAh0048173:
>| from=SRS0=z96n=VB=gmx.de=yyy.XXXXXXX@mx.kontent.com, size=3706,
>| class=0, nrcpts=1,
>| msgid=<trinity-96fda309-e869-4265-9366-60a7ad4d15d4-1473774625559@3capp-gmx-bs42>,
>| proto=UUCP, relay=uucp@localhost

Das ist schon auf dem Transportweg kaputt. Allerdings ist der
Transportweg nicht SMTP sondern UUCP.

>| Sep 13 16:10:10 rsli sm-mta[48174]: u8DEAAI7048174:
>| from=<SRS0=z96n=VB=gmx.de=yyy.XXXXXXX@mx.kontent.com>, size=3932,
>| class=0, nrcpts=1,
>| msgid=<trinity-96fda309-e869-4265-9366-60a7ad4d15d4-1473774625559@3capp-gmx-bs42>,
>| proto=ESMTP, daemon=IPv4, relay=localhost [127.0.0.1]

Das ist das loakle weiterleiten obiger Mail per SMTP an sich selbst.

>| Sep 13 16:10:10 rsli sendmail[48173]: u8DEAAh0048173:
>| to=xx@example.com,
>| ctladdr=SRS0=z96n=VB=gmx.de=yyy.XXXXXXX@mx.kontent.com (66/66),
>| delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=33706,
>| relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (u8DEAAI7048174
>| Message accepted for delivery)

Und das ist der Logeintrag von der Empfeangerseite obiger lokaler
weiterleitung.

>| Sep 13 16:10:10 rsli sm-mta[48175]: u8DEAAI7048174:
>| to="|/usr/local/bin/procmail", ctladdr=<xx@example.com> (1000/1000),
>| delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=34170, dsn=2.0.0,
>| stat=Sent

Und das dann das uebergeben an Procmail. (heh)

>> Falls ja: Dann wird die Mail auf dem WEg zwischen MTA und MUA vermurkst.
>
> Zugestellt wird die Mail durch Procmail. 

Den Logeintraegen nach duerfte die mail schon kaputt bei dir ankommen.
Entweder der Sender oder dein UUCP Transportweg machen das kaputt.

> Zählt der merkwürdige Envelop-From schon als zerhackstueckelt?

Laut diesen Logeintraegen muesste der mailheader am Ende so aussehen:
(bei mutt 'h' druecken um alle header einzublenden, oder |less)

--- snip ---
From SRS0=z96n=VB=gmx.de=yyy.XXXXXXX@mx.kontent.com Tue Sep 13 16:10:10 2016
Return-Path: <SRS0=z96n=VB=gmx.de=yyy.XXXXXXX@mx.kontent.com>
Delivered-To: <xx@example.com>
Received: from localhost by localhost
 (erzeugt vom Sendmail zwischen 2. und 3. Logzeile)
Received: from UUCP via UUCP
 (erzeugt nach der ersten Logzeile)
Message-ID: <trinity-96fda309-e869-4265-9366-60a7ad4d15d4-1473774625559@3capp-gmx-b s42>
... Restliche Header der Mail wie sie per UUCP ankam...

Nach der Leerzeile kommt der Mail-Inhalt ohne weitere Header.
.
--- snip ---


PS: "SRS0=z96n=VB=gmx.de=yyy.XXXXXXX" ist der local-part der
Absenderadresse, "mx.kontent.com" der domainpart. Sowas ist z.B. bei
Newslettern, Mailinglisten-Mails oder Status-Emails ueblich.
Da kann der Absender bei einem Bounce erkennen welche Mail genau
einen bounce verursachte.

PPS: Wenn die Message-ID
<trinity-96fda309-e869-4265-9366-60a7ad4d15d4-1473774625559@3capp-gmx-bs42>
nicht im Header steht, dann musst du dir deinen Procmail filter anschauen.

HTH,
Juergen

[toc] | [prev] | [next] | [standalone]

#5457

"Juergen P. Meier" <nospam-1984@jors.net> wrote:
> Volker Englisch <lrz1035@rsli.de>:
> > Das Envelope-From sieht irgendwie merkwürdig aus:

Das sieht ganz normal aus. SRS-Rewriting kann man machen, bringt aber 
nichts.

> >| Sep 13 16:10:10 rsli sendmail[48173]: u8DEAAh0048173:
> >| from=SRS0=z96n=VB=gmx.de=yyy.XXXXXXX@mx.kontent.com, size=3706,
> >| class=0, nrcpts=1,
> >| msgid=<trinity-96fda309-e869-4265-9366-60a7ad4d15d4-1473774625559@3capp-gmx-bs42>,
> >| proto=UUCP, relay=uucp@localhost
> 
> Das ist schon auf dem Transportweg kaputt.

Woran willst du das erkennen? Das sieht alles noch richtig aus.

Wenn mutt foo@bar präsentiert, muss der Fehler später passieren. Zum 
Beispiel in einem kaputten mbox-File. Ich würde mit formail die Mails in 
maildir konvertieren und nachsehen, ab welcher Mail der Fehler auftritt.

> Den Logeintraegen nach duerfte die mail schon kaputt bei dir ankommen.

Vielleicht solltest du dich zu Dingen äußern, mit denen du dich auskennst. 

> PS: "SRS0=z96n=VB=gmx.de=yyy.XXXXXXX" ist der local-part der
> Absenderadresse, "mx.kontent.com" der domainpart. Sowas ist z.B. bei
> Newslettern, Mailinglisten-Mails oder Status-Emails ueblich.

Der Envelope-From wird in diesem Beispiel von mx003.kontent.com nach 
SRS-Regeln umgeschrieben. kontent.com betreibt den MX für Volkers Domain 
und leitet auf sein UUCP-Relay weiter.

Received: (from uucp@localhost) by meinhost.example.com (8.14.4/8.14.4/Submit) with UUCP id u8DEAAh0048173 for xx@meinhost.example.com; Tue, 13 Sep 2016 16:10:10 +0200 (envelope-from SRS0=z96n=VB=gmx.de=YYY.Xxxxxxxx@mx.kontent.com)
Received: from mx003.kontent.com (mx003.kontent.com [81.88.40.23]) by mail.example.com with esmtps id 1bjo6W-00046D-Ab; Tue, 13 Sep 2016 15:50:28 +0200
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx003.kontent.com (Postfix) with ESMTPS id C9C63179012C

[toc] | [prev] | [next] | [standalone]

#5458

Nomen Nescio <nobody@dizum.com> wrote:

> Wenn mutt foo@bar präsentiert, muss der Fehler später passieren.

Meine Erinnerung war nicht ganz richtig. Ich dachte, mutt würde foo@bar als 
>From in einer kaputten mbox setzen.

formail(1)
  If formail is supposed to determine the sender of the mail, but is 
  unable to find any, it will substitute `foo@bar'.

Die Vermutung liegt nahe, daß die Mail nicht sauber durch procmail kommt. 
Ad-hoc konnte ich das Verhalten leider nicht nachstellen.

[toc] | [prev] | [next] | [standalone]

#5464

Ein Pseudo schrieb:
>
> Vielleicht solltest du dich zu Dingen äußern, mit denen du dich auskennst. 

Sprach der anonyme Feigling die das Problem des OP nicht loesen konnte.

fup2p (ha!), score adjusted
Juergen
-- 
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems.  (Bruce Schneier)

[toc] | [prev] | [next] | [standalone]

#5460

Juergen P. Meier schrieb:
> PS: "SRS0=z96n=VB=gmx.de=yyy.XXXXXXX" ist der local-part der
> Absenderadresse, "mx.kontent.com" der domainpart. Sowas ist z.B. bei
> Newslettern, Mailinglisten-Mails oder Status-Emails ueblich.
> Da kann der Absender bei einem Bounce erkennen welche Mail genau
> einen bounce verursachte.

Danke für die Erklärung, jetzt verstehe ich die Konstruktion auch.

> PPS: Wenn die Message-ID
> <trinity-96fda309-e869-4265-9366-60a7ad4d15d4-1473774625559@3capp-gmx-bs42>
> nicht im Header steht, dann musst du dir deinen Procmail filter anschauen.

Das war der Schubs in die richtige Richtung. In meiner ~/.procmailrc
war ein uraltes "Rezept" drin, das html-only mails in regulären Text
umwandeln sollte. Das könnte durchaus Amok gelaufen sein.

V*

[toc] | [prev] | [next] | [standalone]

#5459

Hallo Volker,

> Als eigentlichen Absender bekomme ich in mutt foo@bar präsentiert,
> das Subject ist leer.

Das kenne ich von einem gewissen Ticket-System, welches die Subject-
Zeile so kaputt faltet, dass die Subject-Zeile selbst leer ist und
der eigentliche Text in den gefalteten Zeilen steht.

Wie es hier weitergehen würde -> keine Ahnung, denn der Mailserver
rejected die Mail aus diesem Grund. ;-)

Aber vielleicht hilft es bei Deiner Fehlersuche ...

Tschau,

  --------------
   / h o m a s
-- 
Kill-, Filter- und Scorefiles: Die modernen Schallschutzwaende des Usenet. 

[toc] | [prev] | [next] | [standalone]

#5461

Hallo Thomas,

Thomas Gohel schrieb:
>> Als eigentlichen Absender bekomme ich in mutt foo@bar präsentiert,
>> das Subject ist leer.
> 
> Das kenne ich von einem gewissen Ticket-System, welches die Subject-
> Zeile so kaputt faltet, dass die Subject-Zeile selbst leer ist und
> der eigentliche Text in den gefalteten Zeilen steht.

falls es nicht mein kaputtes Rezept in der procmailrc ist: Vielleicht
benutzt der Absender ja tatsächlich ein solches System?

Danke jedenfalls für den Tipp.

V*

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.mailserver

csiph-web