Comment below:
On Mon, Apr 26, 2004 at 11:43:59AM +0200, Miquel van Smoorenburg wrote:
On 2004.04.26 09:03, Tom Alsberg wrote:
<snip /> However, the mbox format does store those lines, and they even still have some meaning.
Why not let your MDA or local delivery agent add a proper Return-Path: header. It contains the same information as the From_ line, but it works with all mailbox types, it's easier to parse and you can get at it using IMAP.
Well, my MTA, as most others, does add a Return-Path: header. Usually it contains the same information as the From_ line, but not always, IIRC (the Return-Path: header, IIRC, may be altered/added to by an SMTP relay in the way, while the envelope From_ line is guaranteed to remain as it was). Never mind that, however - naturally I can have the same information stored also in the headers (X-Envelope-From: or something like that).
However, I would still like the From_ line to remain intact - I see no reason to rewrite it while copying the message, instead of keeping the original one. Actually, some user agents and other software even do read it and regard it (for filtering, marking messages, sorting and merging mailboxes, etc.), so it disturbs a bit when that's changed.
To note it - IMAP is not the only way -- at least in my intended installation -- that users access their mailboxes in. Wherever possible, the IMAP and the local mailbox access should be synchronized, and using one should not disturb the usage of the other. It is a bad assumption in my opinion, therefore, that the From_ line is completely irrelevant (and needs not be preserved) only because it is not visible in IMAP.
Maybe it isn't important to many other users, but if it is irrelevant to IMAP, any reason not to preserve it instead of rewriting it? I haven't tried any further yet, but would appreciate some tip on how to cleanly patch dovecot to do so (searching backwards for the From_ line is rather ugly...), or just have it "fixed" in CVS/the next version...
Mike.
Thanks again, -- Tom
-- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further.