0

I have had autoresponder emails set up for a while already, and suddenly I get the following message as undelivered. I only got this one time, so it seems not to be a general problem. I checked RFC 2822 quickly to see if the problem is something obvious, but no.

The undelivered message also does not indicate what is wrong. I don't even know where to start, and Google has no results on this error code.

The error message:

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

<joe@blow.com>: 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)

The email source:

Received: from localhost (mailsvr [127.0.0.1])
    by example.com (Postfix) with ESMTP id 79B9638792F0
    for <joe@blow.com>; 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 <joe@blow.com>;
    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: joe@blow.com
Subject: =?UTF-8?B?123456789==?=
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary = cb686159096ae4feaf2a23845e82dce0
From: Me <me@example.com>
Reply-To: me@example.net
Message-Id: <20150122100129.D000B38792FC@example.com>
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--
NoviceLinux-WindowsGeek
  • 372
Kolja
  • 217

1 Answers1

2

I've had the same problem with libero.it (Italia OnLine) starting on January 21st. I see the same issue with your email here.

Currently you have boundary = cb686159096ae4feaf2a23845e82dce0. Try putting quotes around it, removing the whitespace in front and after the equal sign and add something like "=_" to it in order to get something like this boundary="cb686159096ae4feaf2a23845e82dce0". Hopefully things will then get back to normal with IOL.

After looking at RFC 2822, RFC 2045 and RFC 2046 (and linked and update documents) I would dare say that the notion of This message is not RFC 2822 compliant is not correct. RFC 2046 is only suggesting that "enclosing the boundary parameter values in quotes never hurts". More interesting than that would also be the note in RFC 2045 telling us to use a character sequence like "=_" inside of a boundary (see below).

Hope this helps!

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.
Günther Mair
  • 36