The SMTP Connection Policies build on the foundation of the Mail Relay Parameters. The policies are detailed rules about who will be served by the ZixGateway mail relay. The policies use keyword values.
The connection policies all have the same formatting requirements. These requirements are explained in:
SMTP Connection Policies are organized into:
Reject and Permit rules are always partial rules and should be anchored by a final reject or permit in the rule list.
Check rules always either accept or reject a message. They are complete in themselves and make good anchors for a rule list.
Examples - the following rule sets are all complete and well formed:
Optional, Defaulted
The SMTP Sender Restrictions policy is a fundamental access control for the ZixGateway appliance. It specifies a set of rules for whether the SMTP daemon (the first processing component of the mail relay) will accept or reject the message for further processing by the mail relay.
The Sender Restrictions parameter is a string of specialized keywords separated by commas. Each keyword represents an acceptance or rejection rule. The rules are processed in order from left-to-right. The first rule to specify a disposition for the message determines whether the message is accepted or rejected.
The Manager-default for this
parameter is
permit_mynetworks, reject_non_fqdn_sender, permit
ZixCorp recommends that you accept the
manager-default.
Note: To specify a policy, type the appropriate keywords in the Sender Restrictions field. Use care in selecting the rules. They must be complete and indicate a disposition for every possible message. The Manager-default above is a complete rule set:
In this case, the final permit rule is identical to the default behavior of the server, which would otherwise accept a message from any sender. When you specify it explicitly, you avoid having to remember and rely on the server-default that is being partially overridden.
Sender Restrictions Keyword | Explanation |
---|---|
permit_mynetworks |
Permit any message from a sender whose IP address matches an IP subnet in the Networks served by Mail Relay parameter. |
permit_sasl_authenticated | Permit the message if Simple Authentication and Security Layer (SASL) support is enabled. |
permit | Permit the message unconditionally. |
reject_non_fqdn_sender | Reject the message if the sender is not a FQDN. |
To add a Real Time Black List (RBL) to your ZixGateway appliance, you should add the keywords reject_rbl_client <blacklist address> into the Sender Restrictions field just before the permit statement. Enter as many comma separated reject_rbl_client <blacklist address> statements as necessary.
For example, your sender restrictions list can look like the following:
permit_mynetworks, reject_non_fqdn_sender, reject_rbl_client <blacklist address 1>, reject_rbl_client <blacklist address 2>, permit
Optional, Defaulted
The SMTP Recipient Restrictions parameter is the second and most comprehensive of the fundamental access control parameters. Logically, it tests each recipient of a message to see if the message is to be accepted or rejected as soon as it is presented to the SMTP daemon. In addition to its own unique Recipient Restrictions rules, it allows you to specify any rule that the Sender Restrictions and Hello Restrictions parameters allow.
Recipient Restrictions Keyword | Explanation |
---|---|
permit_mynetworks | Permit any message from a sender whose IP address matches an IP subnet in the Networks served by Mail Relay parameter. |
permit_sasl_authenticated | Permit the message if SASL support is enabled. |
reject_unauth_destination | Reject any message unless the recipient has a domain or subdomain listed in the Domain Name table. |
reject_unauth_pipelining | Reject any message that is sent to the mail relay from an unauthorized pipe. |
Optional, Defaulted
The ZixGateway appliance is very conservative in access control. It always requires an SMTP Hello (HELO) handshake with an email client that wants to drop a message into the mail relay’s email bag.
The Hello Restrictions parameter specifies the validation rules to apply to the HELO response that the email client provides.
Sender Restrictions Keyword | Explanation |
---|---|
permit | Permit the message unconditionally. |
reject_invalid_hostname | Reject the message if the HELO hostname is not syntactically well formed. |
One of the subtleties of setting the access control parameters is that the structure of your email stream determines how tight or loose you should set the rules.
If you choose to use the ZixGateway appliances as your primary mail relays, then they must be available to external mail relays in other organizations across the Internet. In this case, access control must be somewhat loose if they are to send you email.
If you choose to use ZixGateway primarily as an encryption/decryption filter, you probably have positioned other mail relays upstream and/or downstream of the ZixGateway appliances. In this case, you should significantly tighten the access control rules so that only these mail relays are allowed to send email to the ZixGateway appliances.