Protection

Support for mobile users can be disabled on per-account and per-domain basis by disabling the Roaming option in the Enabled Services section on the Account Settings and Domain Settings pages. If this service is disabled for an Account, the Account user will able to connect only from the internet addresses included into the Client IP Addresses list.

Mail relaying for mobile users can be disabled on per-account and per-domain basis by disabling the Relay option in the Enabled Services section on the Account Settings and Domain Settings pages. This setup is useful when you give users Accounts on your Server, but you do not want them to be able to relay SMTP mail through your Server (they are forced to submit messages using the WebUser Interface or any other non-SMTP methods).

Since your SMTP module can accept incoming TCP connections, spammers can send a lot of unwanted messages to your users.

To protect your site from spammers, the SMTP module can verify the Return-Path address (specified with the Mail From SMTP command) of incoming messages.

The SMTP module parses the message Return-Path (Mail From) address and rejects it if:

• the Return-Path domain name is an empty string (no domain specified)
• the Return-Path address is routed (via the Server Router) to the ERROR address

When the Verify HELO and Return-Path option is selected in the SMTP Service Settings, the SMTP module refuses to receive a message if:

• the Return-Path domain name is specified as an IP address, and that address is not included into the Client Addresses list

If the connection comes from an address not included into the Client IP Addresses list, additional DNS verification checks are done, and the SMTP module rejects the Return-Path address if:

• the Domain Name System does not have MX or A records for the Return-Path domain (an unregistered domain)
• the Domain Name System has an MX record for the Return-Path domain, but it points to an A-record that does not exist (a faked domain)

The SMTP module uses the Router after it parses the Mail From address. If that address is an address of a local user, or the address is known (rerouted) with the Router, the Mail From address is accepted. This eliminates Domain Name System calls for the addresses "known" to the Server.

The addresses routed to the ERROR address are rejected, so you can specify "bad" addresses and domains in the Router.

Examples:

If you do not want to accept mail from any address in the offenderdomain.com domain, put the following line into the Router settings:
offenderdomain.com = error
or
<*@offenderdomain.com> = error

If you do not want to accept mail from all addresses starting with "promo" in the offenderdomain.com domain, put the following line into the Router settings:
<promo*@offenderdomain.com> = error

If the Return-Path domain cannot be verified because the Domain Name Server that keeps that domain records is not available, the module refuses to accept the message, but instead of a "permanent" error code the module returns a "temporary" error code to the sending system. The sending system will try again later.

You can tell the SMTP module to use SPF DNS records to check that messages with the specified Return-Path can come from the sender's network (IP) address.

You can tell the SMTP module to use the Reverse Connect method:

• the SMTP module makes a connection to the server that receives E-mail for this Return-Path address
• the SMTP module sends the Return-Path address to that server and checks the server response

If the server rejects this address, the SMTP module rejects the supplied Return-Path address, too.

To protect your system from known spammer sites, CommuniGate Pro provides several methods to maintain "black lists" of offending hosts IP addresses.

When a "blacklisted" host connects to your server and tries to submit a message via SMTP, it gets an error message from your SMTP module and mail from that host is not accepted.

Note: connections from "blacklisted" hosts are still accepted. If you want to reject all connections from the certain Network Addresses, see the Denied Addresses section.

Use the WebAdmin Interface to open the Network pages in the Settings realm, then open the Blacklisted IP Addresses page.

Specifying Offender Addresses

Enter the IP addresses of offending hosts in the Blacklisted IP Addresses field:

Blacklisted IP Addresses

10.34.56.78 ; bad host 10.34.50.01-10.34.59.99 ; bad network

Each line can contain either one address:

10.34.56.78

or an address range:

10.34.50.01-10.34.59.99

A comment can be placed at the end of a line, separated with the semicolon (;) symbol. A line starting with the semicolon symbol is a comment line, and it is ignored.

Using DNS-based Blacklisting (RBL)

It is difficult to keep the Server "blacklist" current. So-called RBL (Real-time Blackhole List) services can be used to check if an IP address is known as a source of spam.

Some ISPs have their own RBL servers running, but any RBL server known to have a decent blacklist can be used with your CommuniGate Pro server. Consult with your provider about the best RBL server available.

To use RBL servers, select the Use Blacklisting DNS Servers option and enter the exact domain name (not  the IP address!) of the RBL server. Now, when the SMTP module accepts a connection from an IP address aa.bb.cc.dd, and this address is not listed in the Blacklisted, Unblacklistable, or Client Addresses lists, the module composes a fictitious domain name dd.cc.bb.aa.rbl-server-name where rbl-server-name is the domain name of the RBL server you have specified.

The SMTP module then tries to "resolve" this name into an IP address. If this operation succeeds and the retrieved IP address is in the 127.0.0.2-127.1.255.255 range, then the aa.bb.cc.dd address is considered to be blacklisted.

Note: this option results in an additional DNS (Domain Name System) operation and it can cause delays in incoming connection processing.

Use Blacklisting DNS Servers (RBLs)

You can specify several RBL Servers using the last (empty) field in the RBL Server table. To remove a server from the list, enter an empty string into its field. The more servers you use, the larger the incoming connection processing delay. If you really need to use several RBL servers, but do no want those additional delays, make your own DNS server retrieve the RBL information from those servers (using daily zone updates) and use your own DNS server as an RBL server.

Note:An RBL server failure can cause very long delays for incoming connections. To avoid these situations, the requests to RBL servers are sent not more than twice, each time with the minimal time-out.

Blacklisting Domains by Name

When a client connects from a network address not listed in the Blacklisted IP Addresses lists, and the Blacklist by DNS Name option is enabled, the server tries to get the domain name for that IP address (if the IP address is aa.bb.cc.dd, the Server tries to retrieve the PTR record for the dd.cc.bb.aa.in-addr.arpa name).
If the PTR domain name is retrieved, it is checked against the strings specified in the table (these strings can include the wildcard (*) symbols). If the retrieved name matches one of the table strings, the address is processed as a blacklisted one.

Detect Blacklisted by DNS Name

Note: if the Blacklist by DNS Name option is enabled, the server has to make an additional reverse-lookup DNS operation (unless the Detect Clients by DNS Name has been already enabled). This additional DNS operation can cause additional delays when processing incoming SMTP connections, so enable this option only when needed, and only when you cannot specify all blacklisted addresses explicitly - in the Blacklisted IP Addresses list.

Note: if the reverse-lookup DNS operation fails, the server places the DNR error code into the container used to keep the reverse-lookup DNS operation results (DNS names). The error code is enclosed in parenthesis. To blacklist all network addresses that do not have reverse-DNS records, place the (host name is unknown) string into the Blacklist by DNS Name table:

Detect Blacklisted by DNS Name

Un-listing Addresses (White Hole Addresses)

When using RBL Servers or DNS Names for blacklisting, you may want to avoid blacklisting certain sites.

Enter those "unblacklistable" addresses using the same format you use for Blacklisted IP Address list:

UnBlacklistable (White Hole) IP Addresses

192.168.254.18 ; a good fellow, got into RBL by mistake

You can "unblacklist" addresses using their DNS (PTR) names:

Detect White Holes by DNS Name

Select the checkbox to enable this option and enter the DNS domain names you do not want to be blacklisted. This can be useful if some "good" addresses are blacklisted with the RBL services you use.

Note: The explicitly specified Blacklisted IP Addresses cannot be "unblacklisted" using the DNS Names.

Processing Messages from Blacklisted Addresses

You can modify the SMTP module reaction on messages coming from blacklisted IP addresses. Instead of rejecting them (by adding the @blacklisted suffix to all their recipient addresses), the module can accept those message, but add a specified Header field to each of them:

Messages from Blacklisted IP Addresses
Reject	Add Header:

The Header field string can contain the following macro combinations:

• ^0. This combination is replaced with the name of the RBL host blacklisting the address. If no RBL host was used, the combination is replaced with an empty string.
• ^1. This combination is replaced with the network address of the blacklisted host.

Temporarily Blocked Addresses

CommuniGate Pro maintains its own "temporary Blacklist". Network addresses in that list are blocked for a certain time period only.

Temporarily Blocked IP Addresses
Debug after:	157101530501003001000300010000other	and Block after:	15710153050100300300010000other failed Logins in 1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min40 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)10 hour(s)12 hour(s)24 hour(s)2 day(s)3 day(s)7 day(s)other
	357101530501003001000300010000other		357101530501003001000300010000other protocol errors in 1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min40 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)10 hour(s)12 hour(s)24 hour(s)2 day(s)3 day(s)7 day(s)other
Blocking Time:	0 sec1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min45 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)8 hour(s)10 hour(s)12 hour(s)24 hour(s)other	Blocked Addresses Limit:	1030100300100030001000030000other
Temporarily UnBlockable IP Addresses
UnBlocking Time:	0 sec1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min45 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)8 hour(s)10 hour(s)12 hour(s)24 hour(s)other	UnBlockable Addresses Limit:	1030100300100030001000030000other

IP Addresses can be put into Temporary Debug IP Addresses list or blocked when the Server detects some activity from those addresses that can be qualified as suspicious:

• too many protocol errors in SMTP receiving sessions (the number of errors is configured in the SMTP module)
• addresses routed to the spamtrap address in SMTP receiving sessions
• too many failed authentication (Login) attempts from the same address
• too many protocol errors (misformed packets) in the packet-based protocols, such as SIP.

Debug after and Block after

Use these settings to specify when a Network IP Address should be debugged or blocked:

failed Logins in

maximum frequency of failed Login attempts: if there are more failed Login attempts from some IP Address during the specified period of time, this IP Address is blocked.

protocol errors in

maximum frequency of protocol errors or misformed packets: if there are more misformed protocol packets from some IP Address during the specified period of time, this IP Address is blocked.

Blocking Time

Use this setting to specify for how long an IP Address should be blocked.

Blocked Addresses Limit

Use this setting to specify the maximum number of IP Addresses the Server can block.

Note: addresses included into the White Hole Addresses list are never placed into the Temporarily Blocked Addresses list.

Note: in a Dynamic Cluster environment only the Cluster-wide Temporarily Blocked Addresses settings are in effect.

Temporarily UnBlockable IP Addresses

The Temporarily UnBlockable IP Addresses are a temporary analogue of permanent White Hole Addresses.
An IP address becomes temporarily unblockable as a result of successful authentication made from that address.

UnBlocking Time

Use this setting to specify for how long an IP Address should be unblockable.

UnBlockable Addresses Limit

Use this setting to specify the maximum number of IP Addresses the Server can not block.

Your IP tables can become quite large, making it difficult to check if a particular network address is recognized by the Server as a Client one, or as a Blacklisted one.

Use the Test Address panel located on the Client IP Addresses and Blacklisted IP Addresses pages:

Test Address:

[10.0.1.89](host1.lan) is Trusted

Enter an IP address and click the Test button. The IP address status appears.

The status shows the IP address you have entered. It can have the Local prefix, if the address is the local address of your Server, or it can have the LAN prefix, if the address is included into LAN IP Addresses list.

The "reverse-resolved" name is displayed if the Server had to perform the "reverse-resolving" DNS operation to get the address status.

The address and optional name are followed by the address status:

Trusted

the IP address is a Client IP address.

TempTrusted

the IP address is processed as a Client IP address because some user (with the Relay Service enabled) has recently authenticated from that address.

Blacklisted

the IP address is blacklisted. If the address is blacklisted because it is included into some RBL, the name of that RBL server is displayed.

Regular

all other addresses.

You can protect your site from incoming spam by creating and advertising one or several "spam-trap" E-mail addresses. The CommuniGate Pro Router detects a special local address, spamtrap. If your server receives a message, and at least one of its recipients is spamtrap@yourhost or at least one of its recipients is routed to spamtrap, the Server rejects the entire message.

You may want to create one or several alias records for "nice-looking" fictitious E-mail addresses and route those addresses to spamtrap:

<misterX> = spamtrap
<johnsmith@subdomain.com> = spamtrap

Alternatively, you can create Forwarders pointing to the spamtrap address.

Then you should do your best to help these addresses (misterX@yoursite.com, johnsmith@subdomain.com) to get to the bulk mailing lists used by spammers. Since most of those lists are composed by robots scanning Web pages and Usenet newsgroups, place these fictitious addresses on Web pages and include them into the signatures used when you and your users post Usenet messages. To avoid confusion, make the fictitious E-mail addresses invisible for a human browsing your Web pages and/or attach a comment explaining the purpose of these addresses.

Many bulk mailing lists are sorted by the domain name, and as a result many spam messages come to your site addressed to several recipients. These recipients are the E-mail addresses in your domain(s) that became known to spammers. When the fictitious, "spam-trap" addresses make it to those databases, most of spam messages will have these addresses among the message recipients. This will allow the Server to reject the entire messages, and they will not be delivered to any real recipient on your site.

When at least one of the incoming message recipient addresses is routed to the spamtrap address, the entire message is rejected, and the IP Address of the sending server is placed into the Temporarily Blocked Addresses list, unless this IP Address is included into the Client IP Addresses or White Hole Addresses lists.

You can specify a set of message Header and Body lines to be used to detect spam. When the server receives mail in the RFC822 format (via SMTP, RPOLL, POP XTND XMIT, PIPE modules), it compares each received header and body line with the specified lists. If a message contains one of the specified lines, the message is rejected.

You can use the wildcard ('*', asterisk) symbols in the Banned Lines you specify. Usually you should not use them, since you are expected to compose the "banned" lists by copying header or body lines from the known spam messages.

Message lines are compared to the specified Banned lines in the case-sensitive mode.

Each Header line can include the end of line symbols if the header field was "wrapped".

If a message header or body is encoded (using MIME or UU encoding), the lines are not decoded before they are compared to the Banned line sets.

To specify the set of Banned Lines, open the Queue pages in the Settings realm of the WebAdmin Interface, and click the RFCReader link.

Banned Header Lines

Banned Body Lines

To add a new line, enter it in the empty field, and click the Update button.

To remove a line, delete it from its field, and click the Update button.

When a message is received with the Server, a set of Server-Wide Rules is applied. These Rules can be used to detect unwanted messages and reject, discard, or redirect them.

For example, the following Rule can be used to reject all messages that have a missing To: header field:

Data	Operation	Parameter
---Header Field	is not
Action	Parameter
---Reject with	Messages without To: fields are not accepted here

You can create various filtering rules using all features of CommuniGate Pro Automated Mail Processing, including external filter programs started with the Execute Rule Action.

Read this section if you need to provide special relaying features.

If you place an alias record into the Router table:

NoRelay:<user> = user@other.host

then all mail from strangers to that user will be rerouted to that other.host server. These messages will be treated as messages "from a stranger to a stranger", and they will be rejected.

To enable relaying, use the Relay: prefix:

Relay:<user> = user@other.host
<user> = user@other.host

When an address is being converted with such a record, it gets a marker that allows the server to relay messages to that address. If an address is modified with a record that has the NoRelay: prefix, this marker is not set, but it is not reset either - if it has has been set with some other Router record (see the example below).

The same situation exists if you want to reroute all mail for a certain domain to a different host (for example, if you back up that host).

Relay:clienthost.com = client1.com
Relay:<*@clienthost.com> = client1.com

When the address modified with the Router record is not a "simple address", i.e. it contains several routes, as in user%host1@host2, or <@host2:user@host1> - the Relay: prefix does not set the flag that allows message relaying. This is done because the host to which the rerouted message is relayed may "trust" all messages that come from your host, and relaying addresses with multiple routes would allow someone to relay messages to anybody through your host and that other host.

If the receiving server is well-protected, too, you may need a Router record that allows relaying of any address rerouted with that record. Use the RelayAll: prefix for those records:

RelayAll:<report-*@clienthost.com> = report-*@client1.com

Very often you do not want the Router records to be used for actual relaying - you provide them for your own clients only, to specify a special path for certain addresses/domains. For example, if you want mail to bigprovdier.com to be sent via a particular relay relay3.com, you should place the following record into the Router table:

NoRelay:bigprovdier.com = bigprovdier.com@relay3.com._via

Without the NoRelay prefix, any host on the Internet could send messages to bigprovdier.com via your Server. The NoRelay prefix tells the Router not to add marker to addresses in the bigprovdier.com domain, so only your own users (clients) can send mail to bigprovdier.com domain using your Server.

Note: you may have an alias record in your Router:

Relay:<joe> = joe5@bigprovdier.com

This record tells the server to reroute all mail addressed to joe@mydomain.com to joe5@bigprovdier.com. Since this record has the Relay: prefix, anybody in the world can send E-mail messages and Signals to joe@mydomain.com and they will be successfully relayed to the bigprovdier.com domain.
The joe5@bigprovdier.com address will be converted to joe5%bigprovdier.com@relay3.com._via and sent via relay3.com host: the second address transformation does not add the "can relay" marker, but it does not reset the "can relay" marker set during the first transformation:

Operation Applied	Address	Marker
Received (Original) address	joe@mydomain.com	NO
Main Domain (mydomain.com) cut-off:	joe	NO
Router Record: Relay:<joe> = joe5@bigprovdier.com	joe5@bigprovdier.com	YES
Router Record: NoRelay:bigprovdier.com = bigprovdier.com@relay3.com._via	joe5%bigprovdier.com@relay3.com._via	YES
SMTP/SIP Module: accepted for the host relay3.com	joe5@bigprovdier.com	YES

When a Server is a member of a Dynamic Cluster, the WebAdmin Network and Queue Settings pages provide links that allow you to switch between the local (server-wide) and the cluster-wide Settings.

The cluster-wide Address Tables (Client IP Addresses, Blacklisted IP Addresses, Unblacklistable IP Addresses) are processed as extensions of the server-wide tables: an address is considered to be listed if it is included into either the server-wide or into the cluster-wide table.

The cluster-wide "Client By DNS Name" list is processed as an extension of the individual server-wide list of "Client By DNS Name" domain names (if the Detect Clients by DNS Name option is enabled on the cluster-wide page).

The cluster-wide "Blacklist By DNS Name" list is processed as an extension of the individual server-wide list of "Blacklist By DNS Name" domain names (if the Blacklist by DNS Name option is enabled on the cluster-wide page).

The cluster-wide list of "Blacklisted" RBLs is processed as an extension of the individual server-wide RBL server lists. Each server will consult with the locally-specified RBL servers first, then it will consult with the RBL servers specified in the cluster-wide settings.

The cluster-wide "Banned" settings are processed as extensions of the server-wide settings: a message is banned if its header or body line is listed in the server-wide or in the cluster-wide settings.