15.4. Forwarding of entire domains

15.4.1. Method

For each domain, it is possible to forward emails to another mail or groupware server (e.g. Microsoft Exchange or Lotus Domino) and not to users of the Intra2net system. This forwarding is done after virus scanning, banned attachments and the global spam filter.

Forwarding can be configured for each domain under Services > Email > Domains : Forwarding.

It is possible to change the destination domain of the forwarded emails. For example, if you receive the domain example.com on the Intra2net system and specify Domain address change as xyz.com, the target addresses in all forwarded emails will be changed to ...@xyz.com. This is especially useful if you do not want to reconfigure a destination server.

15.4.2. Recipient Address Check

If an email cannot be delivered, the sender must be informed of this with a non-delivery message (Bounce). Of course, this also applies if the destination domain exists, but not the user. If spammers send a lot of emails to invalid recipients in a short time, this mechanism can result in 2 problems:

  • Each of these non-delivery messages must be delivered to the sender which results in additional load. Furthermore, many spam addresses are wrong and as a result a further non-delivery message (Double-Bounce) is generated from the other side, which increases the load further.

  • Some recipients consider non-delivery responses to emails that do not originate from themselves as spam. If there are too many of them in a short time, it can happen that the IP of the Intra2net system is added to a spam blacklist. As a result, many normal emails would no longer be delivered or end up in a recipient's spam folder.

These problems can be solved by preventing the Intra2net system from accepting emails with invalid recipients. In this case, the sending server is responsible for generating the non-delivery message, or in the case of a spam server, none at all.

If a domain is assigned to the Intra2net system, the system recognizes all valid recipient addresses and rejects invalid addresses immediately before receipt. No special configuration is required, as this is done automatically.

If, on the other hand, a domain is given to another server, only this server knows the valid addresses. In order to enable the Intra2net system to reject emails on receipt, there are two procedures described below.

15.4.2.1. Receiver address check via SMTP requests

Before an email is accepted, the Intra2net system asks the receiving server whether the address is valid. For the check, an SMTP connection to the target server is established and the target address is checked with the RCPT TO: command.

It is important that the receiving server responds in case of an invalid address with an error code in the range of 500 (e.g. 550 Recipient address rejected: User unknown). Many servers in the default configuration accept the address first and then send a non-delivery message later. For some servers, direct rejection can be activated by changing the settings. However, this is not possible with some server programs (such as Microsoft Exchange before version 2007). In this case, a recipient address check via SMTP cannot be used.

15.4.2.2. Recipient address check via Active Directory and LDAP

With this method, the Intra2net system regularly reads the list of all valid email addresses on an LDAP server (e.g. Active Directory). When an email is received, this list can be used to immediately determine whether the address is valid or not.

The Intra2net system requires a valid login on the LDAP server. The LDAP login (bind DN) is usually entered as a complete Distinguished Name (e.g. CN=username, CN=user, DC=mycompany, DC=local). However, many servers also accept a simple user login if it is located directly in the LDAP search base.

If you are using a standard domain without additional organizational elements or similar, you can enter the user login as an LDAP login for Microsoft Windows Server 2000 and 2003. For Microsoft Windows Server 2008, enter the user's first name and last name separated by a space. Both times the Intra2net system will automatically select the appropriate Distinguished Name.

[Caution]Caution

We strongly advise against using an account with administrative rights. The password has to be stored internally in plain text on the Intra2net system, which, in case of a successful attack on the Intra2net system, it could be used to compromise the LDAP server.

The LDAP search base is the starting point in searching for LDAP queries: A Distinguished Name (DN) of the root node of the subtree to be searched (e.g. DC=mycompany, DC=local for the active directory domain "mycompany.local").

If the LDAP server is an Active Directory, set the structure to Active Directory. If it is an LDAP server with systems other than Active Directory, you have to specify a search filter (e.g. (mail=*)) and the name of the result attribute (e.g. mail).

Immediately after the recipient address check has been configured, the Intra2net system will attempt to read the data via LDAP. This must be regularly carried out. The interval for this is set under Services > Email > Automatic.

15.4.2.2.1. LDAP paths on Windows servers

If you have trouble finding the appropriate LDAP paths for your Windows server, the following describes how to access this data.

  1. Open the management console for Active Directory Users and Computers. You will normally find them under Management.

  2. In the menu View activate the option Advanced Features.

  3. Right click the domain and open the Properties dialog.

  4. In the Attribute Editor tab, you will find the distinguishedName attribute. Enter this in the Intra2net system as the LDAP search basis.

  5. Close the domain's property view and locate the path of the user you want to use to retrieve the data.

  6. Right click the user and open the Properties dialog.

  7. In the Attribute Editor tab, you will find the distinguishedName attribute. Enter this in the Intra2net system as an LDAP login.

15.4.3. Forwarding of individual POP accounts

If you want to retrieve individual POP accounts and then forward the emails directly to another server, proceed as follows: Set up the retrieval as described under Section 15.3.2, „Retrieving individual POP accounts“. Forward at least one domain to the appropriate destination server. If you are not already forwarding a domain, set up an internally valid domain for this purpose only (e.g. net.lan).

Under Services > Email > Polling, do not select a local user of the Intra2net system as recipient, but enter an email address in the forwarded domain. The emails from the POP account will then be delivered to the entered address on the target server after the usual filters (viruses, attachments, spam).