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]
