[ http://issues.apache.org/jira/browse/JAMES-457?page=comments#action_12371202 ]
Stefano Bagnara commented on JAMES-457: --------------------------------------- Appending interesting comments by Noel and Marcello appreared on the mailinglist: ------------------------------------------------------ As I read RFC 1939 Section 4, we may not need to lock the mailbox for exclusive use. The key phase is "as necessary to prevent messages from being modified or removed before the session enters the UPDATE state." At present, JAMES maintains the entire state of the mailbox in memory during the transaction state. If another session were to open and delete a message, we would need to ensure that the deleted message was still available for the other session(s) still in transaction state. In all cases, the maildrop should still permit new messages to arrive, which would not be known to the current transaction state. -------------------------------------------------------- I believe the rfc1939 states the locking mechanism as *the* method to prevent messages from being modified or removed. The effects of locking are 2: - no other session (on the same james instance) can enter the transaction state before the first one enters the update state; because of that, no other session can modify or delete messages before the first session enters in the update state, i.e. deletes the messages. - two different mail clients accessing via pop3 the same mailbox will *never* get the same message. About the last point, even thought the rfc1939 doesn't explicitly state it, it is a standard behavoir: we tested several mail servers and actually no one of them allows two clients to get the same message, because of the exclusive access lock. In our case, this is *very* critical: tho clients getting the same message would cause two different people to trigger the same administrative procedure. ------------------------------------------------------------------------------- I think that we should not use repository locking to prevent the problematic behaviour. We should better add a "single session" enforcement configuration to POP3. > POP3 server doesn't perform an exlusive-access locks in a transaction > required by rcf1939. > ------------------------------------------------------------------------------------------ > > Key: JAMES-457 > URL: http://issues.apache.org/jira/browse/JAMES-457 > Project: James > Type: Bug > Components: POP3Server > Versions: 2.2.0 > Environment: windows 2000 server, linux redhat > Reporter: Marcello Marangio > > According to rfc1939 the standard behavoir of a pop3 server is: > 1) The client opens a connection and server gets into the AUTORISATION state. > 2) The user authenticate himself and the server gets into the TRANSACTION > state, "... 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. " > 3) The client sends a QUIT command and the server gets into the UPDATE state, > updating the repository. > James doesn't perform the exclsive-access lock required by rfc1939 -- 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]
