Ich habe schon seit einiger Zeit Autoresponder-E-Mails eingerichtet und plötzlich erhalte ich die folgende Meldung als nicht zugestellt. Ich habe sie 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 gibt auch keinen Hinweis darauf, 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
<[email protected]>: 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 <[email protected]>; 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 <[email protected]>;
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: [email protected]
Subject: =?UTF-8?B?123456789==?=
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary = cb686159096ae4feaf2a23845e82dce0
From: Me <[email protected]>
Reply-To: [email protected]
Message-Id: <[email protected]>
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--
Antwort1
Ich habe seit dem 21. Januar dasselbe Problem mit libero.it (Italia OnLine). Ich sehe dasselbe Problem mit Ihrer E-Mail hier.
Derzeit haben Sie boundary = cb686159096ae4feaf2a23845e82dce0. Versuchen Sie, Anführungszeichen darum zu setzen, die Leerzeichen vor und nach dem Gleichheitszeichen zu entfernen und etwas wie "=_" hinzuzufügen, um etwa Folgendes zu erhalten boundary="cb686159096ae4feaf2a23845e82dce0". Hoffentlich wird dann mit IOL alles wieder normal.
Nach der Durchsicht von RFC 2822, RFC 2045 und RFC 2046 (und den damit verknüpften und aktualisierten Dokumenten) wage ich zu behaupten, dass die Vorstellung vonThis message is not RFC 2822 compliant das ist nicht richtig. RFC 2046 ist nurvorschlagendass „es nie schadet, die Randparameterwerte in Anführungszeichen zu setzen“. Interessanter wäre auch der Hinweis in RFC 2045, der uns auffordert, innerhalb einer Grenze eine Zeichenfolge wie „=_“ 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.