[Bug 100640] kmail doesn't append :info-field to maildir filenames

Kurt Granroth granroth at kde.org
Mon Apr 14 04:18:12 BST 2008

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
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 <message>: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:


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

More information about the Kdepim-bugs mailing list