DomainPOP Mail Collection
Using MDaemon's DomainPOP Mail Collection features.
Use DomainPOP Mail Collection (Setup DomainPOP…, or F8) to configure MDaemon to download mail from a remote POP mailbox for redistribution to your users. This feature works by using the POP protocol to download all the mail found in the ISP's POP mailbox associated with the specified logon. Once collected, the messages are parsed according to the settings provided on this dialog and then placed in user mailboxes or the remote mail queue for MDaemon to deliver, just as if the messages had arrived at the server using conventional SMTP transactions.
It is important to note that messages stored in POP mailboxes and retrieved using the POP protocol will be devoid of the important routing information (sometimes called the message's "envelope") that would ordinarily be supplied had the messages been delivered using the more powerful SMTP protocol. Without this routing information, MDaemon is forced to "read" the message and examine the headers in an attempt to determine to whom the message was originally intended. This is not an exact science to say the least. Message headers are sometimes notorious for their lack of sufficient information that is needed to determine the intended recipient. This lack of what would seem to be a fundamental characteristic of an email message - the recipient - may seem surprising but one must keep in mind that the message was never intended to be delivered to its recipient using the POP protocol. With SMTP, the contents of the message are irrelevant since the protocol itself dictates specifically to the server, during the mail transaction, the intended recipient of the message.
In order to allow for POP retrieval and delivery of mail messages in a reliable and consistent way, MDaemon employs a powerful suite of header processing options. When MDaemon downloads a message from a remote POP source it immediately parses all the relevant headers within that message and builds a collection of potential recipients. Every email address found in the headers that MDaemon inspects is included in the collection.
Once this process is complete, MDaemon's collection of recipients is divided into local and remote sets. Further, all addresses that are parsed and placed into the collection of potential recipients are processed through the Address Alias translator before being divided into local and remote sets. Every member of the local set (addresses with a domain that matches either MDaemon's Primary domain or one of the Secondary domains) will receive a copy of the message. What happens to the remote set is governed by the settings in this dialog. You can elect to simply ignore these addresses, forward a summary listing of them to the postmaster, or honor them-in which case MDaemon will actually deliver a copy of the message to the remote recipient. Only under rare circumstances would the need to deliver these messages to remote recipients be warranted.
Care must be taken to prevent duplicate messages or endlessly looping mail delivery cycles. A common problem that results from the loss of the SMTP envelope manifests itself with mailing list mail. Typically, messages distributed by a mailing list do not contain within the message body any reference to the addresses of the recipients. Rather, the list engine simply inserts the name of the mailing list into the TO: field. This presents an immediate problem: if the TO: field contains the name of the mailing list then the potential exists for MDaemon to download this message, parse the TO: field (which will yield the name of the mailing list), and then dispatch the message right back to the same list. This would in turn deliver another copy of the same message back to the POP mailbox from which MDaemon downloaded the original message-thus starting the whole cycle over again. To cope with such problems mail administrators must take care to use the tools and settings that MDaemon provides to either delete mailing list mail or perhaps alias it in such a way that it will be delivered to the proper local recipient(s). You could also utilize the Routing Rules or Content Filters to deliver the message to the correct recipient(s).
Additional concerns when employing this sort of mail collection scheme revolve around the issue of unwanted message duplication. It is very easy for mail that is delivered to the ISP's POP mailbox using SMTP to generate unwanted duplicates, once it has been collected using DomainPOP. For example, suppose a message is sent to someone at your domain and a carbon copy is sent to another person at the same domain. In this situation, SMTP will deliver two copies of the same message to your ISP's mailbox-one for each recipient. Each of the two message files will contain references to both recipients-one in the TO: field and the other in the CC: field. MDaemon will collect each of these two identical message files and parse both addresses from each of them. This would result in both recipients receiving one unwanted duplicate message. To guard against this sort of duplication MDaemon uses a control which allows you to specify a header that MDaemon will use to check for duplication. The Message-ID field is ideal for this. In the above example, both messages are identical and will therefore contain the same Message-ID field value. MDaemon can use this value to identify and remove the second message during the download stage before it can be parsed for address information.
As a final measure guarding against duplicate messages and endless looping delivery cycles, MDaemon employs a means for detecting how many trips or "hops" a message has made through the transport system. Each time an SMTP mail server processes a message it "stamps" the message with a "Received" header. MDaemon counts all such headers when it encounters a message for the first time. If the total number of mail servers exceeds a specified value, it is likely the message is caught in a delivery loop and should be taken out of the mail stream and moved to the bad message directory. This value can be configured through the Domain Configuration Editor.
DomainPOP Host Properties
Enable DomainPOP mail collection engine
If selected, MDaemon will use the setting provided on this screen to collect mail from a DomainPOP mail host for local redistribution.
Host name or IP
Enter your DomainPOP host's domain name here. Additionally, if you wish to specify a port to collect the mail from other than MDaemon's current default POP port, you can do so by appending a new port value to the host name separated by a colon. For example, using "mail.altn.com" as a DomainPOP host will connect to that host using the default outbound POP port while using "mail.altn.com:523" will connect to that host on port 523.
Logon name
Enter your logon of the POP account used by DomainPOP.
Password or APOP shared secret
Enter the POP account's password or APOP shared secret here.
Use APOP
Click this box if you wish to use the APOP command and CRAM-MD5 authentication when retrieving your mail. This makes it possible to authenticate yourself without having to send clear text passwords.
Mail Download Control
Leave a copy of message on host server
If selected, MDaemon will not remove collected messages from your DomainPOP mail host.
Delete messages once [xx] or more have accumulated (0 = no limit)
If you are leaving messages on your ISP server then they will be deleted once this number is reached. Enter "0" if you want messages to remain on the server regardless of the number.
Don't download messages larger than [xx] KB (0 = no limit)
Messages greater than or equal to this size will not be downloaded from your DomainPOP mail host. Enter "0" if you want MDaemon to download messages no matter the size.
Delete large messages from DomainPOP and MultiPOP hosts
Click this switch and MDaemon will delete messages that exceed your maximum set size. The messages will simply be removed from the DomainPOP and MultiPOP mail hosts and will not be downloaded.
Warn postmaster about large DomainPOP messages
Click this switch and MDaemon will send a warning to the postmaster whenever a large message is discovered in the DomainPOP mailbox.
Download messages according to size (small messages first)
Enable this checkbox if you want the message downloading order to be based on size-beginning with the smallest and proceeding to the largest.
Over Quota Accounts
Warn account holder and delete over quota message
When this option is chosen and a message is collected for an account that is over its quota (designated on the Quotas tab of the account editor), MDaemon will delete the message and send a warning to the user letting them know that their account is over its limit.
Warn account holder and forward over quota message to Postmaster
When this option is chosen and a message is collected for an account that is over its quota (designated on the Quotas tab of the account editor), MDaemon will forward the message to the Postmaster and send a warning to the user letting them know that their account is over its limit.
Parsing Properties
De-dupe collected mail using the Message-ID field
If this option is selected MDaemon will remember the value of the specified header and will not process additional messages collected in the same processing cycle which contain an identical value. The Message-ID field is the natural header to use but the actual header can be anything you want.
Parse "Received" headers for email addresses
This switch makes use of a powerful yet seldom used optional RFC-822 regulation. It is possible to store the recipient information ordinarily found only within the message's envelope in a message header so that parsers of the mail message will be able to glean the actual recipient address by merely inspecting the headers later. MDaemon will attempt to capitalize on this optional rule if you have this switch set by parsing ALL the "received" headers found within the mail message for valid addresses.
Skip over the first xx "Received" headers
Sometimes it is useful to process Received headers but starting at the nth occurrence of them. This setting allows you to enter the number of "Received" headers that MD will skip over before beginning its processing.
Stop parsing if "Received" yields a valid local address
If while parsing a "received" header MDaemon detects a valid local address, this switch will cause all further parsing to stop and MDaemon will not search the message for more potential delivery addresses.
Parse "Subject:" header for address inside "(" and ")" characters
When this is selected and MDaemon finds an address contained in "( )" in the "Subject:" header of a message, this address will be added to the message's list of recipients along with any other parsed addresses.
Parse these headers for email addresses
This control lists the headers that MDaemon will parse in an attempt to extract addresses. Every header listed here is checked for addresses.
Remove
This button will remove the selected entries from the header list.
Default
This button will clear the current contents of the header list and add MDaemon's default list of headers. The default headers are typically sufficient to extract all addresses from the message.
New header
Enter the header you wish to add to the header list.
Add
Add the header listed in the New Header control to the list.
Domain NameReplacement
Enable domain name replacement engine
This option is an attempt to cut down on the number of domain aliases your site will require. When a message is downloaded *all* domain names in *all* addresses which are parsed from that message are instantly transformed into the one specified here.
Ignore unknown local addresses parsed from messages
As mentioned above, the Domain Name Replacement feature will alter the domain name in all email addresses parsed from the message, converting it into the one you specify on this screen. This could create some addresses which do not have a corresponding mailbox account at your site. Since the domain name will match your primary domain name, MDaemon will consider such addresses local but undefined. Such mail typically generates a "No Such User" message directed at the postmaster. This switch will prevent the Domain Name Replacement Engine from generating "No Such User" messages.
Address Filtering
Always strip the following text from all parsed addresses
Some ISP's will stamp each message with a line that indicates who the recipient of the message should be along with a bit of routing information appended to the address on either the left or right hand side. This stamp would be perfect to use for parsing the recipient address except that the additional routing
DOMAINPOP MAIL COLLECTION
information makes this impossible without a lot of account aliasing. Rather than do all that you can simply specify the value of this appended text in the edit control associated with this feature and MDaemon will strip any occurrence of this text from all addresses that it parses.
Existing Rules
This list shows you the rules that you have created and will be applied to your messages.
Remove
Press this button and the selected rules in the Existing Rules list will be removed.
Default
Press this button to remove all existing rules and replace them with a predefined set of defaults.
Clear all
This button removes all existing rules.
New Rule
If the parsed address…
Is equal to, is not equal to, contains, does not contain
This is the type of comparison that will be made when an address is compared to this routing rule. MDaemon will search each address for the text contained in the "This text" field and then proceed based upon this control's setting-does the address's complete text match exactly, not match exactly, contain the text, or not contain it at all?
This text
Enter the text that you want MDaemon to search for when scanning the addresses.
Then do this with the message
This control lists the available actions that can be performed if the result of the rule is true. Here is a list of actions and what they do:
Don't deliver to this address - Selecting this rule will prevent the message from being delivered to the specified address.
Send to user or group of users -Selecting this action will bring up a dialog that will allow you to create a list of email addresses that should receive a copy of the message being processed.
What to do with non-local mail
Forward summary of non-local addresses to postmaster
If this option is selected MDaemon will send a single copy of the message to the postmaster along with a summary of the non-local addresses that the parsing engine extracted using the current set of headers and parsing rules.
Deliver non-local mail to all remote recipients
If this option is selected MDaemon will deliver a copy of the message to any non-local recipient that it finds within the inspected headers.
Do not deliver mail addressed to non-local addresses
If this option is selected MDaemon will remove from the recipient list any address that is non-local. It will be as if MDaemon never parsed remote addresses from the original downloaded message.
Safety Options
Place an extra copy of all downloaded mail into this directory
This is a safety feature to ensure that you don't lose any mail due to unforeseen parsing or other errors that might occur when downloading mail in bulk quantities.
Real Name Matching Engine
Activate real name matching engine
This feature allows MDaemon to determine who should receive a DomainPOP collected message based not upon what the email address is but upon what the text portion (typically a person's real name) is. For example, a message's TO header might read:
TO: "Joe User" <common-mailbox@isp.com>
or
TO: Joe User <common-mailbox@isp.com>
Name Matching does not care about the "common-mailbox@isp.com" portion of the address. It instead extracts the "Joe User" portion and attempts to lookup this name in the MDaemon user database. If a match is found to an account's real name field then that account's local email address is used for delivery purposes. If no match is made then MDaemon reverts to delivering the message to the email address parsed from the data (common-mailbox@isp.com in this example).
Only apply this feature if the address portion matches this value
This control allows you to specify an email address that must be present in the extracted data in order for the real name matching process to proceed. This allows you a measure of control over when the Name Matching feature will be employed. For example, you can specify an address such as "common-mailbox@isp.com" and then only addresses matching this value will be candidates for Name Matching.
Suppose you have "common-mailbox@isp.com" in this control.
This means that:
TO: "Joe User" <common-mailbox@isp.com> will be a candidate for Name Matching while TO: "Joe User" <Joe@mdaemon.com> will not.
