[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: Wed, 6 Mar 2019 14:11:10 -0500
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2

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

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

reply via email to

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