The CommuniGate Pro RPOP implements E-mail message retrieval using the POP3 Internet protocol (STD0053) via TCP/IP networks. While the POP module allows the CommuniGate Pro users to retrieve mail from their Server mailboxes, the RPOP module retrieves messages from other (remote) hosts and delivers them to user mailboxes or to other destinations.
For each registered user, the RPOP module can retrieve messages from several remote mailboxes. The RPOP module can retrieve mail for your entire domain using "Unified Domain-wide accounts" and distribute retrieved messages to their recipients.
The RPOP module can be used when the CommuniGate Pro Server has a dial-up connection with dynamically assigned IP address, and thus the Server cannot receive mail via SMTP. The RPOP module polls the specified remote host (ISP) accounts, retrieves messages and stores them in the Server mailboxes.
The RPOP module supports Domain-Wide Accounts. A Domain-wide account is an account on the ISP or any other host that collects all messages sent to your domain. The RPOP module retrieves all messages from such an account and distributes them based on the addressing information in the message headers. The RPOP module can poll several Unified Domain-wide Accounts.
The RPOP module is useful even if the CommuniGate Pro Server has a full-time Internet connection. A user that has several accounts on several hosts can instruct the RPOP module to poll those accounts, so all their mail is collected in their CommuniGate Pro account.
Use a Web browser to configure the RPOP module. Polling Settings Log: Crashes Only Failures Major Problems Low Level All Info Delay Failed Hosts for: 15 seconds 30 seconds 1 minute 2 minutes 3 minutes 5 minutes 10 minutes 20 minutes 1 hour 2 hours 3 hours 6 hours 12 hours 1 day 2 days 3 days 1 week Channels Limit: 0 5 10 25 50 100 250 500 Delay Failed Accounts for: 15 seconds 30 seconds 1 minute 2 minutes 3 minutes 5 minutes 10 minutes 20 minutes 1 hour 2 hours 3 hours 6 hours 12 hours 1 day 2 days 3 days 1 week Use APOP Log Use the Log setting to specify what kind of information the RPOP 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 RPOP 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 RPOP module records in the System Log are marked with the RPOP tag. Channels Limit When you specify a non-zero value for the Channels Limit setting, the RPOP module starts to connect to the remote hosts and retrieve mail from accounts on those hosts. The setting is used to limit the number of simultaneous connections the RPOP module can initiate. Use APOP The RPOP can use the secure APOP authentication method when connecting to hosts that support this feature. If for any reason you want the RPOP module to always use the "clear text" passwords, disable the Use APOP option. Delay Failed Hosts When the RPOP module fails to connect to an external host, it marks the host as "failed" and stops polling all accounts on that host. The option specifies when the RPOP module should try to poll the failed host again. Delay Failed Account When the RPOP module fails to open a mailbox (wrong password, remote mailbox is locked, etc.), or if the connection fails when the module retrieves messages from a remote account, the module marks an account as "failed". The option specifies when the RPOP module should make the next attempt to poll the failed account. Click the Update button to modify the RPOP module settings.
Use a Web browser to configure the RPOP module.
Click the Update button to modify the RPOP module settings.
If a mail account on an external host collects mail directed to all users of your domain, the RPOP module can be instructed to retrieve mail from that account and distribute it to local users. Unified Domain-wide Account(s) Poll Every Account at Host Password Special Header never minute 2 minutes 3 minutes 5 minutes 10 minutes 15 minutes 30 minutes hour 2 hours 3 hours 6 hours 12 hours day 2 days 3 days week never minute 2 minutes 3 minutes 5 minutes 10 minutes 15 minutes 30 minutes hour 2 hours 3 hours 6 hours 12 hours day 2 days 3 days week Poll Every This option specifies how often the RPOP module should poll the remote account. Account This option specifies the name of the mail account on the remote host. For Unified Domain-Wide Accounts, this name is usually your domain name or part of your domain name. at Host This option specifies the exact name of the POP server that should be polled. Please note that this could be the name of a specific computer (as specified in DNS A-records), not just a generic domain name of the provider system. For example, if the provider has the domain name provider.com, its POP server is usually named mail.provider.com or pop.provider.com. Consult with your provider. Password The password assigned to the remote account. Special Header The name of the messages header (RFC822) field that the provider host inserts into the messages stored in the Unified Domain-Wide Account (see below). There is always an empty row in the Unified Accounts table. Use it to specify a new Unified Account. To remove an account, set the Poll Every option to never. Click the Update button to modify the RPOP module list of the Unified Domain-Wide Accounts.
If a mail account on an external host collects mail directed to all users of your domain, the RPOP module can be instructed to retrieve mail from that account and distribute it to local users.
Poll Every
Account
at Host
Password
Special Header
There is always an empty row in the Unified Accounts table. Use it to specify a new Unified Account. To remove an account, set the Poll Every option to never.
Click the Update button to modify the RPOP module list of the Unified Domain-Wide Accounts.
When a message is sent via the Internet, the information about the sender and the message recipients is sent in the so-called mail envelope. If mail is sent via SMTP, the envelope is sent as a sequence of the that protocol commands, if mail is sent via UUCP, the envelope is sent using additional files. The information in the envelope is usually the same as the information in the message headers, but it is not always true. The most important exceptions are: the message headers do not contain the addresses of the Bcc recipients.; the headers of a mailing-list message do not contain the addresses of the mailing list subscribers. When a message is stored in a mailbox, the envelope information about the sender is add to the message headers as the Return-Path header field. Usually, the envelope information about the recipients is not stored. When the RPOP module retrieves a message from a Unified Domain-Wide Account, it has to recompose the message envelope and deliver the message to its final recipient. If the message contains the Return-Path header field, the address in that field is placed in the new envelope as the sender's address, and the header field is removed from the message (it will be recreated when the message is delivered to its final destination). If a Unified Domain-Wide Account is created with the mail system that can copy the recipients addresses from the envelope into a message header field, then the delivery via RPOP is as reliable as SMTP and UUCP delivery. Enter the name of that header field into the Unified Account settings, and the RPOP module will look for that field in all messages retrieved from that account. The addresses from that field will be placed in new envelope and the messages will be directed to those addresses. All Stalker mail servers can be used to create Unified Domain-Wide Accounts. For those accounts, the envelope recipients are added to the message headers as the X-Real-To fields. A popular sendmail system can be configured to add X-Real-To header fields, too (See the Appendix A). If the host system cannot store envelope recipients in the message headers, leave the Special-Header field empty. In this case, the RPOP module will search for all To:, Cc: and Bcc: header fields in a retrieved message. It will use the addresses from those fields only if the domain name in those addresses can be routed to any non-SMTP module of the CommuniGate system. If the address is routed to the SMTP module, or the address cannot be routed at all (unknown user, etc), the RPOP module does not send any error messages to the sender, but simply ignores the address. As explained above, this can cause problems when envelope addresses are not the same as the addresses in the message headers. Besides, some systems do not process the Unified Accounts correctly, so if a message is sent to three users in your domain, those systems store three copies of the message in the Unified Account mailbox. Since each message header contains the addresses of all three users, the RPOP module will deliver three copies of the message to each user. The problems with Bcc, mailing lists, and duplicated message can be very annoying, so we strongly recommend you to ensure that the provider's mail system adds envelope information to the messages stored in your Unified Domain-Wide Account.
When a message is sent via the Internet, the information about the sender and the message recipients is sent in the so-called mail envelope. If mail is sent via SMTP, the envelope is sent as a sequence of the that protocol commands, if mail is sent via UUCP, the envelope is sent using additional files. The information in the envelope is usually the same as the information in the message headers, but it is not always true. The most important exceptions are:
When a message is stored in a mailbox, the envelope information about the sender is add to the message headers as the Return-Path header field. Usually, the envelope information about the recipients is not stored.
When the RPOP module retrieves a message from a Unified Domain-Wide Account, it has to recompose the message envelope and deliver the message to its final recipient. If the message contains the Return-Path header field, the address in that field is placed in the new envelope as the sender's address, and the header field is removed from the message (it will be recreated when the message is delivered to its final destination).
If a Unified Domain-Wide Account is created with the mail system that can copy the recipients addresses from the envelope into a message header field, then the delivery via RPOP is as reliable as SMTP and UUCP delivery. Enter the name of that header field into the Unified Account settings, and the RPOP module will look for that field in all messages retrieved from that account. The addresses from that field will be placed in new envelope and the messages will be directed to those addresses.
All Stalker mail servers can be used to create Unified Domain-Wide Accounts. For those accounts, the envelope recipients are added to the message headers as the X-Real-To fields.
A popular sendmail system can be configured to add X-Real-To header fields, too (See the Appendix A).
If the host system cannot store envelope recipients in the message headers, leave the Special-Header field empty. In this case, the RPOP module will search for all To:, Cc: and Bcc: header fields in a retrieved message. It will use the addresses from those fields only if the domain name in those addresses can be routed to any non-SMTP module of the CommuniGate system. If the address is routed to the SMTP module, or the address cannot be routed at all (unknown user, etc), the RPOP module does not send any error messages to the sender, but simply ignores the address.
As explained above, this can cause problems when envelope addresses are not the same as the addresses in the message headers. Besides, some systems do not process the Unified Accounts correctly, so if a message is sent to three users in your domain, those systems store three copies of the message in the Unified Account mailbox. Since each message header contains the addresses of all three users, the RPOP module will deliver three copies of the message to each user.
The problems with Bcc, mailing lists, and duplicated message can be very annoying, so we strongly recommend you to ensure that the provider's mail system adds envelope information to the messages stored in your Unified Domain-Wide Account.
The CommuniGate Pro RPOP module can poll POP accounts on remote hosts on behalf of the CommuniGate Pro users. For each user an unlimited number of external accounts can be specified. The accounts can be specified by the Server administrator, via a link on the Account settings page, or by the user herself, via the User Web Interface, if the right to specify remote accounts has been granted to the user by the administrator. Poll Every Account at Host Password never minute 2 minutes 3 minutes 5 minutes 10 minutes 15 minutes 30 minutes hour 2 hours 3 hours 6 hours 12 hours day 2 days 3 days week never minute 2 minutes 3 minutes 5 minutes 10 minutes 15 minutes 30 minutes hour 2 hours 3 hours 6 hours 12 hours day 2 days 3 days week The settings are the same as for the Unified Accounts, but the Special Header field is not presented. All messages retrieved on the user behalf are directed to that user, regardless of the message header contents.
The CommuniGate Pro RPOP module can poll POP accounts on remote hosts on behalf of the CommuniGate Pro users. For each user an unlimited number of external accounts can be specified. The accounts can be specified by the Server administrator, via a link on the Account settings page, or by the user herself, via the User Web Interface, if the right to specify remote accounts has been granted to the user by the administrator.
The settings are the same as for the Unified Accounts, but the Special Header field is not presented. All messages retrieved on the user behalf are directed to that user, regardless of the message header contents.
The following file can be used to force sendmail to store the envelope information in the messages headers. # This file should be placed into the directory cf/feature from # the sendmail.8.X.XX.cf.tar.Z archive. # To add special headers, the macros `FEATURE(xrealto)' should be # added to the main configuration file in the directory cf/cf, # and the flag T should be added to the mailer description. # # This file adds special headers with the `X-Real-To' keyword. # The special headers will be added to all messages routed to the # mailer marked with the `T' flag in the sendmail configuration. divert(0) VERSIONID(`@(#)xrealto.m4 0.1 1/4/96') divert(9) # add the X-Real-To: header field to the message # if the mailer is marked with the `T' flag H?T?X-Real-To: $u divert(0) After these updates are applied, make sure that sendmail delivers all mail for you domain to one account on the sendmail system. The sendmail configuration for that unified account should list the 'mailer' marked with the 'T' flag.
The following file can be used to force sendmail to store the envelope information in the messages headers.
After these updates are applied, make sure that sendmail delivers all mail for you domain to one account on the sendmail system. The sendmail configuration for that unified account should list the 'mailer' marked with the 'T' flag.