From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/67811 Path: news.gmane.org!not-for-mail From: "Steven E. Harris" Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap with openssl stopping up after connecting in Windows Date: Sun, 23 Nov 2008 20:38:05 -0500 Organization: SEH Labs Message-ID: <833ahh3nud.fsf@torus.sehlabs.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1227490796 13453 80.91.229.12 (24 Nov 2008 01:39:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Nov 2008 01:39:56 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M16259@lists.math.uh.edu Mon Nov 24 02:40:58 2008 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1L4QRZ-0003vp-QP for ding-account@gmane.org; Mon, 24 Nov 2008 02:40:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1L4QPM-0004Fi-DT; Sun, 23 Nov 2008 19:38:36 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1L4QPK-0004FU-Kp for ding@lists.math.uh.edu; Sun, 23 Nov 2008 19:38:34 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1L4QP7-0000AR-QW for ding@lists.math.uh.edu; Sun, 23 Nov 2008 19:38:34 -0600 Original-Received: from mail2.panix.com ([166.84.1.73]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1L4QPH-0000ZU-00 for ; Mon, 24 Nov 2008 02:38:32 +0100 Original-Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail2.panix.com (Postfix) with ESMTP id C85383480A for ; Sun, 23 Nov 2008 20:38:19 -0500 (EST) Original-Received: from torus.sehlabs.com (c-24-131-239-140.hsd1.pa.comcast.net [24.131.239.140]) by mailbackend.panix.com (Postfix) with ESMTP id A1A9B11F42 for ; Sun, 23 Nov 2008 20:38:19 -0500 (EST) Original-Received: from seh by torus.sehlabs.com with local (Exim 4.69) (envelope-from ) id KATDVV-000574-JM for ding@gnus.org; Sun, 23 Nov 2008 20:38:19 -0500 Mail-Followup-To: ding@gnus.org User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (cygwin32) X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:67811 Archived-At: Steinar Bang writes: > Steven thinks the solution lies in setting the coding system for the > buffer where nnimaps reads the server responses (perhaps to > undecided-unix...?), but he hasn't yet figured out to do it. Right. I note that the lines being read from the remote IMAP server show up in the IMAP process buffer with ^M glyphs at the end. Looking at these lines in hexl mode, I can see that Emacs has each line ending with CR CR LF That suggests some conflicting assumptions about line endings, maybe with two steps of conversion going on among the programs involved: starttls (Cygwin) -> Emacs (Windows) That is, the Emacs is a Windows build, but it's calling on starttls built for Cygwin. I would expect that this starttls would emit lines per the Unix convention, or maybe it transparently passes through what the server sends. The IMAP specification shows line ending with CRLF pairs. If that's what the server is sending, then I suspect that Emacs reading from starttls is doing some erroneous line conversion and adding in the extra CR before the server's CRLF pair. Here's what Emacs shows in its *imap-log* buffer, sanitized a little: ,----[ *imap-log* buffer ] | * OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=3DREFERENCES MULTIAPPEND= UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA STARTTLS= AUTH=3DPLAIN AUTH=3DLOGIN] Dovecot ready. | 1 CAPABILITY | * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=3DREFERENCES MULTIAPPEND UNS= ELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA STARTTLS AUT= H=3DPLAIN AUTH=3DLOGIN | 1 OK Capability completed. | 1 STARTTLS | * OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=3DREFERENCES MULTIAPPEND= UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA STARTTLS= AUTH=3DPLAIN AUTH=3DLOGIN] Dovecot ready. | 1 OK Begin TLS negotiation now. | 2 LOGOUT | * BYE Logging out | 2 OK Logout completed. | 2 CAPABILITY | 3 LOGIN "seh" "mypassword" `---- And from the *Messages* buffer: ,----[ *Messages* buffer ] | Checking new news... | Opening nnimap server on panix... | imap: Connecting to mail.panix.com... | Waiting for response from mail.panix.com...done | imap: Reconnecting with stream `starttls'... | Loading starttls...done | imap: Connecting with STARTTLS...done | Waiting for response from mail.panix.com...done | imap: Reconnecting with stream `starttls'...done | Parsing authinfo file `~/.authinfo'. | imap: Authenticating to `mail.panix.com' using `login'... | imap: Plaintext authentication... | Unable to open server due to: Process imap<1> not running | Unable to open nnimap:panix, go offline? (y or n)=20 | Opening nnimap server on panix...failed `---- Per the "2 LOGOUT" command above, it looks like the client closes the connection, and /then/ issues the LOGIN command. I'm not sure why. Or maybe that LOGOUT is required once the TLS negotiation is complete, after which the LOGIN command is appropriate. Here's a similar *imap-log* buffer from a successful login with a Cygwin XEmacs build (actual ^M characters are replaced here with the character sequence "^M"): ,----[ *imap-log* buffer (Cygwin) ] | * OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=3DREFERENCES MULTIAPPEND= UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA STARTTLS= AUTH=3DPLAIN AUTH=3DLOGIN] Dovecot ready. | 1 CAPABILITY^M | * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=3DREFERENCES MULTIAPPEND UNS= ELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA STARTTLS AUT= H=3DPLAIN AUTH=3DLOGIN^M | 1 OK Capability completed.^M | 1 STARTTLS^M | * OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=3DREFERENCES MULTIAPPEND= UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA STARTTLS= AUTH=3DPLAIN AUTH=3DLOGIN] Dovecot ready.^M | 1 OK Begin TLS negotiation now.^M | 2 NOOP^M | 2 OK NOOP completed.^M | 3 LOGOUT^M | * BYE Logging out^M | 3 OK Logout completed.^M | 2 NOOP^M | 2 OK NOOP completed.^M | 3 CAPABILITY^M | * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=3DREFERENCES MULTIAPPEND UNS= ELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA AUTH=3DPLAIN= AUTH=3DLOGIN^M | 3 OK Capability completed.^M | 4 LOGIN "seh" "mypassword"^M | 4 OK Logged in.^M | 5 NOOP^M | 5 OK NOOP completed.^M | 6 STATUS "INBOX" (UIDVALIDITY UIDNEXT UNSEEN)^M | * STATUS "INBOX" (UIDNEXT 18324 UIDVALIDITY 1067275254 UNSEEN 0)^M | 6 OK Status completed.^M `---- Note here the NOOP commands and the LOGOUT followed by another CAPABILITY, finally followed by the LOGIN command. There's more cause-and-effect chatter evident here, whereas the first transcript above looks more like two parties talking but not hearing one another. I hope someone more familiar with nnimap, process control, and coding systems can chime with suggestions for further investigation. --=20 Steven E. Harris