☰

552 此邮件不符合 RFC 2822 标准

tag-icon • tag-icon email smtp email-bounces
552 此邮件不符合 RFC 2822 标准

我已经设置了自动回复电子邮件一段时间了，突然收到以下未送达的消息。我只收到过一次，所以这似乎不是一个普遍的问题。我快速检查了 RFC 2822，看看问题是否很明显，但不是。

未送达的消息也没有表明哪里出了问题。我甚至不知道从哪里开始，谷歌搜索也没有找到关于这个错误代码的结果。

错误信息：

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)

電子郵件來源：

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

答案1

从 1 月 21 日开始，我在使用 libero.it (Italia OnLine) 时也遇到了同样的问题。我在这里看到您的电子邮件也存在同样的问题。

目前您有boundary = cb686159096ae4feaf2a23845e82dce0。尝试在其周围加上引号，删除等号前后的空格，并向其添加类似“=_”的内容，以便获得类似这样的内容boundary="cb686159096ae4feaf2a23845e82dce0"。希望 IOL 一切恢复正常。

在查看了 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.

相关内容