You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Stefano Bagnara (JIRA)" <se...@james.apache.org> on 2006/03/21 11:01:02 UTC
[jira] Commented: (JAMES-457) POP3 server doesn't perform an
exlusive-access locks in a transaction required by rcf1939.
[ 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org