Matt Coughlin wrote: > (note: this is a reply to comment 71 on Bugzilla for bug 2920 > <http://bugzilla.mozilla.org/show_bug.cgi?id=2920#c71>) > >> Is deleting the attachment data an mbox violation?
Only if you think of the mbox format as a "standard" that can be violated. Given mbox's history, pretty much anything goes. In fact there isn't just one mbox format, but a collection of, sometimes incompatible, formats. > > [...] mbox requires that messages be stored in rfc822 format. The > issue isn't really mbox, it's rfc822. By removing the attachment data > you are making a new message which is missing data from the original > message, and by retaining the message id you have caused your message to > be different from the message that all other recipients and the sender. Technically, by rfc822 standards it may be a new message, but in the eyes of those of us who want this feature, it's the same message with an attachment removed. Many of us make a distinction between the simple body of an message and the MIME (or even UUEncoded) attachments to the message. Even Mozilla's message viewer and composer make this distinction since the "text" of the message shows in the message pane and the attachments are treated as separate but related items. The mbox format uses rfc822 format for messages only because that's the format coming in from the network and is the easiest to store on disk. There is nothing magical or sacred about it. I will agree that deleting an attachment or making other changes and not leaving some trace of the modification is wrong, but only because it would mislead someone into believing that the current version is the original version of the message. > > [...] if i'm the sender and i mean to send you a picture and you > decide to remove my picture from my message, you have changed what I > intended to convey, and therefor by the rfc you are obligated to use a > new unique message id. As the reciever, I'm not obligated to anything other than not resending an altered version of the message as if it were the original. > > [...] If I send you an image/gif and you store an rfc822 image/png > then i expect that it will have a different Message-ID. Why? It's the same content. After all is it the image you sent or it's encoding? From a user's perspective it's the same. If I send a plain text 7-bit ASCII message to someone using a UNICODE based system, then I fully expect my message to be encoded and stored in UNICODE using the original Message-ID even though it's not in ASCII anymore. > > [...] Imagine rfc822 as an envelope (see rfc822 1.1), mbox stores it > and magically allows you to examine its contents without violating the > seal (Message-ID), what you are doing is taking an envelope and breaking > its seal, removing pieces from it and then sealing it up again and > claiming you haven't violated the sanctity of the seal -- which clearly > you have. > > > > [...] once you've broken the seal, it should be trivial for you to > add extra contents, the issue is with the seal. Change the Message-ID > and do whatever damage you need to do. I don't agree with the Message-ID as Seal analogy. It's an identifier not a security and integrity safeguard. Yes, technically the rfc822 message is being altered, but if we remove an attachment and clearly note our change, then I consider this to be fundamentally the same message. In the real world there are cases where a multi-page memo is sent to a group of people and then copies of only certain pages are forwarded to others (for security or just paper-saving reasons). I've never heard anyone claim that the partial memo was a NEW memo, just an incomplete one. Now if we rewrite sections or even add new material (other than "look at what John sent me"), that would constitute a new memo, but just omitting a few pages doesn't. > Is it possible to change the message ID without breaking threading? No, not if you are talking about real threading using the References header. If the message ID changes then you have a new message that is not part of the thread. > If not, then between breaking threading (changing the message ID) and > violating the mbox seal (not changing the message ID), is one of the two > actions acceptable, at least as an option that can be disabled? Dropping an attachment and keeping the Message-ID is the behavior that many (most?) of us expect. We aren't creating a new message, we are just removing part of an existing one. > If neither of the two actions is acceptable, then there's no reasonable > way to delete attachments; however, consider that attachment deletion > and/or externally autosaving attachments is a feature in some > widely-used e-mail clients (mutt, Eudora, and Outlook; and Pegasus > offers some form of this). So what do these e-mail clients do with > their handling of removing attachments that apparently (?) is accepted > as an adequate solution? > > Eudora does not change the message id when they externally autosave the > attachments. Eudora replaces the attachment section with text like the > following: > Attachment Converted: "c:\program files\eudora\attach\filename.ext" Yes, this is exactly the behavior that I would expect. > Is this a case of an mbox violation? If so, is there adequate > documentation indicating that the violation occurred, such that the > violation itself wouldn't pose any legal risk to individuals if they had > to provide such an e-mail in court? (Although the seal has been broken, > the documentation (the "Attachment Converted..." text) openly declares > that the seal was broken, and it openly states what was removed from the > e-mail.) > Whether or not this, technically speaking, is a violation of the rfc822 > format, would it pose any legal risk to individuals who are in > possession of such altered e-mails? Legal risk? You'd have to ask a lawyer. But the Message-ID is NOT a seal or any other type of security or integrity check. The only legal issue I can see would be if you stripped an attachment or modified the contents of the message WITHOUT documenting the change and then forwarded the changed message to others or submitted it as evidence in court while claiming that it was the original, unaltered message. If you state that it was changed, then I don't see how there can be a problem (unless of course you intentionally deleted an attachment that contained critical evidence of some sort, but in that case you probably wouldn't want to tell anyone that you did it and it would be much easier to just delete the entire message). Again, if someone sends me a four page memo and I decide to throw away page 3, where does "legal risk" come into play? > > [...] I suppose a corporation could set a policy prohibitting people > from deleting attachments :-). ok ... so maybe you do need to allow it > to be disabled. w/o that argument I would have said you shouldn't > provide the option to disable it. Why? Do they also prohibit people from deleting messages? While I can't say there isn't some Dilbert-style boss that has made that policy, I don't see a reason for Mozilla to provide technological enforcement. If a company really wants to keep information, it should be trapping data at the servers during delivery not relying on the recipients. Charles Cooley
