Maildir

From ThorxWiki
(Difference between revisions)
Jump to: navigation, search
(procmail handling link)
(do we care about hostname in maildir filenames?)
Line 32: Line 32:
   
 
== Nemo sez... ==
  
== Nemo sez... ==
−
Arbitrary unfriendless is anathema to me.
+
Arbitrary unfriendless is anathema to me. Especially, speaking here as a human, arbitrary unfriendliness to a human!
   
   
 
== So... ==
  
== So... ==
−
How to fix the cons of maildir?
 +
How to fix maildir's woes?
 
=== Information in Filename ===
  
=== Information in Filename ===
−
The standard says that the name shoulnd't be of care to the MUA, so let's make it at least human useful. What is wrong with:
 +
The standard says that the name shoulnd't be of care to the MUA, so let's see if we can make it human useful afterall. How about:
 
* YYYYMMDDHHMMSS.SubjectLineUpTo40CharsLong.md5:2,
  
* YYYYMMDDHHMMSS.SubjectLineUpTo40CharsLong.md5:2,
 
This provides human readable date, and messages are then likely sortable by date from commandline easily. Date plus "." = 15 chars. Then let's have up to 40characters of subject line - this should allow for reasonable hinting as to message contents from the filename. That's 55 characters used so far. The first 4 characters of an md5sum of the message itself should be a final uniqueness check (if it is identical to all the others then we have a problem! That brings us to 60 characters (the seperating period making the shortfall for those keeping count). And at the end let's say that status chars (including ":2,") could grow to 10 chars. That's 70 chars which means a basic 'ls' stays comfortably inside a standard 80column terminal.
 
This provides human readable date, and messages are then likely sortable by date from commandline easily. Date plus "." = 15 chars. Then let's have up to 40characters of subject line - this should allow for reasonable hinting as to message contents from the filename. That's 55 characters used so far. The first 4 characters of an md5sum of the message itself should be a final uniqueness check (if it is identical to all the others then we have a problem! That brings us to 60 characters (the seperating period making the shortfall for those keeping count). And at the end let's say that status chars (including ":2,") could grow to 10 chars. That's 70 chars which means a basic 'ls' stays comfortably inside a standard 80column terminal.
 
** What is the date based on? Envelope date or message date? In mbox, envelope date is encoded in the From_ line. In maildir it is the datestamp of the file? Or is it forgotten?
  
** What is the date based on? Envelope date or message date? In mbox, envelope date is encoded in the From_ line. In maildir it is the datestamp of the file? Or is it forgotten?
  +
** We lose the hostname of the machine that delivered the message (maildir used to put this in). Is this exactly relevant anyway since it can end up almost anything (eg: converting a mbox to maildir with mutt will set the host to whatever the machine name that mutt is running on! BFW!)
   
 
== Links ==
  
== Links ==

Revision as of 11:39, 31 March 2009

Contents

Maildir is a popular alternative to the almost ubiquitous mbox format (formats - see below). However, I have some issues with it...

First though, let's look at mbox

mbox

Where each folder is a file, and each message is a segment within that file

Pro

  • Easy to grep from the commandline (grep STRING file)
  • Easy to search within folder using 'less' or similar
  • Faster to open as only one fopen required

Con

  • Requires $From escaping. Multiple incompatible methods!!!
  • Requires file locking for multiple access handling (esp nfs?)
  • Slower to write changes as whole mbox needs re-writing


maildir

Where each folder is a directory, and each message is a file in that directory structure

Pro

  • Multiple simultaneous access
  • No need for escaping anything
  • Changing status on an individual message is VERY fast (file rename only)
    • Can also be done from the commandline easily
  • Each file is a self-contained valid RFC822 message datastream

Con

  • May not be able to search from commandline so easily with multiple ('rgrep STRING maildir/' may return MULTIPLE files, which is then harder to search through with 'less', etc)
  • Filename uniqueness is arbitarily unfriendly to human readability


Nemo sez...

Arbitrary unfriendless is anathema to me. Especially, speaking here as a human, arbitrary unfriendliness to a human!


So...

How to fix maildir's woes?

Information in Filename

The standard says that the name shoulnd't be of care to the MUA, so let's see if we can make it human useful afterall. How about:

  • YYYYMMDDHHMMSS.SubjectLineUpTo40CharsLong.md5:2,

This provides human readable date, and messages are then likely sortable by date from commandline easily. Date plus "." = 15 chars. Then let's have up to 40characters of subject line - this should allow for reasonable hinting as to message contents from the filename. That's 55 characters used so far. The first 4 characters of an md5sum of the message itself should be a final uniqueness check (if it is identical to all the others then we have a problem! That brings us to 60 characters (the seperating period making the shortfall for those keeping count). And at the end let's say that status chars (including ":2,") could grow to 10 chars. That's 70 chars which means a basic 'ls' stays comfortably inside a standard 80column terminal.

    • What is the date based on? Envelope date or message date? In mbox, envelope date is encoded in the From_ line. In maildir it is the datestamp of the file? Or is it forgotten?
    • We lose the hostname of the machine that delivered the message (maildir used to put this in). Is this exactly relevant anyway since it can end up almost anything (eg: converting a mbox to maildir with mutt will set the host to whatever the machine name that mutt is running on! BFW!)

Links

Retrieved from "http://wiki.thorx.net/mediawiki/index.php?title=Maildir&oldid=4537"
Personal tools
Namespaces

Variants
Actions
Navigation
meta navigation
More thorx
Tools