Bug 100640 - kmail doesn't append :info-field to maildir filenames
Summary: kmail doesn't append :info-field to maildir filenames
Alias: None
Product: kmail
Classification: Applications
Component: maildir (show other bugs)
Version: 1.7.1
Platform: OpenSUSE Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdepim bugs
Depends on:
Reported: 2005-03-02 12:41 UTC by Cornelius Claussen
Modified: 2015-04-12 10:02 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Cornelius Claussen 2005-03-02 12:41:19 UTC
Version:           1.7.1 (using KDE KDE 3.3.0)
Installed from:    SuSE RPMs
OS:                Linux

KMail 1.7.1 doesn't append the :info field to maildir filenames for me, e.g. the :2,S. It seems to save the "message-marked-as-read-tag" in the index files only, so once they get rebuilt, all mails are marked as unread again.

This is also problematic if I use both pine and KMail on the same folder because all mails that I already read in KMail are marked as unread in pine.

This worked fine until KMail 1.6 or something. If this was changed on purpose it would be cool to have this option configurable.
Comment 1 mark 2005-06-30 18:42:25 UTC
hi, i get then with kde 3.4.1:
for example, kmail adds 2,S yes but doesn't seh the other. I would suggest that kmail leaves the filenames alone when it moves them from new to current or in other places
i file a bug report
Comment 2 Kurt Granroth 2008-04-14 05:18:12 UTC
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".
Comment 3 Laurent Montel 2015-04-12 10:02:30 UTC
Thank you for taking the time to file a bug report.

KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2.

We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.