From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/72386 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?Bj=C3=B8rn_Mork?= Newsgroups: gmane.emacs.gnus.general Subject: Re: A few basic nnimap problems Date: Fri, 01 Oct 2010 13:17:24 +0200 Organization: m Message-ID: <87wrq2yxff.fsf@nemi.mork.no> References: <87aamz17w0.fsf@nemi.mork.no> <8762xn151w.fsf@nemi.mork.no> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1285931932 30430 80.91.229.12 (1 Oct 2010 11:18:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Oct 2010 11:18:52 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M20759@lists.math.uh.edu Fri Oct 01 13:18:51 2010 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.69) (envelope-from ) id 1P1ddY-0000U2-SF for ding-account@gmane.org; Fri, 01 Oct 2010 13:18:49 +0200 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 1P1dcl-0003cQ-JA; Fri, 01 Oct 2010 06:17:59 -0500 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 1P1dci-0003c6-KM for ding@lists.math.uh.edu; Fri, 01 Oct 2010 06:17:56 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1P1dcR-0007Pk-JN for ding@lists.math.uh.edu; Fri, 01 Oct 2010 06:17:56 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1P1dcQ-0000Hl-00 for ; Fri, 01 Oct 2010 13:17:38 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P1dcN-0000Ep-KJ for ding@gnus.org; Fri, 01 Oct 2010 13:17:35 +0200 Original-Received: from 193.160.199.1 ([193.160.199.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Oct 2010 13:17:35 +0200 Original-Received: from bjorn by 193.160.199.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Oct 2010 13:17:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 38 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 193.160.199.1 User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:M7onWBoMKpsetrDfHLAGkvru95I= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:72386 Archived-At: Lars Magne Ingebrigtsen writes: > openssl s_client is "-starttls imap" (or whatever other protocol you're > using) -- and THEN IT EATS THE GREETING. You mean the problem that you end up with just the final ". OK CAPABILITY completed" and not the actual capability list? Doesn't matter much, does it? Send a cabability command if you cannot parse IMAP4rev1 out of the OK CAPABILITY. In fact reading the RFC 3501, sending the CAPABILITY as part of the preauth OK is optional: A server MAY send capabilities automatically, by using the CAPABILITY response code in the initial PREAUTH or OK responses, and by sending an updated CAPABILITY response code in the tagged OK response as part of a successful authentication. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities. although I haven't yet seen an IMAP4rev1 server not sending it automatically... But you should handle such servers, and that will also handle the case where openssl ate your automatic capability. One question I can't find the RFC answer to right now: Is it possible for the capabilities to change depending on the logged in user? Maybe some users are allowed to use server resource intensive commands like sorting and threading while others are not? The quoted text above certainly indicates that this may happen. If this is possible, then you should probable issue another capability command right after authenticating as well. Bjørn