У меня была такая же проблема с libero.it (Italia OnLine) начиная с 21 января. Я вижу ту же проблему с вашей электронной почтой здесь.
В настоящее время у вас есть boundary = cb686159096ae4feaf2a23845e82dce0. Попробуйте поместить вокруг него кавычки, убрав пропуски впереди и после знака равенства, и добавьте что-то вроде «= _», чтобы получить что-то подобное boundary="cb686159096ae4feaf2a23845e82dce0". Надеюсь, что с ИОЛ все вернется на круги своя.
Посмотрев на RFC 2822, RFC 2045 и RFC 2046 (а также связанные и обновленные документы), я бы осмелился сказать, что понятие This message is not RFC 2822 compliant неверно . RFC 2046 предлагает только то, что «заключение значений параметров границы в кавычки никогда не повредит». Более интересным было бы также примечание в RFC 2045, в котором говорится, что мы должны использовать последовательность символов, такую как «= _» внутри границы (см. Ниже).
Надеюсь это поможет!
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.