CommuniGate Pro
Version 6.1
Access
 
 
POP

POP Module

The CommuniGate Pro POP module implements a POP3 server. POP3 servers allow client applications (mailers) to retrieve messages from Account Mailboxes using the POP3 Internet protocol (STD0053, RFC1939, RFC1734, RFC1725) via TCP/IP networks.

The CommuniGate Pro POP module implements several protocol extensions, including the XTND XMIT extension. Some mailers can employ this feature to submit E-mail messages to the CommuniGate Pro Server.

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:

Processing
Log Level: Channels: Listener
Use the Log Level setting to specify what kind of information the POP module should put in the Server Log. Usually you should use the Major (message transfer reports) or Problems (message transfer and non-fatal errors) levels. But when you experience problems with the POP module, you may want to set the Log Level setting to Low-Level or All Info: in this case protocol-level or link-level details will be recorded in the System Log as well. When the problem is solved, set the Log Level setting to its regular value, otherwise your System Log files will grow in size very quickly.

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 Authentication

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.


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 Features

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.


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:

Account name
(specified in the mailer settings)
Accessed Mailbox
jsmithINBOX Mailbox in the jsmith Account
private#jsmithprivate Mailbox in the jsmith Account
lists/info#jsmith@client1.comlists/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
jsmithINBOX Mailbox in the jsmith Account
~public/announces#jsmiththe public Mailbox announces
~boss/INBOX#jsmithINBOX Mailbox in the boss Account
In all samples above, the user is authenticated as jsmith, using the jsmith account password.

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.

Example:
The Router line:
client1.com = Cl1.local
The first message is sent to:
abcdef@client1.com
It is stored in the Cl1 account INBOX with unique ID 101, and a header field is added:
X-Real-To: abcdef
The next message is sent to:
xyz@client1.com
It is stored in the Cl1 account INBOX with unique ID 102, and a header field is added:
X-Real-To: xyz
After these 2 messages are stored, POP sessions will show different views depending on the user name specified:

S: +OK CommuniGate Pro POP Server is ready
C: USER Cl1
S: +OK, send pass
C: PASS mypassword
S: +OK 2 message(s)
C: UIDL
S: +OK
S: 1 101
S: 2 102
S: .
C: QUIT
S: +OK bye-bye

S: +OK CommuniGate Pro POP Server is ready
C: USER abcdef@client1.com
S: +OK, send pass
C: PASS mypassword
S: +OK 1 message(s)
C: UIDL
S: +OK
S: 1 101
S: .
C: QUIT
S: +OK bye-bye

S: +OK CommuniGate Pro POP Server is ready
C: USER xyz@client1.com
S: +OK, send pass
C: PASS mypassword
S: +OK 1 message(s)
C: UIDL
S: +OK
S: 1 102
S: .
C: QUIT
S: +OK bye-bye

S: +OK CommuniGate Pro POP Server is ready
C: USER blahblah@client1.com
S: +OK, send pass
C: PASS mypassword
S: +OK 0 message(s)
C: UIDL
S: +OK
S: .
C: QUIT
S: +OK bye-bye

CommuniGate® Pro Guide. Copyright © 1998-2015, Stalker Software, Inc.