CommuniGate Pro POP Module

Intro
Installation
SysAdmin
Objects
Transfer
Access 
Sharing 
POP
IMAP 
Web User 
LDAP 
ACAP 
PWD 
Directory
Data Files
Clusters
WebMail
Miscellaneous
Licensing
HowTo
  • Post Office Protocol (POP3)
  • Configuring the POP module
  • User Authentication
  • Special Features
  • The XTND XMIT Extension
  • Notification Alerts
  • Accessing Additional Mailboxes
  • Accessing Individual Mail in a Unified Account
  • 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 messages to the CommuniGate Pro server.

    Post Office Protocol (POP3)

    The Post Office Protocol allows computers to retrieve messages from mailboxes on mail servers. 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 support multi-mailbox accounts. If a client application specifies a multi-mailbox (folder) 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 a Web browser to configure the POP module. Open the Access page in the WebAdmin Settings section (realm):

    Serving POP Clients
    Log:  
    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.


    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 Sharing 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 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 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 notifiction 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 mailbox mailboxname in the accountname account, a user should specify the account name as: mailboxname#accountname:
    Account name
    (specified in the mailer settings)
    Accessed Mailbox
    jsmithmailbox INBOX in the jsmith account
    private#jsmithmailbox private in the jsmith account
    lists/info#jsmith@client1.commailbox lists/info 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 Sharing 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
    jsmithmailbox INBOX in the jsmith account
    ~public/announces#jsmiththe public mailbox announces
    ~boss/INBOX#jsmithmailbox INBOX 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-1999, Stalker Software, Inc.