[
http://issues.apache.org/jira/browse/JAMES-424?page=comments#action_12434788 ]
Stefano Bagnara commented on JAMES-424:
---------------------------------------
Further considerations.
rfc2822 definition of a message:
---------
A message consists of header fields (collectively called "the header
of the message") followed, optionally, by a body. The header is a
sequence of lines of characters with special syntax as defined in
this standard. 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).
---------
An header field is defined
---------
Header fields are lines composed of a field name, followed by a colon
(":"), followed by a field body, and terminated by CRLF. A field
name MUST be composed of printable US-ASCII characters (i.e.,
characters that have values between 33 and 126, inclusive), except
colon. A field body may be composed of any US-ASCII characters,
except for CR and LF. However, a field body may contain CRLF when
used in header "folding" and "unfolding" as described in section
2.2.3. All field bodies MUST conform to the syntax described in
sections 3 and 4 of this standard.
---------
Using this rule the first line of my previous example could not be part of the
headers because it does not contain the ":", and cannot be part of the body
because there is no CRLF.
But let's analyze where we can add the Received and the results.
1) We can do like "the others" and consider it a body starting from the first
non-header like line:
------------------
Received: <new received>
This is a test
Received: <a received header>
-----------------
2) We can do like we do now:
--------------------
Received: <new received>
This is a test
Received: <a received header>
--------------------
Either ways we are changing the original message, but in the first case the
output message is an rfc2822 valid message.
RFC2821 never talks about the header/body and it simply say the SMTP should add
the "Received: <xx>" header at the TOP of the data received for tracing purpose.
RFC2822 has a lot of obsolete examples and how to handle them but they never
define how to parse a message having no header.
That said I still don't know what is the best thing to do "per RFC".
So I start looking at what other "players" do and there seem to be agreement on
the solution to handle the text as body starting from the first "non-header
like" header and maybe this is what most people would expect and what we would
probably want to do.
> Invalid DATA for Message shows up in Headers in mailstore
> ---------------------------------------------------------
>
> Key: JAMES-424
> URL: http://issues.apache.org/jira/browse/JAMES-424
> Project: James
> Issue Type: Bug
> Components: MailStore & MailRepository, SMTPServer
> Affects Versions: 2.2.0
> Environment: WinXP
> Reporter: Scott Carr
>
> If you open a connection to the server, and send in the following in the DATA
> for the message:
> This is a test
> .
> Then the data shows up in the headers instead of after the headers like it
> should. Here is what I recieved in the message:
> Return-Path: <[EMAIL PROTECTED]>
> Received: from localhost ([127.0.0.1])
> by QRGMAIN (JAMES SMTP Server 2.2.0) with SMTP ID 792
> for <[EMAIL PROTECTED]>;
> Thu, 6 Oct 2005 21:40:21 -0500 (CDT)
> this is a test
> Date: Thu, 6 Oct 2005 21:40:21 -0500 (CDT)
> From: [EMAIL PROTECTED]
> Delivered-To: [EMAIL PROTECTED]
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset=us-ascii
> Mime-Version: 1.0
> Message-ID: <[EMAIL PROTECTED]>
> Notice where 'this is a test' appears in the message.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
