Re: New storage?

Kurt Hackenberg <[email protected]> ha escrit:

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

Thanks for reporting.

> Not writing those messages is arguable,

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.

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

> It never generates X-Envelope-Sender when writing dotmail.

Right. See below.

> Without mbox, that header's value comes from
> Return-Path:, or From:, or the user who's running movemail.

Not quite so. If the message is created by MDA during final delivery,
this header is set directly from the SMTP envelope. Otherwise,
if the source message is in traditional mbox format, it is
obtained from the envelope preserved in the "From " line.
Otherwise, this value is obtained from the first existing header
from the following list: "Return-Path", "X-Envelope-Sender",
"X-Envelope-From", "X-Original-Sender", "From", in that order. If none
of these exist, current user name is used.
		
> Those last two values are technically incorrect, not the SMTP sender.

Right. They are used only as a last resort to provide some sensible default.
A message without sender is invalid anyways.

> What's the purpose of this header

The purpose is to preserve the sender value from the SMTP envelope.

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

Mailutils API supposes that each message has an envelope associated 
with it and provides two functions for obtaining information from this
envelope. The mbox format (be it standard or not) makes provisions for
keeping these values, so these provisions are used. The directory-based
mailbox formats don't - for these formats two surrogate headers are used
(X-Envelope-Sender and X-Envelope-Date).

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.

Regards,
Sergey