[ http://issues.apache.org/jira/browse/JAMES-700?page=comments#action_12451059 ] Robert Burrell Donkin commented on JAMES-700: ---------------------------------------------
IMAP is a very tough protocol (IMO too complex but maybe more on that another time) so kudos to having got so far in definite agreement about 1, 3, 4, 5 RE: 2 here's my symptoms: sending a reset to the client means that the client will restart it's entire program up to where it left off. so, a single bug in a single command results in an uninformative error message being displayed (connection reset by peer) followed by a new connection and the whole process starts again from scratch. this results in the client becoming effectively unusable until killed. i've now tracked down the problem by studying the code but I fear that rule 2 is too harsh for most clients and most users. i've been running with catching all RuntimeException's thrown by any command and this works very well for me. i'll add some configuration and attach a patch for this since it'll probably be useful for anyone else who's using IMAP ATM. but i agree 2alt. * assume that client can recover and send a NO with error message is probably not a good idea i think that it should be possible to work out from the command whether it's reasonably safe to send a NO or not. so the rule would be: 2new. * for safe commands, send a NO; for unsafe commands send reset for example, perhaps (where reset means reset the connection, swallow mean ignore the error and NO means send a NO with message) CAPABILITY Command - reset NOOP Command - swallow LOGOUT Command - reset AUTHENTICATE Command - NO LOGIN Command - NO SELECT Command - reset? EXAMINE Command - NO CREATE Command - NO DELETE Command - NO RENAME Command - NO SUBSCRIBE Command - reset UNSUBSCRIBE Command - reset LIST Command - NO LSUB Command - reset STATUS Command - NO APPEND Command - NO CHECK Command - reset CLOSE Command - NO? EXPUNGE Command - NO SEARCH Command - NO FETCH Command - NO STORE Command - NO COPY Command - NO UID Command - NO > James resets connection when command throws RuntimeException > ------------------------------------------------------------ > > Key: JAMES-700 > URL: http://issues.apache.org/jira/browse/JAMES-700 > Project: James > Issue Type: Improvement > Components: IMAPServer > Reporter: Robert Burrell Donkin > Fix For: Trunk > > > I think that whenever a exception is thrown when processing an IMAP command > the socket connection is reset. This behaviour seems little less polite than > it needs to be. IMAP is stateless and IMHO errors should be returned within > the band. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
