James Server
  1. James Server
  2. JAMES-875

Message-ID changed by mailets (MSGID_FROM_MTA_HEADER changed)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.1, Trunk
    • Fix Version/s: 3.0-M1
    • Component/s: SMTPServer
    • Labels:
      None
    • Environment:
      Linux (Fedora Core 8)

      Description

      I noticed that emails sent using my James Server have this header when they are delivered :

      X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER

      This is added by SpamAssassin telling that the Message-Id was generated by a relay, rather than by the user agent.

      If I use the same mailing software but not James to send an email, I don't have this problem.
      I looked in the configuration files of James and couldn't find anything about this msgid. Why is James changing that ?

      1. config-james.xml
        78 kB
        Marc SCHNEIDER

        Activity

        Marc SCHNEIDER created issue -
        Hide
        Stefano Bagnara added a comment -

        What mailets do you you have in your processing?

        I this this may be an issue with any mailet making any change (like adding an header) that simply call mimemessage.saveChanges and this make JavaMail to generate a new Message-ID.

        Maybe we should work around this JavaMail feature because we don't want to change the Message-ID of messages just because we do some manipulation, but I'd like to be sure this is the issue you are hitting before evaluating a solution.

        Show
        Stefano Bagnara added a comment - What mailets do you you have in your processing? I this this may be an issue with any mailet making any change (like adding an header) that simply call mimemessage.saveChanges and this make JavaMail to generate a new Message-ID. Maybe we should work around this JavaMail feature because we don't want to change the Message-ID of messages just because we do some manipulation, but I'd like to be sure this is the issue you are hitting before evaluating a solution.
        Hide
        Stefano Bagnara added a comment -

        In James code we seems to have a workaround in AbstractRedirect:


        newMail.setMessage(new MimeMessage(originalMail.getMessage()) {
        protected void updateHeaders() throws MessagingException {
        if (getMessageID() == null) super.updateHeaders();
        else

        { modified = false; }

        }
        });


        That code was added as a workaound in the specific case of the AbstractRedirect:
        http://svn.apache.org/viewvc?view=rev&revision=108787

        Maybe we need a more generic solution in the MimeMessageWrapper
        overriding "protected void updateMessageID() throws MessagingException" with


        protected void updateMessageID() throws MessagingException

        { if (getMessageID() == null) super.updateMessageID(); }
        Show
        Stefano Bagnara added a comment - In James code we seems to have a workaround in AbstractRedirect: newMail.setMessage(new MimeMessage(originalMail.getMessage()) { protected void updateHeaders() throws MessagingException { if (getMessageID() == null) super.updateHeaders(); else { modified = false; } } }); That code was added as a workaound in the specific case of the AbstractRedirect: http://svn.apache.org/viewvc?view=rev&revision=108787 Maybe we need a more generic solution in the MimeMessageWrapper overriding "protected void updateMessageID() throws MessagingException" with protected void updateMessageID() throws MessagingException { if (getMessageID() == null) super.updateMessageID(); }
        Hide
        Stefano Bagnara added a comment -

        From RFC2822:


        Note: There are many instances when messages are "changed", but those
        changes do not constitute a new instantiation of that message, and
        therefore the message would not get a new message identifier. For
        example, when messages are introduced into the transport system, they
        are often prepended with additional header fields such as trace
        fields (described in section 3.6.7) and resent fields (described in
        section 3.6.6). The addition of such header fields does not change
        the identity of the message and therefore the original "Message-ID:"
        field is retained. In all cases, it is the meaning that the sender
        of the message wishes to convey (i.e., whether this is the same
        message or a different message) that determines whether or not the
        "Message-ID:" field changes, not any particular syntactic difference
        that appears (or does not appear) in the message.


        IMHO this means that by default mailets should not change the Message-ID unless they want to do this by purpose so the above change seems to be appropriate.

        Opinions?

        Show
        Stefano Bagnara added a comment - From RFC2822: Note: There are many instances when messages are "changed", but those changes do not constitute a new instantiation of that message, and therefore the message would not get a new message identifier. For example, when messages are introduced into the transport system, they are often prepended with additional header fields such as trace fields (described in section 3.6.7) and resent fields (described in section 3.6.6). The addition of such header fields does not change the identity of the message and therefore the original "Message-ID:" field is retained. In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. IMHO this means that by default mailets should not change the Message-ID unless they want to do this by purpose so the above change seems to be appropriate. Opinions?
        Stefano Bagnara made changes -
        Field Original Value New Value
        Summary MSGID_FROM_MTA_HEADER changed Message-ID changed by mailets (MSGID_FROM_MTA_HEADER changed)
        Fix Version/s Trunk [ 12312135 ]
        Fix Version/s 2.3.2 [ 12312493 ]
        Affects Version/s Trunk [ 12312135 ]
        Hide
        Marc SCHNEIDER added a comment -

        Here is my config.xml and you can see all the mailets that are activated.

        Show
        Marc SCHNEIDER added a comment - Here is my config.xml and you can see all the mailets that are activated.
        Marc SCHNEIDER made changes -
        Attachment config-james.xml [ 12391543 ]
        Hide
        Danny Angus added a comment -

        this was discussed with Sun, it is a "feature" of JavaMail and they justify it by saying that javamail is a client API and any changes made by a MUA should result in a new message.

        The approved workaround is as shown, which was developed specifically after the discussion with the Sun guys.

        Show
        Danny Angus added a comment - this was discussed with Sun, it is a "feature" of JavaMail and they justify it by saying that javamail is a client API and any changes made by a MUA should result in a new message. The approved workaround is as shown, which was developed specifically after the discussion with the Sun guys.
        Hide
        Stefano Bagnara added a comment -

        @Danny: I don't understand if you do think it is good to have the workaround moved to the MimeMessageWrapper or your instead prefer to leave it as is and have each mailet altering the content to workaround Javamail.

        Show
        Stefano Bagnara added a comment - @Danny: I don't understand if you do think it is good to have the workaround moved to the MimeMessageWrapper or your instead prefer to leave it as is and have each mailet altering the content to workaround Javamail.
        Hide
        Danny Angus added a comment -

        @stefano. Difficult question...

        In the wrapper makes james behave like an MTA by default but may confuse people who are used to JavaMail.

        If we could somehow set a flag or param to hint that a new id is required then I'd definitely say it should be in the wrapper, because 99 times out of 100 James users will want to alter an existing message, not effectively create a new one.

        (This issue also causes problems for MUA's that use ID's and In-reply-to id's to organise threads)

        Show
        Danny Angus added a comment - @stefano. Difficult question... In the wrapper makes james behave like an MTA by default but may confuse people who are used to JavaMail. If we could somehow set a flag or param to hint that a new id is required then I'd definitely say it should be in the wrapper, because 99 times out of 100 James users will want to alter an existing message, not effectively create a new one. (This issue also causes problems for MUA's that use ID's and In-reply-to id's to organise threads)
        Hide
        Robert Burrell Donkin added a comment -

        I would like to try to push out a 3.2.2 sometime soon

        I think that this has some small risk of breaking some mailets that are coded to expect the original behaviour (which I agree is unintuitive)

        I'll push this fix back into a later version unless people jump in

        Show
        Robert Burrell Donkin added a comment - I would like to try to push out a 3.2.2 sometime soon I think that this has some small risk of breaking some mailets that are coded to expect the original behaviour (which I agree is unintuitive) I'll push this fix back into a later version unless people jump in
        Hide
        Robert Burrell Donkin added a comment -

        This consensus on list is that this should be committed. So unless there are any objections sometime soon I plan to do that

        Show
        Robert Burrell Donkin added a comment - This consensus on list is that this should be committed. So unless there are any objections sometime soon I plan to do that
        Hide
        Stefano Bagnara added a comment -

        Here is a tentative text for the release notes as this is an important issue:
        ------------------------------
        IMPORTANT If you're upgrading from a previous release of James please note that JAMES Server 2.3.2 changes a behaviour in the management of the MessageID header. Until 2.3.1 JAMES was chaning the MessageID of messages in many many places and the MessageID was changed to almost every message relayed. Now this is not correct as when the message is relayed a server must not alter the MessageID by specification. So we changed the main message handling object to remove the automatic MessageID update. This means that since 2.3.2 if you use a Mailet that clones a MimeMessage in order to create a new, different, message you'll have to take care updating the MessageID.
        -------------------------------

        Please, Robert, fix my english/verbosity as you think appropriate.

        Show
        Stefano Bagnara added a comment - Here is a tentative text for the release notes as this is an important issue: ------------------------------ IMPORTANT If you're upgrading from a previous release of James please note that JAMES Server 2.3.2 changes a behaviour in the management of the MessageID header. Until 2.3.1 JAMES was chaning the MessageID of messages in many many places and the MessageID was changed to almost every message relayed. Now this is not correct as when the message is relayed a server must not alter the MessageID by specification. So we changed the main message handling object to remove the automatic MessageID update. This means that since 2.3.2 if you use a Mailet that clones a MimeMessage in order to create a new, different, message you'll have to take care updating the MessageID. ------------------------------- Please, Robert, fix my english/verbosity as you think appropriate.
        Robert Burrell Donkin made changes -
        Assignee Robert Burrell Donkin [ robertburrelldonkin ]
        Hide
        Robert Burrell Donkin added a comment -

        Stefano's suggested fix should now be committed. Please test the latest 2.3 code and ensure that this fix is working correctly

        Show
        Robert Burrell Donkin added a comment - Stefano's suggested fix should now be committed. Please test the latest 2.3 code and ensure that this fix is working correctly
        Robert Burrell Donkin made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Gavin Chiu added a comment -

        Hi,

        I have the latest JAMES 2.3.2 running and I am getting this error in the Barracuda header report from all the email I send from this JAMES mail server:

        X-Barracuda-Spam-Score: 1.50
        X-Barracuda-Spam-Status: No, SCORE=1.50 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE, MSGID_FROM_MTA_HEADER, MSGID_FROM_MTA_HEADER_2
        X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.30982
        Rule breakdown below
        pts rule name description
        ---- ---------------------- --------------------------------------------------
        -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes
        verification
        0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature
        0.00 HTML_MESSAGE BODY: HTML included in message
        0.00 MSGID_FROM_MTA_HEADER Message-Id was added by a relay
        1.50 MSGID_FROM_MTA_HEADER_2 Message-Id was added by a relay

        Have I implement the new version incorrectly? Please advise.

        Thanks

        Show
        Gavin Chiu added a comment - Hi, I have the latest JAMES 2.3.2 running and I am getting this error in the Barracuda header report from all the email I send from this JAMES mail server: X-Barracuda-Spam-Score: 1.50 X-Barracuda-Spam-Status: No, SCORE=1.50 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE, MSGID_FROM_MTA_HEADER, MSGID_FROM_MTA_HEADER_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.30982 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MSGID_FROM_MTA_HEADER Message-Id was added by a relay 1.50 MSGID_FROM_MTA_HEADER_2 Message-Id was added by a relay Have I implement the new version incorrectly? Please advise. Thanks
        Norman Maurer made changes -
        Fix Version/s 3.0-M1 [ 12314294 ]
        Fix Version/s Trunk [ 12312135 ]
        Fix Version/s 2.3.2 [ 12312493 ]
        Mark Thomas made changes -
        Workflow jira [ 12443058 ] Default workflow, editable Closed status [ 12566527 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12566527 ] jira [ 12582073 ]

          People

          • Assignee:
            Robert Burrell Donkin
            Reporter:
            Marc SCHNEIDER
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development