Matt Coughlin wrote:
>>> 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.)
Replacing the actual attachment with a simple text file attachment
describing the deleted contents is a very good idea. Those who view
attachments in-line will automatically see the notification and
those who don't will see it when they try to open the attachment.
An extra header would also be appropriate as an additional way for
people and software to know the message was altered.
> 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.)
Actually, this isn't at all similar to what Eudora does. Eudora
physically separates the attachments from the messages for storage
but still considers them part of the original message and maintains
enough information to be able to put things back together when
presented to the user. We are discussing removing the attachment
entirely. Since the user intends to DELETE the attachment, I don't
see the need to be able to reconstruct the original. If you implement
the "save and delete" option then it would make sense to record the
save location in the delete notification message. That could in
turn be used to reconstruct the original (but only if the saved file
isn't later moved or altered).
>> [...] 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 would use the same strategy. Save a simple text message attachement
that gives the details about the file included in the outbound message.
>
>>>> [...] 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.
A confirmation warning than can be disabled would be better. Once the
attachment has been separated from the message there is no way to
guarantee that you can undo the change. Don't give people the false
hope of an undo. If the option is called "Delete Attachment" and
there is a confirmation warning by default then people will know what
to expect. If you let them disable the confirmation dialog they should
also know what to do.
Given the raw text format of a MIME mail message this feature is fairly
easy in a storage sense. I don't know what impediments the internal
Netscape data structures will present or where to add the UI hooks but
I envision a change something like:
--------------050606040201070208030509
Content-Type: image/png;
name="names.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="names.png"
iVBORw0KGgoAAAANSUhEUgAAANAAAACTCAIAAABwCgDhAAAABGdBTUEAALGOfPtRkwAAACBj
SFJNAAB6JQAAgIMAAPn/AACA6AAAdTAAAOpgAAA6lwAAF2+XqZnUAAANYElEQVR4nGJgGAWj
NJrgRgFdAUCAAQAzf2wO1s6SyQAAAABJRU5ErkJggg==
--------------050606040201070208030509--
becoming:
--------------050606040201070208030509
Content-Type: text/plain;
name="deleted.txt"
Content-Transfer-Encoding: 7bit
The original attachment was removed from this message to conserve space
on Fri, 16 Aug 2002 21:08:45 -0400 by Mozilla 1.1b ....buildID.
The original content MIME type info was:
Content-Type: image/png;
name="names.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="names.png"
--------------050606040201070208030509--
Obviously, the actual message needs a little more work and it would
be nice if it could be edited by the user who could then put in more
specific or relevent information than we can get from the MIME headers.
And my example certainly didn't save space. :-)
Popping up a dialog with the text (editable) that's about to be
inserted and a warning message would make the confirmation useful.
