SMTP Header - RCF 2822 and extra CR (Carriage return)

Question

Hi,
I have a customer with trouble reading emails from one business partner, all other emails comes through.
I have located the problem to an extra "\r" (Carriage Return 0x0d) i the incoming mail header.
According to RFC-2822 (http://tools.ietf.org/html/rfc2822):
* The body is simply a sequence of characters that follows the header and is separated from the header by an empty line (i.e., a line with nothing preceding the CRLF).
Part of a problem header:
Subject: KxxxxS + "\r\n"
X-PHP-Originating-Script: 508:ajax_final_step.php + "\r\n"
MIME-Version: 1.0 + "\r\r\n"
Content-type: text/html; charset=UTF-8 + "\r\r\n"
From: BxxxxxS <[email protected]> + "\r\n"
Message-Id: <[email protected]> + "\r\n"
Date: Fri, 1 Aug 2014 11:04:39 +0200 (CEST) + "\r\n"
With GWIA 2012 version 12.0.2 "03/25/13" running on SLES 11 SP1, the above header translate into:
Subject: KxxxxxS + "\r\n"
X-PHP-Originating-Script: 508:ajax_final_step.php + "\r\n"
MIME-Version: 1.0 + "\r"
"\r\n"
Content-type: text/html; charset=UTF-8 + "\r"
\r\n"
From: BxxxxxS <[email protected]> + "\r\n"
Message-Id: <[email protected]> + "\r\n"
Date: Fri, 1 Aug 2014 11:04:39 +0200 (CEST) + "\r\n"
This means that the header ends before "Content-type: text/html; charset=UTF-8" and the user gets an empty email.
The contents can been seen in "message source", but with all the header and HTML ****, and normal users can't decode the content.
Is this a Groupwise GWIA problem or a problem at the business partner?
The partner say outgoing email works with Gmail, Exchange, Office 365 and Notes - and will not fix.
If just RFC-2822 was more precise and did not contain the I.E. in "(i.e., a line with nothing preceding the CRLF)".
Kind regards
Uffe Bager

Answer 1

Hi.
That's an interesting issue. The problem evolves around the question if
a bare carriage return is "something" when in front of a CRLF or not.
One thing is certain though: The Business Partner sending those mails is
actively asking for trouble galore by completely without sense or reason
doing something within the headers that totally stretches the rules.
Personally, I'd sayfor good measurement, Groupwise should indeed
consider the bare CR before the CRLF as "something", aka should *not*
consider the following CRLF as theend of the header. But then somebody
else will most likely come aorund, break it and lcaim that it shouldn't
be doing this.
The real question is: Why is the code of the sender here doing this? Is
there any business casesending a line with a bland CR within the
headers? If not (and of course there's noreason to do this on purpose),
then this is just sloppy coding asking for trouble.
And the old argument "but it works with others" just makes me mad. I
usually reply something along the line that others also drive their car
completely drunk and very often don't get cought by the cops and don't
kill someone doing so. *Some* people start to think then. Rarely though.
Am 01.08.2014 12:46, schrieb uffbag:
>
> Hi,
>
> I have a customer with trouble reading emails from one business partner,
> all other emails comes through.
>
> I have located the problem to an extra "\r" (Carriage Return 0x0d) i the
> incoming mail header.
CU,
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de