> > Marcello Marangio ha scritto: > >>> So if after a PASS a QUIT is not issued, the user gets stuck. > >>> > >>> The question is: if a client chooses the USER and PASS sequence to get > >> the > >>> authentication (instead of APOP), is the QUIT command mandatory? > >>> > > > > Anyway, the question is the same, even if is more rfc1939 related rather > > than james: is QUIT command the ONLY way to pass from the AUTHENTICATION > > state to the UPDATE state? > > If you want my opinion you have to reset the lock on session close anyway. > > Stefano > Yes, I really appreciate your opinion!
Reading the rfc1939: "Once the POP3 server has determined through the use of any authentication command that the client should be given access to the appropriate maildrop, the POP3 server then acquires an exclusive- access lock on the maildrop, as necessary to prevent messages from being modified or removed before the session enters the UPDATE state." And "When the client issues the QUIT command from the TRANSACTION state, the POP3 session enters the UPDATE state." But: "If a session terminates for some reason other than a client-issued QUIT command, the POP3 session does NOT enter the UPDATE state and MUST not remove any messages from the maildrop". Summing up: if the client doesn't issue a QUIT command the maildrop remains locked. > It is not acceptable that a disconnect in the AUTHENTICATION phase > results in a forever locked inbox. You're right. Now I have to understand when to unlock the maildrop, other than processing the QUIT command; this means I have to understand when a session ends other than QUIT. This could be the right starting point to close the lock bug ) https://issues.apache.org/jira/browse/JAMES-457). Any help is really appreciated. Ciao Marcello --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
