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 2007/05/08 17:11:51 UTC
QUIT command
Hi all
As you probably already know, James performs a user lock processing the PASS
command and releases the processing the QUIT command.
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?
If not, it is quite of a bug.
Marcello
R: R: QUIT command
Posted by Marcello Marangio <m....@tno.it>.
>
> 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: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: R: QUIT command
Posted by Stefano Bagnara <ap...@bago.org>.
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.
It is not acceptable that a disconnect in the AUTHENTICATION phase
results in a forever locked inbox.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
R: QUIT command
Posted by Marcello Marangio <m....@tno.it>.
> -----Messaggio originale-----
> Da: Stefano Bagnara [mailto:apache@bago.org]
> Inviato: martedì 8 maggio 2007 20.02
> A: James Users List
> Oggetto: Re: QUIT command
>
> Marcello Marangio ha scritto:
> > Hi all
> >
> > As you probably already know, James performs a user lock processing the
> PASS
> > command and releases the processing the QUIT command.
>
> An user lock? Isn't this a custom patch you did to your own James
> Server? IIRC we (official JAMES Server distribution) never supported
> user locking (and this is a known bug, but not the bug you're reporting
> now).
>
> Please check if the lock is in your custom code or please point us to
> the code locking the user.
Yes, you're right: I was looking at some old code I made to fix the lock bug
for a single instance, and I thought it was some original james code...
>
> > 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 not, it is quite of a bug.
... of mine.
Thanks
Marcello
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: QUIT command
Posted by Stefano Bagnara <ap...@bago.org>.
Marcello Marangio ha scritto:
> Hi all
>
> As you probably already know, James performs a user lock processing the PASS
> command and releases the processing the QUIT command.
An user lock? Isn't this a custom patch you did to your own James
Server? IIRC we (official JAMES Server distribution) never supported
user locking (and this is a known bug, but not the bug you're reporting
now).
Please check if the lock is in your custom code or please point us to
the code locking the user.
Stefano
> 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?
>
> If not, it is quite of a bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org