James Server
  1. James Server
  2. JAMES-457

POP3 server doesn't perform an exlusive-access locks in a transaction required by rcf1939.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.0
    • Fix Version/s: 3.0-M2
    • Component/s: POP3Server
    • Labels:
      None
    • Environment:
      windows 2000 server, linux redhat

      Description

      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

        Activity

        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12566561 ] jira [ 12582108 ]
        Mark Thomas made changes -
        Workflow jira [ 12352078 ] Default workflow, editable Closed status [ 12566561 ]
        Norman Maurer made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Norman Maurer [ norman ]
        Resolution Fixed [ 1 ]
        Hide
        Norman Maurer added a comment -

        With the new code we just "mark" a message deleted in the session until quit is processed. In Quit we then delete the message. So until then its still visible to other session. If the second session try to open the message after the first processed quit it will show an error.

        I tried the same thing with dovecot and courier pop3. Both do the same. So I think thats ok now

        Show
        Norman Maurer added a comment - With the new code we just "mark" a message deleted in the session until quit is processed. In Quit we then delete the message. So until then its still visible to other session. If the second session try to open the message after the first processed quit it will show an error. I tried the same thing with dovecot and courier pop3. Both do the same. So I think thats ok now
        Norman Maurer made changes -
        Field Original Value New Value
        Fix Version/s 3.0-M2 [ 12315479 ]
        Hide
        Norman Maurer added a comment -

        Assign to M2

        Show
        Norman Maurer added a comment - Assign to M2
        Hide
        Stefano Bagnara added a comment -

        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.

        Show
        Stefano Bagnara added a comment - 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.
        Marcello Marangio created issue -

          People

          • Assignee:
            Norman Maurer
            Reporter:
            Marcello Marangio
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development