552 Diese Nachricht ist nicht RFC 2822-konform [smtp-07.iol.local; LIB_670]

2088
koljanep

Ich habe bereits vor einiger Zeit Autoresponder-E-Mails eingerichtet, und plötzlich erhalte ich die folgende Nachricht als nicht zugestellt. Ich habe dies nur einmal erhalten, es scheint also kein allgemeines Problem zu sein. Ich habe RFC 2822 schnell überprüft, um zu sehen, ob das Problem offensichtlich ist, aber nein.

Die nicht zugestellte Nachricht zeigt auch nicht an, was falsch ist. Ich weiß nicht einmal, wo ich anfangen soll, und Google hat keine Ergebnisse zu diesem Fehlercode.

Die Fehlermeldung:

This is the mail system at host example.com.  I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.  For further assistance, please send mail to <postmaster>  If you do so, please include this problem report. You can delete your own text from the attached returned message.  The mail system  <joe@blow.com>: host mx.blow.com[123.123.123.123] said: 552 This message is not RFC 2822 compliant [smtp-07.iol.local; LIB_670] (in reply to end of DATA command)

Die E-Mail-Quelle:

Received: from localhost (mailsvr [127.0.0.1]) by example.com (Postfix) with ESMTP id 79B9638792F0 for <joe@blow.com>; Thu, 22 Jan 2015 11:01:38 +0100 (CET) X-Virus-Scanned: amavisd-new at example.com Received: from example.com ([127.0.0.1]) by localhost (mailsvr.example.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PBe6jEv1vZEb for <joe@blow.com>; Thu, 22 Jan 2015 11:01:32 +0100 (CET) Received: by example.com (Postfix, from userid 0) id D000B38792FC; Thu, 22 Jan 2015 11:01:29 +0100 (CET) To: joe@blow.com Subject: =?UTF-8?B?123456789==?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary = cb686159096ae4feaf2a23845e82dce0 From: Me <me@example.com> Reply-To: me@example.net Message-Id: <20150122100129.D000B38792FC@example.com> Date: Thu, 22 Jan 2015 11:01:29 +0100 (CET)  --cb686159096ae4feaf2a23845e82dce0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64   123456789123 --cb686159096ae4feaf2a23845e82dce0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64   12349678945313 --cb686159096ae4feaf2a23845e82dce0--
0
Arbeiten Sie daran aus Sicht des Clients oder des Servers? Ich habe diesen [Google-Hilfeforum-Beitrag] (https://productforums.google.com/forum/#!topic/gmail/pIhqQ8JCgGI) gefunden, der ihn adressiert. Schauen Sie sich auch diesen Artikel an (http://techedemic.com/2013/04/29/our-system-hat-det-that-this-message-isn5-7-1-not-rfc-2822-compliant) -perl-netsnmp /). CharlieRB vor 9 Jahren 0

1 Antwort auf die Frage

2
Günther Mair

Ich hatte das gleiche Problem mit libero.it (Italia OnLine) seit dem 21. Januar. Ich sehe das gleiche Problem mit Ihrer E-Mail hier.

Momentan hast du boundary = cb686159096ae4feaf2a23845e82dce0. Versuchen Sie es mit Anführungszeichen, entfernen Sie den Leerraum vor und nach dem Gleichheitszeichen und fügen Sie etwas wie "= _" hinzu, um so etwas zu erhalten boundary="cb686159096ae4feaf2a23845e82dce0". Hoffentlich werden die Dinge mit IOL wieder normal.

Nach einem Blick auf RFC 2822, RFC 2045 und RFC 2046 (und verknüpfte und aktualisierte Dokumente) möchte ich sagen, dass die Vorstellung von This message is not RFC 2822 compliant nicht richtig ist . RFC 2046 schlägt nur vor , dass "das Einschließen der Randparameterwerte in Anführungszeichen niemals weh tut". Interessanter als das wäre auch der Hinweis in RFC 2045, der uns sagt, eine Zeichenfolge wie "= _" innerhalb einer Grenze zu verwenden (siehe unten).

Hoffe das hilft!

RFC 2045 http://www.rfc-editor.org/rfc/rfc2045.txt

Since the hyphen character ("-") may be represented as itself in the Quoted-Printable encoding, care must be taken, when encapsulating a quoted-printable encoded body inside one or more multipart entities, to ensure that the boundary delimiter does not appear anywhere in the encoded body. (A good strategy is to choose a boundary that includes a character sequence such as "=_" which can never appear in a quoted-printable body. See the definition of multipart messages in RFC 2046.)

RFC 2046 http://www.rfc-editor.org/rfc/rfc2046.txt

WARNING TO IMPLEMENTORS: The grammar for parameters on the Content- type field is such that it is often necessary to enclose the boundary parameter values in quotes on the Content-type line. This is not always necessary, but never hurts.
Irgendwie bekomme ich bei der Implementierung einen fehlerhaften Header-Fehler. `INVALID HEADER: BAD MIME HEADERS ODER BAD MIME STRUCTURE` `MIME-Fehler: Fehler: Unerwartetes Ende der Präambel`. Mein Header sieht etwas aus wie: MIME-Version: 1.0 Content-Type: multipart / alternative; border = "_ = _ 1173e0e47e01a3ff4eaaa7c11e92d1ec _ = _" Von: ..... `. Was mache ich falsch? koljanep vor 9 Jahren 0
Hallo kolja .... Ich denke, das ist jetzt ein ganz anderes Thema und gerade dieses Stück reicht nicht aus, um noch mehr Feedback / Informationen zu geben. Versuchen Sie es mit etwas wie 'Content-Type: multipart / alternative; border = "- = _ cb686159096ae4feaf2a23845e82dce0" `und stellen Sie sicher, dass Sie die exakte Grenze verwenden, um jeden Abschnitt einzuführen (was dazu führen würde, dass es ---- = _ cb686159096ae4feaf2a23845e82dce0` erscheint). Wenn Sie sich nicht sicher sind, wie Sie diese Dinge tun sollen, ist es vielleicht besser, wenn Sie sich etwas wie ** PHP Mailer ** ansehen. Günther Mair vor 9 Jahren 0

Verwandte Probleme