[Top][All Lists]

[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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]