The following comment has been added to this issue:
Author: Hes Siemelink
Created: Thu, 6 May 2004 8:09 AM
Body:
Here is Danny Angus's original response to this issue:
----
Hes,
The following extracts from the RFC's[1][2] indicate that a return path should only
contain a single address, which MUST be enclosed in angle brackets eg <[EMAIL
PROTECTED]>
Your test case is non-comformant with the spec on two counts,
a) more than one Return-path header
b) no angle brackets around the address specification
Now I agree that james' current behaviour isn't compliant or much use in this
situation, but would also contend that James should not make any decision about which
is the "right" header to use, however arbitrary.
I would therfore propose that in this case James either ignore all the return-path
headers and relay the mail untouched, or that James remove all the return-path headers
and replace with one created from the envelope sender.
IMHO no other action is both compliant and reasonable.
d.
[1]From RFC2821:
A message-originating SMTP system SHOULD NOT send a message that
already contains a Return-path header. SMTP servers performing a
relay function MUST NOT inspect the message data, and especially not
to the extent needed to determine if Return-path headers are present.
SMTP servers making final delivery MAY remove Return-path headers
before adding their own.
The primary purpose of the Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures
are to be sent. For this to be unambiguous, exactly one return path
SHOULD be present when the message is delivered. Systems using RFC
822 syntax with non-SMTP transports SHOULD designate an unambiguous
address, associated with the transport envelope, to which error
reports (e.g., non-delivery messages) should be sent.
[2]From RFC 2822
return = "Return-Path:" path CRLF
path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) /
obs-path
addr-spec = local-part "@" domain
----
[Additional comment from Hes]
The behavior is the same when adding brackets to the email addresses.
I agree with Danny that a more sensible action should be taken. I prefer that the mail
should not be touched, since I have configured James as a relay server and according
to the RFC 2821 the headers, faulty as they are, should not be touched.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JAMES-281?page=comments#action_35432
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JAMES-281
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JAMES-281
Summary: Return-Path twice in header
Type: Bug
Status: Unassigned
Priority: Minor
Project: James
Components:
SMTPServer
Versions:
2.1.3
2.2.0RC1
2.2.0RC2
Assignee:
Reporter: Hes Siemelink
Created: Thu, 6 May 2004 8:03 AM
Updated: Thu, 6 May 2004 8:09 AM
Description:
Hello
I posted about this problem a while ago on the list. I see that James 2.2.0RC2 still
contains this issue so I've taken the liverty of creating a Jira entry.
We experienced some unexpected behavior with James 2.1.3 when sending a message that
has two Return-Path headers.
An example of such a message:
Return-Path: [EMAIL PROTECTED]
From: "Brinkers" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Return-Path mail
Return-Path: [EMAIL PROTECTED]
Date: Tue, 9 Dec 2003 22:36:33 -0500
Hoi
James transforms this into something like
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
content-class: urn:content-classes:message
Subject:
Date: Thu, 15 Jan 2004 12:02:16 +0100
[EMAIL PROTECTED]
Received: from vallum.intra.izecom.com ([192.168.0.1])
by uffizi.intra.izecom.com (JAMES SMTP Server 2.1.3) with SMTP
ID 302
for <[EMAIL PROTECTED]>;
Thu, 15 Jan 2004 12:02:19 +0100 (CET)
From: "Brinkers" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Test Mail
Date: Tue, 9 Dec 2003 22:36:33 -0500
Hoi
It seems that new headers are created and the original headers start with after a
blank line, causing them to be interpreted as a message body.
In Outlook, this is displayed as a message without Subject or From field, where the
message body starts with the '[EMAIL PROTECTED]' followed by the original headers.
Now putting the Return-Path twice in your headers is probably not a good idea, but we
do happen to have some emails that have that in our test set and would like to process
them in a reasonable way.
So we investigated the James source code trying to find the cause for this unexpected
behavior.
In org.apache.james.smtpserver.SMTPHandler in the method
processMailHeaders() we found the following call to retrieve the Return-Path header.
// Determine the Return-Path
String returnPath =
headers.getHeader(RFC2822Headers.RETURN_PATH,
"\r\n");
This roughly means "Give me all Return-Path headers separated by line breaks.". Later
on, this returnPath String is put on top of all headers.
We deduced that if there is more than one Return-Path header, this will result in
something like
Return-Path: [EMAIL PROTECTED]
[EMAIL PROTECTED]
From: "Brinkers" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Return-Path mail
Date: Tue, 9 Dec 2003 22:36:33 -0500
Hoi
where that the second line ('[EMAIL PROTECTED]') is interpreted as the start of the
message body later on, causing new headers to be invented and the old headers to
dispappear on the message body.
We changed the call to get the getHeader() in processMailHeaders() to pass a null
argument:
// Determine the Return-Path
String returnPath =
headers.getHeader(RFC2822Headers.RETURN_PATH, null);
which roughly means "Give only one Return-Path header".
After recompiling and deploying James, our test mails passed James correctly.
We would appreciate it if this fix, or a similar one, could be included in the next
James release.
Thank you
Hes Siemelink
Izecom BV
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
