Re: New storage?

On 3/6/19 4:42 AM, Sergey Poznyakoff wrote:

> I wonder if there is any use in keeping deleted messages in a monolithic
> mailbox. Doing so in MH and Maildir is OK, because it imposes little if
> any additional strain on the mailbox reader (moreover, MH does not
> provide any mechanism for purging the mailbox at all). For a monolithic
> mailbox this would mean bloating the disk file with unused data.
> 
> However, this statement shouldn't be taken as an established mailutils
> policy. If you see any reason for keeping deleted messages, I'm open to
> discussing it.

I guess the reason to keep them would be to keep things working as the 
user expects, in a mail reader that works that way. Otherwise, the user 
might see messages as mysteriously vanishing, when he hadn't really 
decided to delete them. At a lower level, I think that's the intended 
meaning of the deleted attribute -- that the message is marked for 
deletion, but won't be deleted until somebody or something calls for an 
expunge.

MH has no purge? That's surprising. Are MH users expected to do that 
outside of MH, with something like rm ,* ?

>> Movemail always generates X-Envelope-Sender: when writing maildir and
>> MH, even when not reading mbox.
> 
> Right. But not only movemail. In fact, it is done by the corresponding
> mailbox library (the "abstract mailbox directory" layer) when storing
> the message.

I guessed that, but didn't want to say more than I knew.

> Mailutils API supposes that each message has an envelope associated
> with it and provides two functions for obtaining information from this
> envelope.

Makes sense, for a package that includes SMTP.

> You are right that the Return-Path header already contains this
> information and that generating X-Envelope-Sender in its presence is
> superfluous. This should be revised. That's why I don't generate it
> for dotmail format.

I see. Maybe you could also do that with X-Envelope-Date and the most 
recent Received, which contains a time. I think it's the right time...