> Can you name some of "Most mail clients"? In the past 10 years I used > many different MUAs and I'm sure I've always been subscribed to at least > one list with 2 different accounts receiving each list messages at least > twice with the same Message-ID: in all of the MUAs I used I received > each message twice with no unexpected "filtering" by the MUA (Agent, > Outlook 2000, Outlook 2003, Outlook Express, Eudora don't remember the > versions, Thunderbird since 1.0 to current, Sylpheed Claws, Gmail, The > Bat, MailWarrior, and probably others I forgot).
You are right I should have been more precise on this. I have experienced this behavior with Outlook and Exchange 2003 some time ago while testing a James based application. It took me some time to understand why I did not receive some test messages until I found out that Exchange filtered on duplicate message-id's. I was under the impression that Evolution did the same but I just tested it and it seems that I receive the duplicate messages. So you are probably right in that not all clients (most?) filter in message-id. I'm sorry for that. Still, Exchange (I tested it some time ago with Exchange 2003) did filtered on message-id's. > AddFooter is one of that cases that are fixed by this patch. > Adding a footer SHOULD NOT change the message-id. AddFooter was just an example of a mailet that modified the source message. I did not say that in this particular example (ie. AddFooter mailet) the message-id should be different after adding the footer. My point is that you do not know what kind of mailets other James users have created. > Exchange 2007? Is it Exchange 2007 Server or does Exchange identify also > a MUA product? I'd like to have at least another example. I wouldn't go > RFC uncompliant to follow M$ proprietary solutions. If Exchange 2007 is I don't think RFC2888 says something about dropping duplicate message-id's so it's probably up to the implementation to handle (or not handle) this. Exchange filters it like this: http://msexchangeteam.com/archive/2004/07/14/183132.aspx > In any way what Exchange 2007 does (from my reading) is to suppress > messages having the same Message-ID and destinated to the same > Recipient. You are right in that it only affects messages being sent to the same recipient but it still is a change of behavior that can change some behavior for some existing mailets. Personally I don't care if this patch is applied or not because I understand the possible implications but I just wanted to discuss the possible pitfalls with this patch. Personally I think the default behavior should be to change the message-id when the message has been changed unless you know that the changes did not change the message in such a way that a new message-id is required. Martijn On Sun, 2008-10-05 at 16:00 +0200, Stefano Bagnara wrote: > Martijn Brinkers ha scritto: > >> 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. > > Reading the RFC adding an header or a footer does not change the meaning > of the message and SHOULD NOT change the Message-ID. > > > 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. > > In fact the current behaviour is bad and is a BUG, in my opinion. > The behaviour introduced by the patch is the one imposed by RFC2822. > > > 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. > > Can you name some of "Most mail clients"? In the past 10 years I used > many different MUAs and I'm sure I've always been subscribed to at least > one list with 2 different accounts receiving each list messages at least > twice with the same Message-ID: in all of the MUAs I used I received > each message twice with no unexpected "filtering" by the MUA (Agent, > Outlook 2000, Outlook 2003, Outlook Express, Eudora don't remember the > versions, Thunderbird since 1.0 to current, Sylpheed Claws, Gmail, The > Bat, MailWarrior, and probably others I forgot). > > > 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)? > > AddFooter is one of that cases that are fixed by this patch. > Adding a footer SHOULD NOT change the message-id. > > At most we could discuss whether a partial match (leading to message > duplication) should create a new message-id for one of the 2 messages or > not, but not if AddFooter should change the message-id, because IMO this > is clearly mandated by RFC2822. I still think that we should not change > the Message-ID in this case because we split by recipient and it is OK > to have multiple messages with same or similar content destinated to > multiple recipients using the same Message-ID. > I should make sure the AbstractNotify mailet (and maybe the > AbstractRedirect, using a configurable behaviour) actually change the > Message-ID, but all of other mailets SHOULD NOT change the Message-ID. > > > 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 > > Exchange 2007? Is it Exchange 2007 Server or does Exchange identify also > a MUA product? I'd like to have at least another example. I wouldn't go > RFC uncompliant to follow M$ proprietary solutions. If Exchange 2007 is > the only server abusing Message-ID then it is probably a bug and maybe > they are not even aware of this. IIRC M$ is already known to ignore RFC > in this area, like Outlook 2000 (and maybe others) do not add a > Message-ID to sent messages. > > In any way what Exchange 2007 does (from my reading) is to suppress > messages having the same Message-ID and destinated to the same > Recipient. So this is a very specific case: to send the same message > with modified content to the same recipient in james you have to > duplicate it somewhere and to reroute the duplicated message to the same > recipient, otherwise it won't happen. Your "partial matcher"+AddFooter > example would not be hit by the Exchange 2007 filter because the > different mails would have different recipients. > > Stefano > > > 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] > > > > > > > --------------------------------------------------------------------- > 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]
