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:
- IMAP COPY from serverA (dovecot) to serverA (dovecot)
- IMAP COPY from serverA (dovecot) to serverB (dovecot)
- IMAP COPY from serverA (dovecot) to serverC (not-dovecot)
- 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