Hi Robert,

I have tested this against our servers (I work for FastMail.FM) with Kmail 1.9 on KDE 3.5.0 (Ubuntu Breezy packages) and here's what happens after I save the message as a draft (looking at the server afterwards)

   * OK IMAP4 ready
   1 LOGIN <my details>
   1 OK User logged in
   2 SELECT INBOX.Drafts
   * FLAGS (\Answered \Flagged \Draft \Deleted \Seen hasnoatt selected)
   * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen hasnoatt selec   ted \*)]
   * 1 EXISTS
   * 0 RECENT
   * OK [UIDVALIDITY 1090367972]
   * OK [UIDNEXT 15]
   2 OK [READ-WRITE] Completed
   3 FETCH 1 FLAGS
   * 1 FETCH (FLAGS (\Seen hasnoatt))
   3 OK Completed (0.000 sec)
   
This is a message added by Kmail, and you can see it's quite clearly missing the \Draft flag.

For what it's worth, our servers are Cyrus IMAP from CVS about a month ago with a small set of patches that wouldn't make any difference here.  We also run a multiplexing proxy - nginx (http://sysoev.ru/nginx/) forwarding the IMAP connection to the appropriate backend server - but by the time you get to appending a message the proxy has finished the authentication phase and is passing everything through.

I may come back and do a tcpdump trace if this isn't enough information to pinpoint the cause.

Bron.

Just to add, the problem is that IMAP doesn't differentiate regular messages/drafts by what folder they are in, but by a "flag" added to the message.

http://www.faqs.org/rfcs/rfc3501.html

---
2.3.2.  Flags Message Attribute

...

 \Draft
    Message has not completed composition (marked as a draft).

---

The easiest way to set the draft flag is during the "append" process.

---
6.3.11. APPEND Command

   Arguments:  mailbox name
               OPTIONAL flag parenthesized list
               OPTIONAL date/time string
               message literal
---

That is you'd do something like:

C: tag APPEND Drafts (\Draft) {310}
S: + Ready for literal data
C: ... literal draft message data ...

So this should be pretty easy to fix I think, you just need to add the (\Draft) flag during the append process.

Rob Mueller

KMail does not use this flag as draft folders do not depend on the storage. You need to specify your draft folder in your identity.

I configured the identity I use for my fastmail.fm account to use the fastmail drafts folder as its own drafts folder. It still doesn't work. I cannot edit drafts, created or first re-opened in kmail, in other email clients.

The whole point of imap is to enable you to work with a single email account from a number of machines and/or clients without getting in a mess. If kmail cannot leave an imap account in a state usable by other clients (by making sure, in this case, that drafts are properly flagged), this is a bug.

I'm using KMail and Thunderbird in parallel. I never had problems with editing 
messages in the drafts folder. I'm using a Kolab server (Cyrus based).

Do I understand correctly that you put the draft messages in any folders and 
want to be able to edit them there?

The FastMail web interface uses the \Draft flag to decide how to present the message.  If it is present, then the message is presented with the 'Compose' template, ready for you to keep editing and eventually send.  If the flag is not present then it's presented for view only.

There is an 'edit as new' menu option which allows you to treat it as if it was a draft, with the crucial difference that the original is _not_ deleted when you then send your messag

Because of that, it's really not the same behaviour.

As Robert said - in the IMAP world, the correct behaviour is to use the flags specified in the RFCs:

RFC 2060:

2.3.2.  Flags Message Attribute
   ...
   A system flag is a flag name that is pre-defined in this
   specification.  All system flags begin with "\".  Certain system
   flags (\Deleted and \Seen) have special semantics described
   elsewhere.  The currently-defined system flags are:
   ...
        \Draft      Message has not completed composition (marked as a
                    draft).


It's quite clear in the standard that if a message has not completed composition then you should be setting this flag on it when you stored it to IMAP.  It's quite reasonable for kmail to not be bothering with flags on backends that don't support them - but when it transfers those same messages to an IMAP server then the \Draft flag should be set so other software can be sure what the intention is.

Regards,

Bron.

I think I have caused some misunderstanding because my first bug report was confused due to my ignorance of a kmail feature, namely the ability to set the drafts folder for each identity. This feature provides an easy workaround for the problem as I initially reported it.

What I discovered in the meantime, with the help of the fastmail.fm people, was that the underlying problem was the inability of kmail to deal with the \Draft flag. The the other more serious effect of this is that drafts saved in kmail cannot easily be reopened for editing in other clients, and it is this that has been bothering me now that I have a workaound for my earlier problem. I am sorry for not making this clear in my last comment. Perhaps it would have been better to have filed a fresh bug report. Maybe I still should.

To answer Andreas's question, I don't personally need to be able to edit mails marked with the \Draft flag from any folder. However in a truly IMAP-compatible client you should be able to do that, even though it is not likely to be an important feature for most users. In that respect the bug I initially reported was a real one and has not been resolved.

Robert, please close this report with a short summary (or refer to e.g. your 
last comment.)
Additionally, add a new wish for KMail in the bugtracker to support the \Draft 
flag in the IMAP implementation. (please check for potential duplicates 
first.) TIA

Marking a folder as containing drafts for an identity causes a nice double-click to behave as expected in current Kmail (4.8.3)