[This message is in response to earlier comments from timeless.] > Supposing that you had since migrated to another mailer and the > mailer didn't show any sign that mozilla had tampered with the > message, then you might have problems -- this can mostly be fixed > by making sure that sane mailers show evidence that the message > is modified, it might also be an argument against simply using > header flags.
I agree. I wouldn't want the visible evidence of alteration to be entirely dependent on special functionality in Mozilla, such that if a user migrates to a different e-mail client they likely wouldn't be able to tell which e-mails were altered. Usage of header flags alone clearly wouldn't be adequate. Personally, if header flags do get added, I'd want it to be only for posterity, as an internal, non-visible record of what happened, and not something that Mozilla makes use of afterwards (since other e-mail clients likely wouldn't make use of it either). Do you see any benefit from or need for adding header flags? It might be a bit redundant or excessive, if there's always a reasonable amount of visible info added describing the alteration. I might lean towards adding a header flag only if it was both very useful and safe. Along a similar line, I'm hesitant to consider replacing the data of an attachment with text info (as opposed to removing the attachment altogether), because it would either be awkward (if the user can delete or save the text-info replacement) or there'd be special functionality (for distinguishing between original attachments and text-info replacements) that other e-mail clients likely wouldn't support. Plus, for any e-mail clients that don't display text attachments inline (if such clients exist), the user wouldn't have any visible indication of the e-mail having been altered. At the moment, I'd favor removing the attachments altogether, appending text info to the end of each alternate version of the message body, and, if needed, adding a header flag that's added and forgotten. What arguments would you have against this approach or in favor of a somewhat different approach? (aside from the general issue of mbox violations, which might apply equally to any of the discussed approaches) > I suppose a problem could arise if the user forwarded the modified > email to someone). Are there additional concerns for forwarding or replying to an altered e-mail, concerns that don't apply to storing an altered e-mail? > it's OK for us to work gradually to compliance with a *new* > standard. but it's not OK for us to work away from compliance > with an old standard with which we used to be compliant. The approach that I presented above might be a deviation from standards technically speaking, but the deviation might not have any real-world impact (as long as there's an obvious visible indication of the e-mail having been altered). In a practical, debatable sense, the resulting altered e-mail would be in compliance with the mbox format, since it could still be read by any reasonable mbox-supported e-mail client; as such, it wouldn't affect mailbox portability. The deviation would be the fact that it was altered at all, not (at least in this case) the way in which it was altered. The distinction between the two might not be very significant in a theoretical sense, but in real-world situations I'm hoping it'd be significant enough to make the above approach, or a comparable one, acceptable. > I'm opposed to even temporary deviations, but the fact is > that if we chose a deviation, it would be because we found > no way to do it right (which i believe we can do), so it > wouldn't ever be a temporary deviation. What do you see being necessary to allow for deletion of attachments without deviating from compliance with formal standards? I'd be opposed to non-deviation (other than doing nothing), if it would take a year or more before it could be implemented (say perhaps if a formal superset of or an alternative to RFC822 had to be created), and if deviation was possible in a way that didn't have a real-world impact. To put it another way, I might not be willing to commit to a longer time frame than half a year for the patch. Do you see a potential, non-deviation solution that could be resolved within the space of half a year? What steps would need to be taken to accomplish such a solution? I'm starting to wonder how practical it would be to append text info to the end of each alternate version of the message body. I expect it'd be trivial for plain text at least. It might be a little tricky for html - at the very least it would require a more intelligent insertion algorithm. I expect it wouldn't be practical to use code from the html editor to read and parse the structure of the html, insert text in the appropriate place in the data structures, and save the html back to the e-mail; since there'd likely be formatting differences in the resulting html, and possibly even loss of data (if there was some very non-standard content), versus how it was originally. The simplest method that comes to mind for html is to search for the "</body>" tag and insert the text info (formatted as necessary for html) just before the tag. Hopefully that would be reasonably reliable. But I'd wonder about any other present or future alternate versions besides plain text and html, perhaps xml or formats that haven't even been thought up yet. Any other types of alternate versions would presumably need to have the text info appended to them also. What if the formatting of some versions was very non-trivial, perhaps encrypted? I'm wondering if this approach would open up a big, ugly can of worms, one that might not be obvious at first. The only safeguard I can think of for this offhand, is to disable deletion of attachments for e-mail that has alternate versions that the deletion algorithm doesn't support at the time. That could be extended further to disable the deletion functionality for any situation that the overall deletion algorithm can't handle, though it could be confusing to the user as to why the functionality is sometimes unavailable. In some ways it'd be cleaner and simpler to keep the attachment and just replace the attachment data with text info, but, as described [earlier], I have some concerns about that approach too. Maybe just about any approach would be inherently awkward (other than doing nothing of course). One important thing to note with appending text info to the end of each alternate version of the message body, is that if it was implemented and it later became necessary to remove or replace that functionality, it wouldn't pose a problem for any e-mails that had already been altered; they could still be accessed just as well, with the visibile indication of the alteration still being just as obvious. This approach doesn't depend on maintaining any special functionality for the e-mail to be adequately accessible after it's been altered; it's a "set it and forget it" approach, as far as the e-mail client is concerned, and a "set it and permanently remind them" approach, as far as the user goes, regardless of which e-mail client or which version of Mozilla the user uses in the future. Any thoughts about this? -- Matt Coughlin [EMAIL PROTECTED] <remove "sp4mless_" from the e-mail address to reply>
