[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VM] VM and davmail issues again.

From: John Stoffel
Subject: Re: [VM] VM and davmail issues again.
Date: Thu, 15 Feb 2018 10:49:57 -0500

>>>>> "CC" == Gian Uberto Lauri <address@hidden> writes:

>>>>> "JS" == John Stoffel <address@hidden> writes:
CC> Hello John!

JS> This all looks good, and just like what I get from my dovecot
JS> server.  When you look in the emacs buffer for the imap log, do
JS> you see ^M on the end of the lines, like I do?

CC> Yes they are there. As if Emacs was not expecting a network line
CC> terminator.

Yeah, it's not clear to me what encoding VM is using internally, but I
suspect Uday has it down pretty well honestly.  

JS> Maybe you should back out that patch you applied and see if that
JS> makes things work again.

CC> It was even worse. No reply from server.

Hmm.. that's not a good sign.  I have *zero* ability to hack elish in
any good way, but looking at the code in vm-imap.el where the error is
thrown from might give us some ideas.

     process (format "FETCH %s:%s (UID RFC822.SIZE FLAGS)" first last))
    (while need-ok
      (setq response (vm-imap-read-response-and-verify process "FLAGS FETCH"))
       ((vm-imap-response-matches response '* 'atom 'FETCH 'list)
        (setq p (cdr (nth 3 response)))
        (setq tok (nth 1 response))
        (goto-char (nth 1 tok))
        (setq msg-num (read imap-buffer))
        (while p
           ((vm-imap-response-matches p 'UID 'atom)
            (setq tok (nth 1 p))
            (setq uid (buffer-substring (nth 1 tok) (nth 2 tok)))
            (setq p (nthcdr 2 p)))
           ((vm-imap-response-matches p 'RFC822\.SIZE 'atom)
            (setq tok (nth 1 p))
            (setq size (buffer-substring (nth 1 tok) (nth 2 tok)))
            (setq p (nthcdr 2 p)))
           ((vm-imap-response-matches p  'FLAGS 'list)
            (setq pl (cdr (nth 1 p))
                  flags nil)
            (while pl
              (setq tok (car pl))
              (if (not (vm-imap-response-matches (list tok) 'atom))
                   "expected atom in FLAGS list in FETCH response"))
              (setq flag (downcase
                          (buffer-substring (nth 1 tok) (nth 2 tok)))
                    flags (cons flag flags)
                    pl (cdr pl)))
            (setq p (nthcdr 2 p)))
             "expected UID, RFC822.SIZE and (FLAGS list) in FETCH response"))
        (setq list 
              (cons (cons msg-num (cons uid (cons size flags)))
       ((vm-imap-response-matches response 'VM 'OK)
        (setq need-ok nil))))

So it's parsing the returned strings, and it's dying because the (t (
vm-imap-protocol-error ... )) stuff, which hurts my brain.  It's
probably not matching something properly.  Maybe the trick would be to
pull out the FLAGS part from the request sent by vm, and see if the
result returned parses properly or not.  Do the same with the
RFC822.SIZE part as well, leaving in flags.  Maybe it's busted or
slightly formatted differently by DAVmail?

Hmm.. on my end I see something like this:

    a3 FETCH 510:515 (UID RFC822.SIZE FLAGS)
    * 510 FETCH (UID 35104 RFC822.SIZE 12579 FLAGS (\Seen))
    * 511 FETCH (UID 35113 RFC822.SIZE 5476 FLAGS (\Seen))
    * 512 FETCH (UID 35114 RFC822.SIZE 5481 FLAGS (\Seen))
    * 513 FETCH (UID 35115 RFC822.SIZE 8255 FLAGS (\Seen))
    * 514 FETCH (UID 35117 RFC822.SIZE 2976 FLAGS (\Recent))
    * 515 FETCH (UID 35118 RFC822.SIZE 42224 FLAGS (\Recent))
    a3 OK Fetch completed (0.001 + 0.000 secs).

So it must to correctly using the (...) after the FETCH response.
Looking more into DavMAIL, it's a Java based application.  Another
language I don't speak well at all.  Sigh..  *grin*

And the sourceforge site is down too, so I can't even look at the
DAVmail source.  Are you running the latest version of DAVmail as

Sorry I'm kinda useless here...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]