Martijn Brinkers ha scritto: >>> 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 > > Cyrus IMAP seems to do something similar > > Duplicate Delivery Suppression > A message is considered a duplicate if two copies of a message with the > same message-id and the same envelope receipient are received. Cyrus > uses the duplicate delivery database to hold this information, and it > looks approximately 3 days back in the default install. > > http://cyrusimap.web.cmu.edu/imapd/overview.html#duplicate > > > Like I said, I'm not saying this patch should not be applied I just wanted to > point out the possible gotchas
So it seems both Exchange and Cyrus IMAP (optionally!!) suppress messages with duplicated Message-IDs ONLY when the envelope recipient is also the same. I'd like to have a pratical mailet configuration example that duplicate a message change one of the messages content and deliver both messages to the same recipient and this is a needed behaviour. If no one can provide an use case (I want to see the mailet configuration we are talking about!) then I think we should simply fix the bug and ignore this minor issue with the compliant behaviour. Stefano > Martijn > > On Sun, 2008-10-05 at 16:38 +0200, Martijn Brinkers wrote: >>> 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. > > > > --------------------------------------------------------------------- > 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]
