I recently ran across an IMAP server which advertises several extra
capabilities after you've successfully issued a LOGIN. (FWIW, in this
case I think it's a server config bug, but that's another story). In the
absence of TLS, or SASL with an encryption layer, this seemed kind of
strange, and indeed RFC 2060 explicitly forbids this. From Sec 6.1.1.:
The CAPABILITY command requests a listing of capabilities that the
server supports. The server MUST send a single untagged
CAPABILITY response with "IMAP4rev1" as one of the listed
capabilities before the (tagged) OK response. This listing of
capabilities is not dependent upon connection state or user. It
is therefore not necessary to issue a CAPABILITY command more than
once in a connection.
However, I couldn't find any similar kind of restriction in the revised
draft (draft-crispin-imapv-16.txt). It seems to me that this is
unfortunate: A client written to follow 2060 (i.e. not using SASL or
TLS) would be entitled not to re-issue CAPABILITY.
Obviously, the blanket statement about only having to send CAPABILITY
once doesn't apply. Should there be something more explicit in the spec
here? Something to the effect of capabilities not changing, except for
the case of AUTHENTICATE and extensions?
________________________________________
Grant Baillie
Mac OS X Mail - Apple Computer, Inc.
________________________________________
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
