5.5 Controlling Who Can Send Email Through Your Server
MailMarshal includes a number of features that allow you to control acceptance of email messages. These include Reputation Service checking, PTR lookups, a list of blocked hosts, and authentication by account (user name and password).
5.5.1 Reputation Services and DNS Blocklists
MailMarshal can retrieve information from Reputation Services or DNS based blocklists including the Marshal IP Reputation Service, and third-party services such as SpamCop and SpamHaus. A Reputation Service is a service that provides an automated response through the DNS protocol. These services typically attempt to list email servers that are associated with spamming, open relays, or other unacceptable behavior. Each list has its own policies, and you should carefully evaluate the lists you choose to use.
|
Note: Reputation Services results are based on the IP address of a server, and currently provide information about IPv4 addresses only. |
The Marshal IP Reputation Service (provided by Trustwave) is automatically provisioned. You can configure details of other services in Policy Elements. You can configure one or more Connection Policy or Content Analysis Policy rules to filter email based on the list information.
|
Tip: Default policy for new installations includes an enabled Connection rule to use the Marshal IP Reputation Service. |
To minimize performance issues, use only one or two reliable services.
You can view the result returned by a Connection Policy rule Reputation Service condition by reviewing the MailMarshal Receiver text log.
5.5.1.2 Configuring Access to a Reputation Service
MailMarshal maintains a list of available reputation services it can use in Connection Policy rules.
To configure access to a reputation service:
1.In the Management Console, expand Policy Elements and select Reputation Services. The right pane shows a list of configured services.
|
Note: The Marshal IP Reputation Service will be automatically provisioned for use by trial installations and customers with current maintenance. Provisioning requires Internet access from the Array Manager server. |
2.You can edit or test a service entry or add a new entry. See Help for details of the required information.
5.5.1.3 Using a Reputation Service Rule
The default email policy provided with MailMarshal includes a Connection Policy rule that uses the Marshal IP Reputation Service (Trustwave Reputation Service). This policy is enabled by default.
To disable or re-enable the default Reputation Service rule:
1.Verify that the Marshal IP Reputation Service is present in the list of Reputation Services. This service is enabled by default in current versions of the product.
2.In the left pane, expand the item Email Policy.
3.Expand Connection Policy and double-click Connection Policies.
4.In the right pane, double-click the rule Deny Trustwave Reputation Service Blocklisted on connection. On the General tab, toggle the Enabled status, and then click Save.
5.Commit the configuration changes.
MailMarshal can mark or refuse email from external servers that do not have correctly published Reverse DNS (PTR record) information. You can use this method to help guarantee the genuineness of a remote site, and as a layer of anti-spoofing protection.
|
Note: Use PTR lookups with caution. Not all sites publish correct PTR information. Valid email traffic can be blocked by DNS checking if the sending site does not have PTR records, or if the records are faulty. If MailMarshal refuses a connection due to this policy, the connection is closed with the response: 554 no SMTP service here. |
To edit the PTR lookup policy:
1.In the Management Console, select System Configuration and then expand Receiver Properties.
2.Select Host Validation from the right pane menu.
3.To validate hosts sending incoming email using DNS information, toggle on Validate connecting hosts in the DNS. MailMarshal will perform a reverse DNS lookup on each IP address from which email is being sent.
4.Select an option using the radio buttons.
•Choose Accept unknown hosts to accept email from hosts without appropriate DNS information, but log this fact to the MailMarshal Receiver text log.
•Choose Host must have a PTR record to block messages from any host that does not have a valid DNS PTR record. Blocked messages are logged in the Windows Event Log and return the SMTP response: 554 No SMTP service here.
•Choose PTR Record must match the HELO connection string to block messages from hosts whose PTR domain does not match the HELO identification sent by the server. This is the most restrictive option. Blocked messages are logged in the Windows Event Log and return the SMTP response: 554 No SMTP service here.
5.To implement the blocking, click Save and then commit configuration.
You can maintain a list of servers that are never allowed to send any email through MailMarshal. MailMarshal will reject SMTP connections from these servers. Entries on this list will generally be servers outside your local LAN.
To edit the list of Blocked Hosts:
1.In the Management Console, select System Configuration and then expand Receiver Properties
2.Select Blocked Hosts from the right pane menu.
3.Toggle on Refuse Mail... and then add server names, IP addresses, or IP address ranges to the list. For information about the format of entries, see Help.
4.To implement the blocking, click Save and then commit the configuration.
5.5.4 Authentication by Account
MailMarshal can require each computer connecting to it to provide a user name and password. MailMarshal supports the CRAM-MD5, LOGIN, and PLAIN options for SMTP authentication. Additionally, authentication can be within a TLS session.
To use authentication by account:
1.Create and maintain a list of accounts using the policy element Accounts. For more information see “Setting Up Accounts”.
|
Note: You can also check authentication using an Active Directory group. For details of this option, see Trustwave Knowledge Base article Q16649. |
2.Configure MailMarshal to advertise ESMTP authentication. For more information see “MailMarshal Properties – Advanced”.
3.Create a Connection Policy rule using the condition “Where sender has authenticated”. For information about creating rules see “Understanding Rules”. For information about this rule condition see “Where sender has authenticated”.
|
Note: You can also check the authentication of messages using a Content Analysis Policy rule. For more information, see “Where the DKIM verification result is”. Using Content Analysis Policy to check authentication provides more flexibility in actions and other conditions, but could reduce security. |