552 Esta mensagem não é compatível com RFC 2822 [smtp-07.iol.local; LIB_670]

Question

Já recebi e-mails de autoresponder por algum tempo e, de repente, recebo a seguinte mensagem como não entregue. Eu só tenho uma vez, então parece não ser um problema geral. Eu verifiquei o RFC 2822 rapidamente para ver se o problema é algo óbvio, mas não.

A mensagem não entregue também não indica o que está errado. Nem sei por onde começar e o Google não tem resultados nesse código de erro.

A mensagem de erro:

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)

A fonte de e-mail:

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--

    

Answer 1

Eu tive o mesmo problema com o libero.it (Italia OnLine) a partir de 21 de janeiro. Eu vejo o mesmo problema com o seu email aqui.

Atualmente, você tem boundary = cb686159096ae4feaf2a23845e82dce0 . Tente colocar aspas em torno dele, removendo o espaço em branco na frente e após o sinal de igual e adicione algo como "= _" para obter algo como este boundary="cb686159096ae4feaf2a23845e82dce0" . Espero que as coisas voltem ao normal com a LIO.

Depois de olhar para RFC 2822, RFC 2045 e RFC 2046 (e documentos vinculados e atualização) eu ouso dizer que a noção de This message is not RFC 2822 compliant não está correta . O RFC 2046 está apenas sugerindo que "cercar os valores do parâmetro de limite entre aspas nunca é demais". Mais interessante do que isso seria também a nota na RFC 2045 nos dizendo para usar uma sequência de caracteres como "= _" dentro de um limite (veja abaixo).

Espero que isso ajude!

RFC 2045 link

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 link

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.