At Thu, 12 Jul 2012 23:48:44 +0200,
Sebastian Hofer wrote:
>
> On Fri, Jul 6, 2012 at 6:28 AM, David Maus <dmaus@ictsoc.de> wrote:
>
> > At Thu, 21 Jun 2012 19:55:36 +0100,
> > Simon Brown wrote:
> > >
> > > At Thu, 21 Jun 2012 16:49:10 +0100,
> > > Simon Brown wrote:
> > > > Something has changed with my WL installation and now after sending an
> > > > email, the autosaved drafts are no longer cleaned up. Has something
> > > > changed in WL, or have I broken my setup? I use WL from el-get.
> > >
> > > Just noticed that I'm getting errors from gnutls about short
> > > packets. The corporate mail server has changed to exchange 2010 and is
> > > forcing TLS. This may well be the issue. Perhaps, although the message
> > > is successfully sent, due to the TLS error clean up is not carried out
> > > due to the perceived failure.
> >
> > Is it just the last draft of a message that is not deleted or are
> > there other older autosaves?
>
>
> I also experience the same problem. For me it seems that the older
> autosaves don't get cleaned up but the last version does. So I end up with
> a bunch of empty messages in my Drafts folder. Very annoying. Any ideas?
Not removing old autosaves can be a side-effect of WLs draft-save
mechanism possibly in combination with the outstanding bug:
,----[ BUGS ]
| * IMAP STATUS command MUST NOT be used as a "check for new messages in the
| selected mailbox" operation (RFC3501)
`----
What happens is roughly the following:
1. WL SELECTs (`opens') the draft folder mailbox.
2. To autosave a draft WL calls STATUS on the folder mailbox to obtain
its UIDNEXT value.
3. WL treats the obtained UIDNEXT as the UID of the draft message.
4. WL APPENDs the draft message to the mailbox.
5. The next autosave DELETEs the previous autosave by referencing its
UID obtained in step 2.
The problematic parts are in step 2 and 3:
- calling STATUS on a SELECTed mailbox is verboten by the specs (MUST
NOT); the mail server implementations I'm used to use (Dovecot,
Courier, Google, Kerio) do not report an error on such an action
but e.g. Courier does not report an updated mailbox status for the
mailbox in question.
In the case of Courier this means that the UIDNEXT value is not
updated and WL loses track of all except the first draft autosave.
- strictly speeking UIDNEXT does not return the UID of the next
message in the mailbox but an UID that is lesser or equal to the
UID of the next new message (Cf. 1st note in RFC3501, 2.3.1.1.).
Obviously the right behaviour would be to first APPEND the message and
then obtain its UID by either utilizing the UIDPLUS extension
(RFC4315) if available or search for the appended message
(Cf. RFC4549). There still is the chance that old drafts pile up if
the SEARCH for the appended message is not successful or conclusive
but I would argue that this is acceptable because we did all we could
do to find the autosaved message.
In order to see what is going wrong in your particular case you could
turn on IMAP4 debugging by setting the variable `elmo-imap4-debug' to
a non-nil value and look at the APPEND/DELETE sequences in the IMAP4
debug buffer.
Good news is that there is the branch `heimkehr' in
<git://github.com/dmj/wanderlust.git> where I combined two major
improvements to WL that sadly received no feedback yet:
1. egh's improved IMAP search
(elmo-imap4-new-search in official repo)
2. my fix for the outstanding bug w/ STATUS on SELECTed mailbox
(elmo-imap4-compliance in official repo)
The 2nd fix for STATUS on SELECTed also contains an implementation of
the proper draft save mechanism outlined above.
Please note that I recommend to use `heimkehr' rather than
`elmo-imap4-compliance' in official repo because the notion of an
`official repo' got somewhat fuzzy after the CVS was shut down and I
made some bugfixes to the compliance part directly in `heimkehr'.
In order to use or try out `heimkehr' you would need to:
- git clone git://github.com/dmj/wanderlust.git /path/to/some/directory
- cd /path/to/some/directory
- git checkout heimkehr
and prepend the subdirectories `wl', `elmo', and `utils' to your load path.
There is no need to byte-compile WL on the `heimkehr' branch.
I am running this branch for ~4 months w/o any problems against
Courier, Kerio, GoogleMail and Dovecot.
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.deAttachment:
pgpVGa6ZUF5p5.pgp
Description: OpenPGP Digital Signature