[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 100640] kmail doesn't append :info-field to maildir filenames
From:       Kurt Granroth <granroth () kde ! org>
Date:       2008-04-14 3:18:12
Message-ID: 20080414031812.21020.qmail () ktown ! kde ! org
[Download RAW message or body]

------- 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 <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:

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


[prev in list] [next in list] [prev in thread] [next in thread]