>> 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.
Well, that pretty much rules out changing the message ID. As for the option of leaving the message ID as is, there's bound to be a feasible way to approach this, a way that would allow the real-world need for this to be met, while also alleviating (to a reasonable extent) concerns about altering a received e-mail - some combination of adding additional info to the e-mail, along with (possibly) allowing people to confirm, undo, or disable the deletion of attachments. Personally, I don't care if the rfc822 format is broken, technically speaking, as long as any changes made don't hinder the user from later migrating away from Mozilla if they choose to (mbox portability). I'd be resistant to making any change to received e-mails that would cause the mailbox to be "best viewed in Mozilla". > 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. Whatever changes that are made to the e-mail need to address this concern in a generic-enough way so that if the user later migrates to a different e-mail client and resends the e-mail from that other e-mail client, it will still be obvious (easily or upon close internal inspection) that the e-mail was an altered version of the original message. I'll include this in the general concerns about ensuring mbox portability. > [...] 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. What would be a minimal amount of info that would adequately indicate (visibly or non-visibly) that the e-mail was altered by the e-mail client? One suggestion was to add a new header type, along the line of "X-Mozilla-Altered: <whatever info here>". Some other suggestions involve adding visible info, such as "Attachment deleted: <name> [<type>] [<size>] [<date & time>]". Does there have to be some visible info added (like the above, which might be just as useful in any other e-mail client)? Does there have to be some non-visible internal info added (like X-Mozilla-Altered)? If Mozilla makes use of this extra internal info though (as a way to keep track of which e-mails have been altered, and in what way), that could be perceived as interfering with mbox portability, since no other e-mail client could be reasonably expected to support this Mozilla-specific tracking of alterations. If on the other hand this info is only added for posterity and not made use of in any way, then there wouldn't be any functionality related to tracking alterations that the user would lose if they migrated to a different e-mail client, and hence no loss of mbox portability. Internal info of this sort could at least indicate (on close inspection) that Mozilla was the e-mail client that altered the e-mail (no idea if there'd ever be a need to know that though). If visible info needs to be added, does it have to be appended to the viewable text of the e-mail (including the end of every alternate version of the viewable text. i.e. html vs plain text)? Or would the attachment have to be replaced with a different attachment that contains text info about the deletion? (I suspect this approach would be very impractical and would interfere too much with mbox portability, but I thought I'd toss the idea out there for good measure.) Any viewable info along the lines of a hyper-link to an externally-saved location of the file (not presently considered for this current bug, but mentioned since it's still under much discussion) could be perceived as interfering with mbox portability, unless it made use of a link mechanism that just about any reasonable e-mail client (that supports mbox) would support (i.e. unless the user could still easily access their attachments if they migrate to a different e-mail client). As food for thought, Eudora saves attachments externally, but Mozilla is able to put the attachments back inside the e-mails when it imports the mailboxes. I don't know if it'd be reasonable though to depend on other e-mail clients to undo any loss of mbox portability caused by Mozilla. Perhaps it wouldn't be as much of an issue if Mozilla itself allowed the user to restore Mozilla's own externally-stored attachments back inside the e-mail (most likely no one would seriously consider adding functionality like that though, including myself). (Realistically, some loss of mbox portability would probably be acceptable. But for now I'm taking the viewpoint of resisting any loss of mbox portability, in the interest of minimizing such loss, and to ensure that there's at least one such view in the discussion. A good mixture of views will still be very much needed in the discussion.) > [...] 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. Some viewable info, as described above, most likely in the body of the e-mail itself, would probably be needed so that the user could easily remember that the e-mail has been altered. This would be a reasonable, but not excessive, effort to help prevent the user from presenting the e-mail to others and, unintentionally, mistakenly claiming that it was unaltered. The rest would be up to the user to not be overly forgetful or dishonest. Someone else mentioned about being able to optionally not store attachments in sent messages in the "sent" folder. Do you see any concerns specific to this type of an action? (in the event that this feature would one day be implemented) >>> [...] 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. I'd only consider adding this option if there was a strong demand for it or if there was a very compelling reason to add it. I expect there might be a reasonable need to allow the users to confirm and/or undo the deletion of attachments. Part of the decision on the undo option may depend on how difficult or awkward it turns out to be to add that functionality. It's also possible that an undo operation would absolutely have to be provided. If there's an undo, then maybe it wouldn't be necessary to have a confirmation window (one less annoying thing to deal with). Certainly at the bare minimum, either a confirmation window or an undo operation would be needed. thanks for all the feedback :-) -- Matt Coughlin [EMAIL PROTECTED] <remove "sp4mless_" from the e-mail address to reply>
