next up previous contents
Next: Preventing Spam Mail Up: Smart Blocking Previous: Setting Up Internal Static

Setting Up Mail

The CEQURUX Firewall, like most firewalls, can hide the names of internal hosts in mail sender and recipient headers. The mail addresses of your users then have the form user@domain. In this case all mail user names must be unique - you cannot rely on both a user name and a host name to identify a particular recipient.

For example, if you have a user fred on machine fredsun, and a different user fred on machine fredmac, at least one of these users will have to change their user ID, as the outside world will see both as fred@domain, and the firewall will have no way of deciding which of the two Freds a mail message should be routed to.

A related implication is that the firewall cannot tell from an incoming mail message which host the message is destined for. This mail destination resolution problem can be handled in several ways:

One last factor to consider when configuring the mail service is whether to use an external `smart host'. This is a host which acts as an external mail server; rather than having the firewall deliver mail directly to different hosts on the Internet, all mail is sent instead to the smart host, which forwards it on. Usually there should be no need to use a smart host, but there are two reasons why you might want to do this:

Disadvantages of using a smart host are that mail may take longer to be delivered to its final destination, and that your ISP may not approve of you spooling all your outgoing mail on their machine.

There are two main aspects to how the mail is handled: determining where it should be delivered, and rewriting the sender address in the envelope of outgoing messages. The firewall does each of these as follows:

Determining the destination

1.
If the mail is addressed to a user in the firewall's domain who is configured as a POP3 maildrop user, then store the mail in the user's maildrop on the firewall;
2.
Else if the destination user has a postbox entry, send the mail on to the associated postbox host or address.
3.
Else if the mail is addressed to someone outside of the local domain, send it to the smart host if one is configured, or to the mail exchanger for that address if there is no smart host.
4.
Otherwise, if the mail is addressed to a user at a pass-through host in the local domain, send it on to that host.
5.
Otherwise, send the mail to the mail server, if there is one, or bounce the mail message if there is no server specified.

Rewriting the sender address in outgoing mail

If the mail is from an external user, don't change the address. If it is from an internal user, domain-qualify it if this hasn't already been done, and remove the host name if address hiding is enabled and the host is not a pass-through host.

The firewall also supports `virtual mail domains'. That is, you can configure a list of domains (excluding the firewall's own domain) and associated servers. The firewall will then accept mail to users within those domains, and forward the mail to the server associated with the domain. This allows you to have multiple mail domains behind a single firewall.

In summary, to set up your mail, you need to know the following:

Once you have this information, configuration is straightforward. The basic mail configuration is done from the Mail Setup Screen, while the information needed by the firewall to determine how mail should be delivered is done from the Mail Delivery Rules Setup Screen. Virtual mail domains are set up from the Virtual Domain Setup Screen, described in Section 4.8.5.

The fields in the Mail Setup Screen (Figure 4.13) are:


  
Figure 4.13: The Mail Setup Screen
\includegraphics[width=14cm,height=10cm]{mailsetup.ps}

Disable Mail Subsystem
If this is set to YES, then the firewall will not accept mail from remote hosts (although it will still create and mail daily reports itself, but these must be destined to internal hosts). This is useful if your ISP acts as your mail server, and you retrieve mail from your ISP using POP. If the mail subsystem is disabled, you will be able to define a transparent TCP gateway for outgoing SMTP.

Seamless Mail
If this is set to YES, the the firewall will intercept all TCP connections to external SMTP servers and handle them itself. This allows you to deploy the firewall without needing to reconfigure internal MTAs. This is an alternative approach to the Seamless MX option available in the Name Service Setup Screen.

Maximum Mail Message Size
The maximum size mail message that will be accepted by the mail relayer. The toggle field afterwards allows you to specify whether the mail message should be rejected outright (in which case the remote may try to resend it), or whether the firewall should act as though the mail was accepted.

Maximum Mail Recipients
The maximum number of message recipients that will be accepted by the mail relayer. The toggle field on the right is the same as for the message size limits described above.

Keep Rejected Mail
Any messages that are rejected due to exceeding the maximum size or number of recipients, or due to suspicious mail headers, can either be deleted or retained, depending on this setting. If you specify YES then the messages will be moved to the directory /var/spool/post/reject. The contents of the directory are moved each day end to /var/spool/post/reject.old, and deleted the day following that, so these directories should be checked for mail problems on a regular basis.

Diskspace Low Water Mark
If a non-zero value is entered here, and the available disk space falls below this value (in megabytes), then no further mail will be accepted, until the free disk space exceeds the high water value. This can be used to prevent the disk from filling up if one of the network interfaces goes down temporarily.

Diskspace High Water Mark
This is used in conjunction with the low water mark, and specifies the amount of free disk space that must be available for mail to be re-enabled, after being disabled due to lack of space.

Accept Suspect Addresses
Normally, the firewall will examine mail messages for suspicious mail addresses, and if it finds any, reject the mail message (putting it in the /var/spool/post/reject directory). If you set this toggle to YES, the firewall will bypass this address checking.

Restrict Local Recipients
The firewall can reject mail recipients in incoming messages that do not match a set of strings describing the acceptable internal mail addresses by setting this to YES. The list of strings is configured by pressing F5.

Reject Spam Senders
The firewall can refuse to accept mail if the sender does not have a valid replyable address (namely, there are no Internet address or mail exchanger records for the host or domain that the sender claims to be in). This feature can be useful for filtering out unsolicited junk mail (known as `spam mail'), where the sender uses a fake address.

External Mail Relaying
This toggle field lets you specify whether your firewall should allow external users to relay mail for other external users via its own mail server. In almost every case this should be set to `None'. However, a few sites do have this requirement. The other choices are `Domain', which means that if the mail sender claims to be from the firewall's domain or one of its virtual domains, it will allow relaying, or `Any', which means anyone can use the firewall as a mail relay. Be warned that if you set this to something other than `None', you can be exploited by mail spammers who may redirect spam mail via your site.

Rather than enabling this option, you should rather make use of the `POP3 before SMTP' feature of the firewall. If a user on an external client host successfully retrieves mail using POP3 from the firewall, then they will be allowed to use the firewall as a mail relayer for the next thirty minutes.

Idle Timeout for Incoming Mail
This lets you specify how many minutes the firewall will wait before terminating an idle SMTP connection.

Look for New Mail
This lets you specify how frequently the firewall should look for new mail to be forwarded and attempt to deliver it. In most cases a one minute interval is a good value, unless you have a demand-dial PPP setup and want to reduce the number of calls.

Retry Deferred Mail
If a mail message cannot be sent for some reason, it may be bounced or discarded. However, if the reason for the failure was likely to be a transient problem, then the message will instead be deferred, and can be sent later. This field lets you specify how frequently the firewall should retry sending deferred mail messages.

Bounce Undelivered Mail
Lets you specify the number of days that the firewall will keep trying to deliver a deferred mail message before bouncing the message back to the sender.

Mail Daily Reports To
The firewall generates daily accounting and security reports. By default these are sent to the root user on the firewall, but you can have them sent to a different mail address by specifying one here.

Mail Cron Output To
The firewall uses the UNIX cron utility to schedule tasks for execution at regular intervals. The tasks are the daily, weekly and monthly administration scripts, and deferred mail queue processing. The output produced by these commands can be mailed to a user by specifying the mail address here. If you leave this field empty no mail messages will be sent.

The available keys are:

F1
Cancel any changes and return to the Main Setup Screen
F2
View or edit the internal mail recipient addresses to accept
F3
View or edit the mail recipient addresses to reject
F4
View or edit the mail host addresses to reject
F5
View or edit the mail delivery rules
F6
View or edit the spam mail filter setup
F7
View help
F8
Save any changes and return to the Main Setup Screen

 The fields in the Mail Delivery Rules Setup Screen (Figure 4.14) are:


  
Figure 4.14: The Mail Delivery Rules Setup Screen
\includegraphics[width=14cm,height=10cm]{delivery.ps}

Hide Internal Hostnames
Normally, the firewall will modify the mail addresses of users within your domain to a `canonical' form of user@domain. This is advisable if you have a mail server for your internal users, You can disable this feature if necessary, allowing mail to be routed between different hosts on the inside depending on the host names in the mail addresses.

Hide Received-From Headers
To make the firewall hide your internal host name information even more stringently, set this toggle to YES. This will cause the firewall to strip out any Received-From headers found in outgoing mail messages that were generated by mail programs on internal hosts adn make it appear that the mail originated on the firewall itself.

Obfuscate Message IDs
Each mail message has a unique identifier associated with it, which is specified in the Message-ID header. The message ID usually contains the name of the host on which the mail originated. If you do not want this information to be exposed to the outside enable this option. Message IDs of outgoing mail messages will then be replaced with a cryptographic hash of the original ID followed by the domain name.

Internal Mail Server
If you have an internal host that acts as a mail server for your internal network, and you want the firewall to relay incoming mail to that machine, specify its hostname here.

External Smart Host
You can set up an SMTP smart host to which all outgoing mail will be relayed. Normally this is not needed, but it can improve the security of your firewall.

Handling of Infected Mail Attachments
If you have the Sophos PLC anti-virus library installed, then you can have the firewall automatically scan e-mail attachments for viruses. This toggle field is used to enable such scanning, and to specify how infected attachments should be handled. There are three ways of handling infections, although these can be combined in the case of disinfection, as not all viruses can be disinfected. The three ways are notification (the recipient will simply be warned of the infection), deletion (the infected attachment will be removed), or disinfection (the virus will be removed). If disinfection is not possible, it is possible to select either deletion or notification as the fall-back action.

Mail messages that contain viruses will be wrapped up in a multi-part MIME message. The first part will be a report from the virus scanner as to what viruses were found and what action was taken. The second part will be the original mail message, with possible changes as a result of disinfections or deletions. The new message will be sent to the original recipient, with the sender being the postmaster on the firewall, and the subject being `Virus Alert'.

Hostname for Update Retrieval
If you want your Sophos AV software to be automatically updated, then you need to enter or check the hostname in this field.

Username for Update Retrieval
This field is used for specifying the username you use for fetching AV updates from Sophos' server.

Password for Update Retrieval
This field is used for specifying the password that was allocated to you by Sophos PLC for update retrieval.

The Sophos anti-virus library can be obtained from Sophos PLC directly. When you license this library you will be provided with a username and password for obtaining updates via the Internet. Enabling mail virus checking in this screen, and entering the appropriate username, hostname and password settings for your updates, will result in the firewall automatically obtaining and installing regular updates of the Sophos anti-virus software. The Sophos SAVI library will be updated monthly, and the associated IDE files will be updated daily.

The firewall can also fetch new IDE files almost immediately an alert message is issued by Sophos. For this feature to work, some person at your site needs to subscribe to the Sophos alert mailing list (see http://www.sophos.com/virusinfo/notifications). It doesn't matter which person at your site subscribes to the alert mailing list, provided that person receives email through the firewall. When an email alert message is received, the firewall will parse the message to determine the relevant file name, and will fetch the new IDE file.

The available keys in the Mail Delivery Rules Setup Screen are:

F1
Cancel changes and return to the Mail Setup Screen
F2
View or edit the list of user mail postboxes
F3
Set up the external additional mail exchange hosts for your domain
F4
View or edit the list of hosts which receive mail directly
F5
View or edit the list of users with POP3 mailboxes
F7
View help
F8
Save changes and return to the Mail Setup Screen

Mail postboxes are specified using the Mail Postbox Setup Screen (Figure 4.15). This screen has two columns: the left is for the user names, and the right is for the hosts to which mail for the users should be sent. Any mail received by the firewall addressed to `user@domain' will be delivered to `user@postboxhost'. You can enter multiple pages of postbox entries if needed. It is also acceptable to enter a full e-mail address as the host (but not as the user), in which case the user name will also be modified in the envelope.


  
Figure 4.15: The Postbox Setup Screen
\includegraphics[width=14cm,height=10cm]{pboxsetup.ps}


  
Figure 4.16: The POP3 Mail Users Setup Screen
\includegraphics[width=14cm,height=10cm]{pop3users.ps}

POP3 mail users are specified using the POP3 Mail Users Setup Screen (Figure 4.16). This screen has two columns: the left is for the user names, and the right is for the users' passwords. Any mail received by the firewall addressed to `user@domain' will be stored in a mail folder on the firewall, and can be retrieved by the user using the POP3 protocol.

One or more POP3 TCP proxy service entries must be configured to allow mail to be retrieved, and it is thus possible to use strong authentication in addition to the POP3 passwords for controlling access. The POP3 TCP proxy entries should not specify relay servers (if they do, then the connections will be relayed onwards rather than being handled by the firewall itself).

You can also create POP3 entries for mail addresses in virtual mail domains. Mail for such addresses will be accepted by the firewall, and placed in maildrops with the fully domain-qualified address as the maildrop name. When retrieving the mail with POP3, the domain-qualified address must be given as the user name during the POP3 login.

Even if you have a mail server and are using mail addresses of the form `user@domain', you may find that you have certain hosts to which you want the firewall to deliver mail directly. For example, you may have separate departments each with their own mail server, rather than a single mail server. The Mail Pass-Through Hosts Setup Screen (Figure 4.17) lets you set up a list of host names of internal hosts that can send and receive mail from the firewall directly, and whose names should not be removed from outgoing mail addresses.


  
Figure 4.17: The Mail Pass Through Hosts Setup Screen
\includegraphics[width=14cm,height=10cm]{passthrusetup.ps}

 


  
Figure 4.18: The Reject Mail Recipients Setup Screen
\includegraphics[width=14cm,height=10cm]{badrecipsetup.ps}

You can also have the mail system reject particular recipient addresses, or disallow any incoming mail from particular hosts. The former is done using the Reject Mail Recipients Setup Screen (Figure 4.18), while the latter is done using the Accept Mail Recipients Setup Screen.

You can use this feature to reject mail to users who no longer exist at your site, for example. Each field allows you to specify a string, which, if it matches the suffix of a recipient address, will cause the recipient address to be rejected. If the string does not contain an `@', it will be domain-qualified before the match is performed. If you want to match an exact address, rather than using suffix matching, then you should start the address with a caret `^ ' character.


  
Figure 4.19: The Reject Mail Hosts Setup Screen
\includegraphics[width=14cm,height=10cm]{badhostsetup.ps}

The Reject Mail Hosts Setup Screen (Figure 4.19) lets you specify the numeric addresses of hosts from which mail should not be accepted at all. You can use trailing zeroes in the address to block mail from entire networks.


  
Figure 4.20: The Accept Mail Recipients Setup Screen
\includegraphics[width=14cm,height=10cm]{goodrecipsetup.ps}

You can restrict the recipients that will be accepted in mail messages received from external hosts, by editing the list of acceptable recipients in the Accept Mail Recipients Setup Screen (Figure 4.20). You can use this feature to accept mail to only certain user names at your site, for example. Each field allows you to specify an address which will be accepted. You can omit the user name to accept all mail addressed to a particular host or domain.

The matching algorithm used is the same as for rejected recipients. If a match is not found with one of the acceptable recipients, the firewall will reject the recipient. If you don't want any such rejecting, then you should disable this feature by setting the `Restrict Local Recipients' flag in the Mail Setup Screen to `NO'.

POP3 users and users with mail postboxes are implicitly considered acceptable recipients, so you do not need to re-enter them in this screen.


next up previous contents
Next: Preventing Spam Mail Up: Smart Blocking Previous: Setting Up Internal Static
Copyright © 2004, CEQURUX Technologies