james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Angus <Danny_An...@slc.co.uk>
Subject Re: Return-Path header twice in message
Date Thu, 01 Apr 2004 08:27:56 GMT




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 <server-user@james.apache.org>

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



|---------+---------------------------->
|         |           "Hes Siemelink"  |
|         |           <hes-list@izecom.|
|         |           com>             |
|         |                            |
|         |           30/03/2004 02:29 |
|         |           PM               |
|         |           Please respond to|
|         |           "James Developers|
|         |           List"            |
|         |                            |
|---------+---------------------------->
  >---------------------------------------------------------------------------------------------------------------|
  |                                                                                      
                        |
  |       To:       <server-dev@james.apache.org>                                  
                              |
  |       cc:                                                                            
                        |
  |       Subject:  Return-Path header twice in message                                  
                        |
  >---------------------------------------------------------------------------------------------------------------|




Hello

I posted about this problem a while ago on the user list (as I am
a James user, not a developer), but didn't get much response. This
time, I'm including a patch; I hope that someone will pick it up.

We are experiencing 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: testuser@example.com
    From: "Brinkers" <testuser@example.com>
    To: <testuser@example.com>
    Subject: Return-Path mail
    Return-Path: another_testuser@example.com
    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

    another_testuser@example.com
    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 <hes@secure.izemail.com>;
              Thu, 15 Jan 2004 12:02:19 +0100 (CET)
    From: "Brinkers" <testuser@example.com>
    To: <testuser@example.com>
    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
'another_testuser@example.com' 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: testuser@example.com
    another_testuser@example.com
    From: "Brinkers" <testuser@example.com>
    To: <testuser@example.com>
    Subject: Return-Path mail
    Date: Tue, 9 Dec 2003 22:36:33 -0500

    Hoi

where that the second line ('another_testuser@example.com') 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. The patch is attached.

Thank you

    Hes Siemelink
    Izecom BV
(See attached file: SMTPHandler-patch.txt)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you
are not the intended recipient (or responsible for delivery of the message to the intended
recipient) please notify us immediately on 0141 306 2050 and delete the message from your
computer. You may not copy or forward it or use or disclose its contents to any other person.
As Internet communications are capable of data corruption Student Loans Company Limited does
not accept any  responsibility for changes made to this message after it was sent. For this
reason it may be inappropriate to rely on advice or opinions contained in an e-mail without
obtaining written confirmation of it. Neither Student Loans Company Limited or the sender
accepts any liability or responsibility for viruses as it is your responsibility to scan attachments
(if any). Opinions and views expressed in this e-mail are those of the sender and may not
reflect the opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the presence of computer
viruses.

**************************************************************************


Mime
View raw message