Re: [pop3ext] UIDL response to CAPA command

Bill Shannon <> Sat, 17 November 2012 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B26321F890F for <>; Sat, 17 Nov 2012 00:02:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o0OsnbRjqiOZ for <>; Sat, 17 Nov 2012 00:02:29 -0800 (PST)
Received: from (brmea-mail-1.Sun.COM []) by (Postfix) with ESMTP id DF24421F8471 for <>; Sat, 17 Nov 2012 00:02:23 -0800 (PST)
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id qAH82KZP009182; Sat, 17 Nov 2012 08:02:21 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id qAH82HZg009024; Sat, 17 Nov 2012 08:02:17 GMT
Received: from [] (vostro []) by (8.14.4+Sun/8.14.4) with ESMTP id qAH8RBaQ005952; Sat, 17 Nov 2012 00:27:11 -0800 (PST)
Message-ID: <>
Date: Sat, 17 Nov 2012 00:02:36 -0800
From: Bill Shannon <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Randall Gellens <>
References: <> <196CBE3CC7222C8957041F15@dhcp-amer-vpn-rmdc-anyconnect-10-159-123-100> <> <p0624060bccccdd31ec74@[]>
In-Reply-To: <p0624060bccccdd31ec74@[]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Chris Newman <>,
Subject: Re: [pop3ext] UIDL response to CAPA command
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions and updates to Post Office Protocol \(POP3\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Nov 2012 08:02:30 -0000

Sorry, I couldn't tell if you were agreeing with Chris or not.

I understand how it works for capabilities that have parameters.

What I don't understand is what the rules are for capabilities that
don't have parameters.

Let's try the simple yes or no question...

Does RFC 2449 allow the UIDL capability to be missing from a CAPA
response before authentication, but included in a CAPA response
after authentication?

The spec says:

   Capabilities available in the AUTHORIZATION state MUST be announced
   in both states.

UIDL is not available in the AUTHORIZATION state, only the TRANSACTION
state, so the above doesn't apply.

UIDL has no arguments, so all the rules about arguments don't apply.

Are there other rules in the spec that I'm missing?

Randall Gellens wrote on 11/16/2012 10:36 PM:
> At 3:03 PM -0800 11/14/12, Bill Shannon wrote:
>>  Well, that was my initial reading as well, and I'd be happy with that
>>  interpretation, but the spec says:
>>     If a capability is announced in both states, but the argument might
>>     differ after authentication, this possibility MUST be stated in the
>>     capability description.
>>     (These requirements allow a client to issue only one CAPA command if
>>     it does not use any TRANSACTION-only capabilities, or any
>>     capabilities whose values may differ after authentication.)
>>  Note that it talks about "arguments" or "values", not about whether
>>  the capability itself might be present or not.
> The wording about arguments and values applies to those capabilities that are
> announced in both states.   The text is saying that the client has to be able to
> know if a capability that it wants to use might only be announced after
> authenticating, or if it is announced before authenticating, if it might have
> different parameters after authenticating.  If so, it needs to issue a second
> CAPA after authenticating, but if not, it can perhaps save a round-trip and
> pipeline other commands right after authenticating.
> A quick check of the IANA registry at
> shows only two capabilities whose parameters may differ: LOGIN-DELAY and EXPIRE
> (which makes sense since these express server policy that may very well differ
> per user).  I don't see any capabilities listed that are only announced in
> TRANSACTION state, although IMPLEMENTATION is allowed to be (but of course no
> client behavior is affected).
>>  It's that ambiguity that caused me to ask, just to be sure...
> Sorry if the wording seemed ambiguous.  The intent is to group together for
> special notice two kinds of capabilities: those that are only announced in
> TRANSACTION state and those that are announced in both AUTHENTICATION and
> TRANSACTION but whose parameters may differ between the states.
>>  Chris Newman wrote on 11/14/12 14:02:
>>>  Section 6.8 says:
>>>  Announced states / possible differences:
>>>  both / no
>>>  So it looks like you're not allowed by RFC 2994's CAPA registration for UIDL
>>>  advertisement to change after authentication.
>>>          - Chris
>>>  --On November 14, 2012 13:14:25 -0800 Bill Shannon <>
>>> wrote:
>>>>  Does RFC 2994 allow the UIDL capability to be missing from a CAPA
>>>>  response before authentication, but included in a CAPA response
>>>>  after authentication?
>>  _______________________________________________
>>  pop3ext mailing list