[Dovecot] Envelope From changed - why?

[Amelia A Lewis]

On Tue, Apr 27, 2004 at 09:40:02PM +0300, Tom Alsberg wrote:
>Hi there.
>Please read my comments below:
>
>On Tue, Apr 27, 2004 at 10:49:51AM -0400, Amelia A Lewis wrote:
>> On Tue, Apr 27, 2004 at 03:53:39PM +0300, Tom Alsberg wrote:
>> >That's possible.  But I'd prefer it if when COPYing a message, it 
>> >would just copy the "From " line verbatim as well, and not get into 
>> >this trouble, even though I see now that the content should normally
>> >be the same (leave those semantics to the MTA...).
>> 
>> Okay, so this is the IMAP COPY command, right?
>
>Yes...
>
>> Why are you putting mbox "From " lines into my maildir?
>
>Uhmm, I am not.  It should of course only copy it together with the 
>"From " line if copied to an mbox...

There's the problem.  IMAP can work between multiple servers (I do it every
day, partly to keep my Important Email backed up).  The protocol, which
defines the COPY command, doesn't have a place for a "From " line, since it
isn't a header.  So, if dovecot implements it, then there are four
possibilities:

1) IMAP COPY from serverA (dovecot) to serverA (dovecot)
2) IMAP COPY from serverA (dovecot) to serverB (dovecot)
3) IMAP COPY from serverA (dovecot) to serverC (not-dovecot)
4) IMAP COPY from serverC (not-dovecot) to ServerA (or B) (dovecot)

In case 1, if the source mailbox is mbox and the target mailbox is mbox,
then the additional information can be copied.  I gather that this is the
scenario that you have in mind.

If the source is mbox and the target is maildir, it would be preferable to
drop the information or transform it to ReturnPath, although that isn't an
IMAP server's job.

If the source is maildir and the target is mbox, what should happen?

In case 2, it doesn't matter that both servers are dovecot, unless you're
suggesting a custom extension of the protocol.  Assuming that Timo refuses
to muck up the protocol with custom extensions, then this is equivalent to
case 3.  The originating server has no way of knowing what format the target
server is storing in, and the "From " line is not a header, so has no
"normal" means of being passed.  If Timo implements a custom extension to
the protocol (rather than custom metadata for a server-internal copy), this
is equivalent to case 1.

Case 4 is like case 3.  In neither case is it possible to communicate from a
dovecot server to a non-dovecot server (or vice versa) information which
does not fit into the IMAP protocol, such as a non-header line prepended to
a message, or the format of the target mailbox.

So, fine, implement for case 1, and leave the others alone, right?  Well. 
A user could then reasonably ask "Why does my data change when I copy it
from my ISP's machine to Uni's Cyrus server?  It doesn't change when I copy
it from folder to folder on my ISP!"  I can't say that I much like the idea
of a network protocol command that has enhancements to behave like a local
file copy.

If all you're concerned about in the copying is a single local machine,
preserving the semantics of a particular storage format, then why not do
file copies?  Note, this is *not* a rhetorical question; if a network server
is to be asked to behave in a different way depending upon context (that
users may not even be aware of) that arises from the chosen storage context,
what happens next?  Is this not possibly a slippery slope?

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
It's is not, it isn't ain't, and it's it's, not its, if you mean it is.
If you don't, it's its.  Then too, it's hers.  It isn't her's. It isn't
our's either.  It's ours, and likewise yours and theirs.
                --OUP Edpress News