You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Marcello Marangio <m....@tno.it> on 2006/03/15 16:40:06 UTC
RFC1939 and pop3 locks
Hi all.
Reading the RFC 1939 standard (http://www.faqs.org/rfcs/rfc1939.html), I
understand that:
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.
How come two clients configured with the same pop3 account get the same
bounce of messages?
Does james perform the exclusive-access lock?
Thanks
Marcello
PS: I reposted this message 'cause of mail problems; if it's duplicated I
apologize
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
R: RFC1939 and pop3 locks
Posted by Marcello Marangio <m....@tno.it>.
Hi Noel.
I see you point.
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.
Cheers
Marcello
> Noel J. Bergman wrote
>
> Marcello,
>
> 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.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: RFC1939 and pop3 locks
Posted by "Noel J. Bergman" <no...@devtech.com>.
Marcello,
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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
R: RFC1939 and pop3 locks
Posted by Marcello Marangio <m....@tno.it>.
Hi.
I submitted the bug, I worked on it and I think I solved it, using a
modified Lock class to lock the user in POP3Handler.doPASS and unlocking
the user in POP3Server.doQUIT.
In POP3Handler.doPASS there is a lock-check in an infinite loop with a 10
secs wait if it the user is locked and a break when the resource is freed.
I think it works fine in a single james instance environment.
I am thinking at a solution for a failover configuration environment, maybe
a locking system via web service.
Ciao
Marcello
> Stefano Bagnara wrote
> [...]
>
> I'm pretty sure that we don't lock the repository.
> Can you submit this issue to our issue tracker?
> https://issues.apache.org/jira/browse/JAMES
>
> Thank you,
> Stefano
>
> > PS: I reposted this message 'cause of mail problems; if it's
> > duplicated I apologize
>
> PS: I confirm we received it twice.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: RFC1939 and pop3 locks
Posted by Stefano Bagnara <ap...@bago.org>.
Marcello Marangio wrote:
> Reading the RFC 1939 standard (http://www.faqs.org/rfcs/rfc1939.html), I
> understand that:
> 1) The client opens a connection and server gets into the AUTORISATION
> state.
> [..]
> Does james perform the exclusive-access lock?
I'm pretty sure that we don't lock the repository.
Can you submit this issue to our issue tracker?
https://issues.apache.org/jira/browse/JAMES
Thank you,
Stefano
> PS: I reposted this message 'cause of mail problems; if it's duplicated I
> apologize
PS: I confirm we received it twice.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org