Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1.3, 2.2.0
    • Fix Version/s: 2.2.0
    • Component/s: SMTPServer
    • Labels:
      None

      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: 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.

      Thank you

      Hes Siemelink
      Izecom BV

        Activity

        Hide
        Noel J. Bergman added a comment -

        Fixed, and verified by reporter.

        Show
        Noel J. Bergman added a comment - Fixed, and verified by reporter.
        Hide
        Noel J. Bergman added a comment -

        Should be resolved in 2.2.0RC3

        Show
        Noel J. Bergman added a comment - Should be resolved in 2.2.0RC3
        Hide
        Noel J. Bergman added a comment -

        As much as I'd like not to touch the headers, we have to do so. This is not the point in the code where we are permitted to remove the headers and replace them; that would happen in LocalDelivery. We've received the Return-Path headers and need to preserve them, however we also need to add our Received: header. The fix would be:

        StringTokenizer tokenizer = new StringTokenizer(returnPath, "\r\n");
        while(tokenizer.hasMoreTokens())

        { String path = tokenizer.nextToken(); newHeaders.addHeaderLine(RFC2822Headers.RETURN_PATH + ": " + path); }

        Testing with data:

        "testuser@example.com\r\nanother_testuser@example.com"
        "<>"
        "<postmaster@localhost>"

        results in:

        Return-Path: testuser@example.com
        Return-Path: another_testuser@example.com

        Return-Path: <>

        Return-Path: <postmaster@localhost>

        as desired.

        Show
        Noel J. Bergman added a comment - As much as I'd like not to touch the headers, we have to do so. This is not the point in the code where we are permitted to remove the headers and replace them; that would happen in LocalDelivery. We've received the Return-Path headers and need to preserve them, however we also need to add our Received: header. The fix would be: StringTokenizer tokenizer = new StringTokenizer(returnPath, "\r\n"); while(tokenizer.hasMoreTokens()) { String path = tokenizer.nextToken(); newHeaders.addHeaderLine(RFC2822Headers.RETURN_PATH + ": " + path); } Testing with data: "testuser@example.com\r\nanother_testuser@example.com" "<>" "<postmaster@localhost>" results in: Return-Path: testuser@example.com Return-Path: another_testuser@example.com Return-Path: <> Return-Path: <postmaster@localhost> as desired.
        Hide
        Hes Siemelink added a comment -

        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 <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


        [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.

        Show
        Hes Siemelink added a comment - 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 <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 [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.

          People

          • Assignee:
            Noel J. Bergman
            Reporter:
            Hes Siemelink
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development