> Yes, do you see a problem with this? That depends on the mailets you use. What if you split a message and for one part of the recipients you change something to the message (like add a header or disclaimer) and the other part you sent the message as is. Currently the message that was not modified has the original message-id and the modified message has a new message-id. With the new patch both messages have the same message-id. Whether that is problematic or not is highly dependend on what has been changed to the message. Most mail clients that I know of filter messages based on message-id, ie. it just discards messages with duplicate message-id's even if the message content is different. I therefore think the current behavior is the correct behavior because the 'patch' does do not 'know' whether the message has been duplicated and modified in such a way that a new message-id should be created or not.
> Can you provide a use case where a mailet starts from an user-created > message and alter its content to produce something with a different meaning? AddFooter mailet? Of course it's debatable whether a message with a footer should get a new message-id or not but what if a message is split and two different footers are added (because for example sending a message to a specific country requires a different footer)? Changing the default behavior on handling message-id's could result in dropping of messages example: http://forums.msexchange.org/m_1800460467/mpage_1/key_/tm.htm#1800460467 Martijn On Sun, 2008-10-05 at 13:22 +0200, Stefano Bagnara wrote: > Martijn Brinkers ha scritto: > > But what happens with messages that are split into multiple messages > > (because of a matcher)? Do they get the same message-id? > > Yes, do you see a problem with this? > It seems this also happen when your MUA sends a message to multiple > recipients on different domains. > The MTA will send the same message to each recipient MDA and they all > will share the same Message-ID, please correct me if you know of MTA > that do alter the Message-ID in this case. > > > And what if the message has been changed in such a way that the message is > > no longer similar to the original message? Should it get a new message-id > > when the message content has been changed completely? > > A mailet can simply call setHeader('Message-ID', 'xxxx') whener there is > a need to change it. > > >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. > ---- > > Can you provide a use case where a mailet starts from an user-created > message and alter its content to produce something with a different meaning? > > If a mailet sends a different message based on the input message it will > usually create a new mimemessage: there is no reason to alter the input > message if you don't have to keep some/most of its content. > > Stefano > > > Martijn Brinkers > > > > On Sun, 2008-10-05 at 00:31 +0200, Stefano Bagnara wrote: > >> Hi all, > >> > >> I just updated my local server to include the patch I proposed in > >> JAMES-875. > >> > >> This basically adds this code to MimeMessageWrapper: > >> ----- > >> protected void updateMessageID() throws MessagingException { > >> if (getMessageID() == null) super.updateMessageID(); > >> } > >> ------- > >> > >> This way my Message-IDs are presereved after Javamail's > >> mimeMessage.saveChanges calls. > >> > >> Most of our mailets are otherwise altering the Message-ID and this can > >> lead to many issues (SpamAssassin score increased, Domain-Key > >> verification failing...). > >> > >> I think this should be applied ASAP to trunk and also backported to 2.3 > >> branch. > >> > >> Opinions? > >> > >> Stefano > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
