[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-mailutils] New storage?
From: |
Kurt Hackenberg |
Subject: |
Re: [bug-mailutils] New storage? |
Date: |
Tue, 5 Mar 2019 20:36:38 -0500 |
User-agent: |
Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 |
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.