Re: Imap Problem

[Jake Colman <colman@ppllc.com>]

Mats,

Bingo!

Here's what I get what I connect to 'truman', my MS Exchange IMAP Server:

Opening nnimap server on truman...
imap: Connecting to truman...
Looking for IMAP greeting in  *nnimap* truman
Looking for IMAP greeting in *Group*
Looking for IMAP greeting in *Group*
imap: Connecting to truman...failed

The 'failed' message is after I pressed C-g.

So now that we have a complete diagnosis of the problem, how can it get
fixed?

Is Simon reading this?

...Jake



>>>>> "ML" == Mats Lidell <Mats.Lidell@contactor.se> writes:

>>>>> Jake wrote:
    Jake> There are enough of use with this problem that you'd think someone,
    Jake> somewhere would try to run it down.  I'd try to look into but I
    Jake> have no idea where to begin.

    ML> Start by applying this patch to imap.el, or just add the message
    ML> line, and verify that you get the same behavior as I do. Then we know
    ML> it is the same problem.

    ML> *** imap.el Fri Jun 1 17:02:46 2001
    ML> --- imap.el.~1~ Thu Jan 4 06:16:06 2001
    ML> ***************
    ML> *** 1830,1836 ****
  
    ML>   (defun imap-parse-greeting ()
    ML>     "Parse a IMAP greeting."
    ML> - (message (concat "Looking for IMAP greeting in " (buffer-name)))
    ML>     ;;; XXX
    ML>     (cond ((looking-at "\\* OK ")
    ML>   	 (setq imap-state 'nonauth))
    ML>   	((looking-at "\\* PREAUTH ")
    ML> --- 1830,1835 ----

    Jake> In case this helps, since upgrading to 21.4.3 and the latest
    Jake> packages, I can make this happen consistently if I just do the
    Jake> following:

    ML> I have had this a long time with different version of XEmacs and it
    ML> is present both on NT and on Linux.

    Jake> 1) Start XEmacs.
    Jake> 2) C-x f .emacs
    Jake> 2) C-x 5 b
    Jake> 3) M-x gnus in the new frame

    ML> With the patch applied my guess is that you will in the Message
    ML> buffer se one line that reads:
    ML>   "Looking for IMAP greeting in *nnimap* <your-server>"
    ML> followed by a number of lines: (Depending on how fast to hit C-G to
    ML> break the loop)
    ML>   "Looking for IMAP greeting in *Group* <your-server>"

    ML> What is going on you might ask? (And if I could tell you the whole
    ML> store we would probably have solved the question.)

    ML> The short answer is that imap is waiting for the authorisation reply
    ML> from the server and when it looks in the process buffer the first
    ML> time the reply hasn't arrived yet. So it loops and comes back again
    ML> only now to be looking-at in the wrong buffer. Since the *Group*
    ML> buffer isn't known to contain an IMAP authorisation message the test
    ML> will fail etc.

    ML> This is a excerpt from the Message log when I just successfully
    ML> managed to connect (by using the M-x gnus-in-a-single-frame-method as
    ML> outlined earlier.)
    ML> ----------------------------------------------------------------------
    ML> imap: Connecting to localhost...  Looking for IMAP greeting in
    ML> *nnimap* contactor Looking for IMAP greeting in *nnimap* contactor
    ML> Waiting for response from localhost...done imap: Connecting to
    ML> localhost...done
    ML> ----------------------------------------------------------------------

    ML> Notice that this time we had to look twice in the process buffer to
    ML> find the reply and that both times we looked in the process
    ML> buffer. That's nice and how it should be.

    ML> This also could explain why it works sometimes. With a fast
    ML> IMAP-server or a slow XEmacs the reply could arrive so that it is in
    ML> the process buffer when we look into it the first time.

    ML> OK. To be complete. Here is how it looks when it failes.
    ML> ----------------------------------------------------------------------
    ML> imap: Connecting to localhost...  Looking for IMAP greeting in
    ML> *nnimap* contactor Looking for IMAP greeting in *Group* Looking for
    ML> IMAP greeting in *Group* imap: Connecting to localhost...failed
    ML> ----------------------------------------------------------------------

    ML> This is what I describe above but it is probably easier to understand
    ML> when you see it.

    ML> Yours
    ML> --
    ML> %% Mats
    ML> PS. I really don't know anything about the internal behavior of
    ML> XEmacs process buffers so there might be other reasons for what we
    ML> are seeing. The consequences remains the same though. DS.

-- 
Jake Colman                     

Principia Partners LLC                  Phone: (201) 946-0300
Harborside Financial Center               Fax: (201) 946-0320
902 Plaza II                           Beeper: (800) 928-4640
Jersey City, NJ 07311                  E-mail: colman@ppllc.com
                                       E-mail: jcolman@jnc.com
                                          web: http://www.ppllc.com