From kde-bugs-dist Mon Apr 14 03:18:12 2008 From: Kurt Granroth Date: Mon, 14 Apr 2008 03:18:12 +0000 To: kde-bugs-dist Subject: [Bug 100640] kmail doesn't append :info-field to maildir filenames Message-Id: <20080414031812.21020.qmail () ktown ! kde ! org> X-MARC-Message: https://marc.info/?l=kde-bugs-dist&m=120814307513336 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. http://bugs.kde.org/show_bug.cgi?id=100640 granroth kde org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW everconfirmed|0 |1 ------- Additional Comments From granroth kde org 2008-04-14 05:18 ------- This is definitely a bug in KMail, up to at least version 1.9.9. I verified this in both an openSUSE package and compiled myself via the kdepim-3.5.6 tarball. The key appears to be the POP3 download. Here's a quick way to reproduce this: 1. Create a POP3 account (possibly as your only account). Have it download to 'inbox' 2. Download your mail. It shows up as New by default in KMail. Error 1: The messages are in inbox/cur, not inbox/new. New mail needs to always start in 'new'. Now I can possibly see that the default would be to assume that the mail is Unread instead of New... but that's not what the KMail status claims for those messages. It clearly shows them as New Error 2: None of the messages have the :2,(P|R|S|T|D|F) extension. This means that they are all Unread... but see above; KMail shows them a New not Unread. 3. Click on a message to read it. KMail shows that message as being read. Error 3: The message filename has not changed! It must change to :2,S at this point to indicate that it has been seen. Specifically, without this change, the message is considered to be Unread. 4. Copy the message to another maildir folder. Notice now that the correct extension is appended. 5. Click on another message and re-set it to Unread. Copy it to another maildir folder. Notice that it doesn't have any extension. That's actually the correct behavior. Not having the correct extension screws up any app that is trying to share the KMail inbox. I wouldn't necessarily recommend using another MUA since that doesn't play nicely with the index files... but what about mail checkers? I came across this bug via a bug report to KBiff. KBiff does The Right Thing(tm) in determining the message status in Maildir and unfortunately, that means that all downloaded messages stay "new" as far as it's concerned. For the record, here is the original (and only) maildir spec: http://cr.yp.to/proto/maildir.html Here is the relevant part: ----------------------------------------------- When you move a file from new to cur, you have to change its name from uniq to uniq:info. Make sure to preserve the uniq string, so that separate messages can't bump into each other. info is morally equivalent to the Status field used by mbox readers. It'd be useful to have MUAs agree on the meaning of info, so I'm keeping a list of info semantics. Here it is. info starting with "1,": Experimental semantics. info starting with "2,": Each character after the comma is an independent flag. * Flag "P" (passed): the user has resent/forwarded/bounced this message to someone else. * Flag "R" (replied): the user has replied to this message. * Flag "S" (seen): the user has viewed this message, though perhaps he didn't read all the way through it. * Flag "T" (trashed): the user has moved this message to the trash; the trash will be emptied by a later user action. * Flag "D" (draft): the user considers this message a draft; toggled at user discretion. * Flag "F" (flagged): user-defined flag; toggled at user discretion. New flags may be defined later. Flags must be stored in ASCII order: e.g., "2,FRS". -----------------------------------------------