Next: The ProtoWrap wrapper implementation
Up: POP3 - RFC 1081
Previous: POP3 - RFC 1081
  Contents
As soon a connection is established, the client will be greeted by a success
string, usually containing the name and version of the server software, and
it enters the first stage of a POP3 connection: the AUTHORIZATION state.
In this first state, there are only three possible commands:
- USER followed by a username tells the server who is trying to log in
to get his messages. Most servers answer with a success string, regardless of
the existence of the username, in order not to unwillingly give a possible attacker
the list of valid usernames existing in the server.
- PASS followed by the user's password, gives the server enough information
to identify the user. If the password matches the username and the user's mailbox
is currently readable and lockable, a success string is sent to the client, usually containing the number of pending
messages, and the session proceeds to the TRANSACTION. If the password
does not match the username or the user's mailbox can not be locked, a failure
string is sent back, explaining the reason for failure, and remains in the AUTHORIZATION
state.
- QUIT tells the server to drop the connection. It always gets a successful
answer.
The TRANSACTION state implements the following commands:
- STAT returns a successful answer, followed by a space, the number of
pending messages, a space and the total number of bytes waiting to be sent.
The RFC strongly suggests that the server should add no comments to this answer,
in order to make it easier to be parsed:
C: STAT
S: +OK 3 5710
- LIST with no arguments returns a list of messages in the a format like
the following:
C: LIST
S: +OK 3 messages (5710 octets)
S: 1 1206
S: 2 2001
S: 3 2503
S: .
Which means, the message number and the number of bytes it has.
If LIST is called with a numeric argument, it answers with a format similar
to STAT, indicating the message number and its length, or a failure
string if the requested message does not exist or has been deleted.
- RETR requires a numeric argument, and returns the whole text of the
requested message. If the message is deleted or non-existent the answer will
be a failure string. Otherwise, it will be in the following format:
C: RETR 1
S: +OK Message follows
S: <the entire message>
S: .
If the number given is higher than the highest message number accessed, the
pointer to the highest message accessed is set to one past the deleted message
number.
- DELE takes a numeric argument, and marks the corresponding message
as deleted. If the message does not exist or it has already been marked as deleted,
a failure string will be returned. Otherwise, a success string will be returned.
If the number given is higher than the highest message accessed, the pointer
to the highest message number accessed is set to one past the deleted message
number. Note that the message is not actually deleted until the TRANSACTION
state is finished.
- NOOP returns a success string, and does nothing.
- LAST returns a success string and the last message number accessed,
or zero if no messages have been accessed.
- RSET returns a success string, and is the equivalent of starting over
the TRANSACTION state: It clears all the deleted flags set by DELE
and resets the last message number accessed to zero.
- QUIT leaves the TRANSACTION state and enters the UPDATE
state. When leaving the transaction state with this command, the messages marked
to be deleted are effectively purged off the mailbox.
The following optional commands are also defined. The RFC states they can be
left out of a particular implementation:
- TOP (TRANSACTION state) takes two numeric arguments: The message
number and the number of lines. If the requested message exists, the server
returns a success string, followed by the message headers and the indicated
number of lines of the message's text.
- RPOP (AUTHORIZATION state) performs a function similar to
PASS, although with a different mechanism: It authenticates a user
based on whether it comes from a trusted host.
Next: The ProtoWrap wrapper implementation
Up: POP3 - RFC 1081
Previous: POP3 - RFC 1081
  Contents
Gunnar Wolf
2001-03-12