Version 6.1 |
|||||||||||||||||||||||||||||||||||
|
|
The Post Office Protocol allows computers to retrieve messages from mail server mailboxes. A computer running a mailer (mail client) application connects to the mail server computer and provides account (user) name and the password. If access to the specified user account is granted, the mail application sends protocol commands to the mail server. These protocol commands tell the server to list all messages in the mailbox, to retrieve certain messages, or to delete them. When a server receives a request to retrieve a message, it sends the entire message to the mail client. The mail client may choose to retrieve only the first part of the message.
The POP3 protocol does not provide direct support multi-mailbox Accounts. If a client application specifies a multi-mailbox Account, the INBOX Mailbox is opened.
When the client application sends a request to delete a message from the Mailbox, the message is not deleted immediately, but it is marked by the server. Only when the client application ends the session properly and closes the connection, the marked messages are then removed.
The POP module supports the XTND XMIT extension of the POP protocol. This extension allows users to submit messages via the POP protocol instead of the SMTP protocol.
The POP module records in the System Log are marked with the POP tag.
When you specify a non-zero value for the Maximum Number of Channels setting, the POP module creates a so-called "listener". The module starts to accept all POP connections that mail clients establish in order to retrieve mail from your server. The setting is used to limit the number of simultaneous connections the POP module can accept. If there are too many incoming connections open, the module will reject new connections, and the mail client should retry later.
By default, the POP module Listener accepts clear text connections on the TCP port 110. The standard TCP port number for secure POP connections is 995, but it is not enabled by default. Follow the listener link to tune the POP Listener.
The POP module supports the STARTTLS command that allows client mailers to establish a connection in the clear text mode and then turn it into a secure connection.
The POP module allows users to employ all authentication methods supported with the CommuniGate Pro Server, as well as the APOP method.
The Account Settings can be used to limit the frequency of POP client logins.
Unlike many other POP servers, the CommuniGate Pro POP module does not "lock" the Mailbox it opens on a mail clients behalf. The open Mailbox can be used by other client applications at the same time. See the Mailboxes section for the details.
Since the POP3 protocol was not designed to support these features, the CommuniGate Pro POP module:When a client mailer retrieves a message with the RETR command, the message is marked with the "Seen" flag (this change is noticed when using an IMAP or XIMSS client with the same Mailbox). The TOP command that allows a client POP mailer to retrieve only the first part of the message does not set the Seen flag.
The POP module supports the "empty AUTH" command (the AUTH command without parameters), returning the list of supported SASL methods.
This feature can be useful for mobile users that would be otherwise unable to send their messages via CommuniGate Pro SMTP due to the Server anti-spam protection. Submitting messages via POP can be more convenient than using the "address-remembering" scheme, since this method does not have time restrictions.
When the user repeats a connection attempt to the same Account, the next pending Alert message is returned as an error - till all Alert messages are sent to that user.
Account name (specified in the mailer settings) |
Accessed Mailbox |
jsmith | INBOX Mailbox in the jsmith Account |
private#jsmith | private Mailbox in the jsmith Account |
lists/info#jsmith@client1.com | lists/info Mailbox in the jsmith Account in the client1.com Domain |
The POP module allows a user to access any Mailbox in any other Account (a foreign or shared Mailbox), as well as public Mailboxes. See the Mailboxes section for the details.
If a user can log into the accountname Account and wants to access the Mailbox mailboxname in the otheraccount Account, that user should specify the Account name as: ~otheraccount/mailboxname#accountname:Account name (specified in the mailer settings) |
Accessed Mailbox |
jsmith | INBOX Mailbox in the jsmith Account |
~public/announces#jsmith | the public Mailbox announces |
~boss/INBOX#jsmith | INBOX Mailbox in the boss Account |
If the authenticated user does not have a right to delete messages in the selected Mailbox, the DELE protocol operations fail and an error code is returned to the user mailer.
The POP module can also use the Direct Mailbox Addressing feature to open additional Mailboxes.
If a client mailer specifies the abcdef@client1.com username (as used in the example), the Router routes this address to the Local account Cl1, and it returns abcdef as the local part of the resulting address.
The POP module checks the local part returned by the Router, and if this string is not empty, it performs filtering on the open Mailbox: the module hides all Mailbox messages that do not have the X-Real-To header field (or other field specified in the Local Delivery module settings), or do not have the specified string (individual name) listed in that header field.
So, if the user has specified the abcdef@client1.com username, only the messages originally routed to that particular address will be shown in the CL1 Account Mailbox.
If a user connects as Cl1, the same Account Mailbox will be opened, but since the local part string will be empty in this case, all Mailbox messages will be shown.