james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Bowesman <...@teamware.com>
Subject Re: [IMAP] CAPABILITY
Date Tue, 08 Apr 2008 21:59:09 GMT
Don't forget CAPABILITY before STARTTLS may be different to CAPABILITY after 
STARTTLS. See 6.2.1 (3501).
Antony


Robert Burrell Donkin wrote:
> one of the design aims of the new, baroque IMAP is to be easily extensible
> 
> for Commands with existing implementations, the typical use case is
> retaining the codec whilst replacing the processing. this can be done
> by amending the chain to replace the standard processor with an
> alternative.
> 
> for Commands without existing implementations, this means adding an
> decoder for the Command, a processor for the request message plus
> encoders for any novel responses. in this case, the processor and any
> encoders would be added to the appropriate chains. currently, a map is
> maintained of decoders against command name but this area needs
> revising for security. anyway, the decoder would be added (somehow).
> 
> the problem is CAPABILITY. this command returns a list of capabilities
> that the server supports
> 
> ATM this is hard coded in a global. this means that extensions cannot
> add their capabilities and announce themselves as is required. RFC3501
> (but not RFC2060) requires a secure mode with STARTTLS, LOGINDISABLED
> and AUTH=PLAIN capabilities. this secure mode is incompatible with
> older RFC2060 clients which do not support STARTTLS. so the
> capabilities they advertise should also be configurable.
> 
> this suggests the introduction of a context (ImapContext, say) into
> the design. this will need to store read-only initial configuration
> information (strings? beans?), maintain a modifiable list of
> capabilities (probably strings) and a version string.
> 
> the IMAP chains are created after upon configuration so it should be
> possible to inject a fully initialised ImapContext
> 
> questions?
> opinions?
> 
> - robert
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message