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.