CAPA command
Adam Kippes
> I tried the Eudora website to find out about this command, and
> couldn't find anything. Anyone know what it is, and how to disable it
> (5.0.0.13 beta).
Maybe authentication, auto configuration, who knows? If the server
doesn't recognize it, the command is ignored - what's the problem?
-- AK
--
adam....@pobox.com
PGP keys available from servers
Adam Kippes
> I tried the Eudora website to find out about this command, and
> couldn't find anything. Anyone know what it is, and how to disable it
> (5.0.0.13 beta).
Okay, if you *really* need to know... and no, I don't see any way to
disable the inquiry:
================================
5. The CAPA Command
The POP3 CAPA command returns a list of capabilities supported by the
POP3 server. It is available in both the AUTHORIZATION and
TRANSACTION states.
A capability description MUST document in which states the capability
is announced, and in which states the commands are valid.
Capabilities available in the AUTHORIZATION state MUST be announced
in both states.
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.)
If the authentication step negotiates an integrity protection layer,
the client SHOULD reissue the CAPA command after authenticating, to
check for active down-negotiation attacks.
Each capability may enable additional protocol commands, additional
parameters and responses for existing commands, or describe an aspect
of server behavior. These details are specified in the description
of the capability.
Section 3 describes the CAPA response using [ABNF]. When a
capability response describes an optional command, the <capa-tag>
SHOULD be identical to the command keyword. CAPA response tags are
case-insensitive.
CAPA
Arguments:
none
Restrictions:
none
Discussion:
An -ERR response indicates the capability command is not
implemented and the client will have to probe for
capabilities as before.
An +OK response is followed by a list of capabilities, one
per line. Each capability name MAY be followed by a single
space and a space-separated list of parameters. Each
capability line is limited to 512 octets (including the
CRLF). The capability list is terminated by a line
containing a termination octet (".") and a CRLF pair.
Possible Responses:
+OK -ERR
Examples:
C: CAPA
S: +OK Capability list follows
S: TOP
S: USER
S: SASL CRAM-MD5 KERBEROS_V4
S: RESP-CODES
S: LOGIN-DELAY 900
S: PIPELINING
S: EXPIRE 60
S: UIDL
S: IMPLEMENTATION Shlemazle-Plotz-v302
S: .
5. The CAPA Command
The POP3 CAPA command returns a list of capabilities supported by the
POP3 server. It is available in both the AUTHORIZATION and
TRANSACTION states.
A capability description MUST document in which states the capability
is announced, and in which states the commands are valid.
Capabilities available in the AUTHORIZATION state MUST be announced
in both states.
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.)
If the authentication step negotiates an integrity protection layer,
the client SHOULD reissue the CAPA command after authenticating, to
check for active down-negotiation attacks.
Each capability may enable additional protocol commands, additional
parameters and responses for existing commands, or describe an aspect
of server behavior. These details are specified in the description
of the capability.
Section 3 describes the CAPA response using [ABNF]. When a
capability response describes an optional command, the <capa-tag>
SHOULD be identical to the command keyword. CAPA response tags are
case-insensitive.
CAPA
Arguments:
none
Restrictions:
none
Discussion:
An -ERR response indicates the capability command is not
implemented and the client will have to probe for
capabilities as before.
An +OK response is followed by a list of capabilities, one
per line. Each capability name MAY be followed by a single
space and a space-separated list of parameters. Each
capability line is limited to 512 octets (including the
CRLF). The capability list is terminated by a line
containing a termination octet (".") and a CRLF pair.
Possible Responses:
+OK -ERR
Examples:
C: CAPA
S: +OK Capability list follows
S: TOP
S: USER
S: SASL CRAM-MD5 KERBEROS_V4
S: RESP-CODES
S: LOGIN-DELAY 900
S: PIPELINING
S: EXPIRE 60
S: UIDL
S: IMPLEMENTATION Shlemazle-Plotz-v302
S: .
================================
Adam Kippes
> Okay, if you *really* need to know... and no, I don't see any way to
> disable the inquiry:
I forgot to mention that this is from RFC2449. Among the members of the
working group is none other than our good friend, one R. Gellens. <g>