Re: New storage?

I've tried out the new dotmail stuff, and it seems fine.

Along the way, I noticed a few minor side things.

I looked at the source code. On read, it apparently un-dotstuffs only 
the message body. Since no valid header line starts with '.', that's a 
pretty safe optimization -- but I'd like it to be noted in comments. I 
wouldn't want somebody to read code and get the wrong idea about the 
algorithm.

I tested by using mail to read dotmail files, and movemail to read and 
write them and convert to and from other formats. I barely tested random 
access, read-only; I did not test concurrent access; I did not test the 
API by writing code to use it.

Now a couple glitches.

When movemail -p reads MH and writes dotmail, when an input message is 
marked as deleted (with ',' in the filename), it doesn't write the 
message. When reading maildir and a message is marked deleted ('T' in 
filename), it writes the message. Not writing those messages is 
arguable, and the inconsistency is peculiar.

Movemail always generates X-Envelope-Sender: when writing maildir and 
MH, even when not reading mbox. It never generates X-Envelope-Sender: 
when writing dotmail. Without mbox, that header's value comes from 
Return-Path:, or From:, or the user who's running movemail. Those last 
two values are technically incorrect, not the SMTP sender.

What's the purpose of this header -- to preserve that field from the 
mbox From_ line?  Since it's non-standard and holds the same information 
as Return-Path:, I would think -- without knowing anything about how 
mailutils or anybody else uses it -- that it should be generated only 
when converting a message that doesn't have Return-Path:, from mbox to 
something else.

All these side things are minor, and some are not dotmail at all. The 
dotmail mechanism works fine -- multiple messages in a single file, with 
the end of each message marked -- and that's my main concern.