|
Version 6.3
|
Version 6.3 |
|
| ||||||||||||||||||||||
Post Office Protocol (POP3)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. Configuring the POP module
Use the WebAdmin Interface to configure the POP module.
Open the Access page in the Settings realm:
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. User AuthenticationThe 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. Secure (encrypted) Access
The POP module can be used to accept SSL/TLS (encrypted) connections from
user mailers (see the Listener configuration note above). Additionally, the
POP module supports the STLS command that allows client mailers to
establish plain text, unencrypted connections (using the regular TCP port 110),
and then start encrypted communications on those connections.
Special FeaturesUnlike 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. The XTND XMIT Extension
The CommuniGate Pro POP module implements the XTND XMIT protocol extension.
Mailer applications that support this extension (like Eudora®) can
submit messages to the Server via a POP connection.
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. Notification Alerts
The POP3 protocol does not provide any method to send a notification alert to the
client mailer. If an Account has any pending Alert message,
the CommuniGate Pro POP Module simply rejects the connection request after the user is authenticated.
The returned error code contains the Alert message text:
ALERT: alert message text
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. Accessing Additional Mailboxes
Unlike the IMAP protocol, the POP3 protocol was designed
to access only one Account Mailbox - the INBOX Mailbox.
The POP module allows users to access any Account Mailbox by specifying the
Mailbox name as a part of the Account name. To access the mailboxname Mailbox
in the accountname Account, a user should specify the account name as:
mailboxname#accountname:
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:
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. Accessing Individual Mail in a Unified Account
The POP module implements Unified Domain-Wide Account
filtering. As all access modules, the POP module uses the
Router to process the specified username.
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.
| |||||||||||||||||||||||
