279060 - mail format and viruses, backups, performance, mail sync, mail merge

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[peter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MultiZilla/1.6.4.0b
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MultiZilla/1.6.4.0b

This is about lossages due to the way mozilla stores mail.  Related bugs are
103993, 116443, 247223, and no doubt others I haven't bothered to look for.

All these bugs are related to needs to change the mail format.  My goal in
adding yet another bug is to implore y'all to try to consider all the issues
together in devising another format.  That's why I'm not just adding this to
just ONE of these other bugs.

Some points:

Backups (meaning e.g., tape backups of all files, not just in mozilla)
------- 

Using the current format (which I guess is unix inbox format), whenever a
message is added to any mail file (i.e. "folder"), such as inbox or sent or
whatever, that file then needs to be backed up at some point.  My mail files
tend to be huge, what with all the attachments.  This means that every time I
get an new email message, the next incremental backup has to once again back
up a 1GB file, even though only 1KB changed in that file.  This is bad.
Using finer granularity of files internally would solve this.

Human readability
-----------------

Most likely, some solution, following others in the past, will be something
like one message per file, or maybe one thread per file.  (Though I can
imagine other choices, such as using diff-based version control.)  PLEASE
make sure these files have the following features:

1. A humble human such as myself can read and edit them with a plain file
   editor without breaking anything.  (This seems to be a design feature of
   the current system, although the system for checking whether an index file
   is still valid for the mail file it is supposed to be indexing seems to
   leave something to be desired.)  This is very useful when something else
   has been entirely too clever.

2. A humble human such as myself can look at the directory structure without
   any special tools and have a prayer of guessing which file contains what
   messages.  E.g., the filename might include the timestamp of the message.

3. They are not locked against being copied, viewed, or backed up by normal
   user mode programs.  In particular, this implies:

4. Resist the temptation to embed the mail into some database file.  While
   this allows clever searching, it makes the file opaque to normal humans,
   and usually makes copying or backing up the file a nightmare.

Merging and syncing
-------------------

I would really like to be able to merge (mail-diff?) different mail files.
In the worst case, this can be done with diff (or its ilk) using the current
inbox format.  Please keep this in mind when designing a new format, so that
it is easy to make tools to do mergin.  E.g., if each message is a file, then
a diff on the directory should give most of what you need to merge.  (This
relates to my point (2) above.)

Reproducible: Always

Steps to Reproduce:

Comment 1

[zug_treno]

Related to bug 58308?

Comment 2

[peter]

Yes, this is related to  bug 58308.

bug 58308 is about a couple of possible formats for mail boxes.  My purpose in
the present bug was to ask for consideration of more ramifications, instead of
just tunnel vision about one isolated problem.

As one tiny example of what I mean, with the current unix format, I can read my
inbox with emacs, and all its tools work.

Also, interoperability between different formats goes as the square of the
number of formats, so you have to consider the amount of bloat.

There are a lot of tradeoffs;  I just want to be sure you guys think about as
many of these as possible, rather than solve one problem only to create 7 others.

--peter

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.