The Internet is flooded with soliciting E-mail messages distributed to millions of E-mail addresses. These messages are known as "spam".

Spammers fill your user mailboxes with a huge amount of unwanted messages, not only overloading the Internet and your Server resources, but making mail retrieval very slow and difficult for your users.

In order to distribute their messages to thousands and even millions of E-mail addresses, spammers try to use any SMTP mail server on the internet as a relay: they deliver one copy of the message to each mail server, requesting that the server then route it to a hundred addresses. This practice not only overloads your Server resources, but it places you at risk to be recognized as a spammer (since messages come from your server).

The CommuniGate Pro Server has Anti-Spam Options that can help you to deal with "spam". Use your browser to enter the Protection Settings page.

Verifying Return-Path Addresses

If your SMTP module can accept incoming TCP connections, your server can be used by spammers as a mail relay engine: they can distribute their messages all over the world using your server. 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.

When the Verify Return-Path option is selected in the SMTP Service Settings, the SMTP module parses the message Return-Path (Mail From) addresses, and the module refuses to receive a message if:

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 ERROR are rejected, so you can specify "bad" addresses and domains in the Router.

If you do not want to accept mail from any address in the domain, put the following line into the Router settings: = error
<*> = error
If you do not want to accept mail from all addresses starting with "promo" in the domain, put the following line into the Router settings:
<promo*> = 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.

Blacklisting Offenders

Since your SMTP module can accept incoming TCP connections, your server can be used by spammers as a mail relay engine: they can distribute their messages all over the world using your server. They can also send a lot of soliciting messages to your clients. To protect your site from known spammer sites, you can place the IP addresses of the offending hosts into the Black List.

When a host with an address that is included in the Black List 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.

Enter the IP addresses of offending hosts in the BlackList field.

Each line can contain either one address in the form:
or a range of addresses in the form:
Blacklisted IP Addresses

A comment can be placed at the end of a line. Use the semicolon (;) symbol to start a comment. A line starting with the semicolon symbol is a comment line.

Using DNS-based Blacklisting (RBL)

It is difficult to keep the Server "blacklist" current. So-called RBL (Realtime 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 option and enter the exact domain name (not  the IP address!) of the RBL server server. Now, when the SMTP module accepts a connection from an IP address aaa.bbb.ccc.ddd and this address is not listed in the Blacklisted and Client Addresses lists, the module composes a fictitious domain 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, then the aaa.bbb.ccc.ddd address is considered to be blacklisted.

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

Use Blacklisting DNS

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 wnat 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.

Prohibiting Unauthorized Relaying

If your SMTP module can accept incoming TCP connections, your server can be used by spammers as a mail relay engine: they can distribute their messages all over the world using your server. To protect your site from spammers, the system can restrict its relaying functionality.

Fill the Client IP Addresses field with the IP addresses on your LAN, as well as IP addresses of other systems that should be allowed to use your server as a mail relay.

If you are an ISP and your mail server is used as a back-up mail server and/or as a forwarding mail server for your client systems, enter the IP addresses of your client servers as well.

If you have dial-up users, enter the range of the IP addresses they use into this field.

Client IP Addresses
Grant Access to Clients Only

A comment can be placed at the end of a line. Use the semicolon (;) symbol to start a comment. A line starting with the semicolon symbol is a comment line.

Now, when a message is received with the SMTP module via TCP/IP, and the sender IP address is not found in the Client Addresses list, the message is marked as being received "from a stranger". If this message should be relayed by your server to some other host on the Internet, and that host is not listed in the list either, the message is rejected.

As a result, servers and workstations included into the Client Addresses list can use your Server to send (relay) messages to anybody on the Internet, and any message from the Internet can be relayed to any listed address. But any message coming from an unlisted system and directed to some other unlisted system will be rejected. This will prohibit spammers from using your Server as a mail relay.

Since this functionality can affect your legitimate users if you do not specify their IP addresses correctly, the Relay for Clients Only option is available in the SMTP Service Settings. The "stranger-to-stranger" messages are rejected only if this option is selected.

If you do not plan to support mobile users, you may want to check the Grant Access to Clients Only option to disable access to your Server from outside the network(s) specified in the Client IP Addresses table. Read the Security section before enabling this option.

Relaying Rerouted Messages

If you place an alias record into the Router table:

NoRelay:<user> =
then all mail from strangers to that user will be rerouted to that server. If that server address is not included into the Client IP Addresses list, these messages will be treated as messages "from a stranger to a stranger", and they will be rejected if the Relay for Clients Only option is switched on. To enable relaying, use the Relay: prefix or just use a record without any prefix:
Relay:<user> =
<user> =
When an addressed is being converted with such a record, it gets a marker that allows the server to relay messages to that address. If an addressed is processing modified with a record that has the NoRelay: prefix, this marker is not set. Please note that if the marker is just not set, but if it has been set with some other record, it is NOT reset (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), and that host address is not included into the Client IP Addresses list. =
Relay:<*> =

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 routing. This is 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 and that other host.

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

RelayAll:<report-*> = report-*

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 to be sent via a particular relay, you should place the following record into the Router table: =
Without the NoRelay prefix, any host on the Internet could send messages to via your Server. The NoRelay prefix tells the server not to add marker to addresses in the domain, so only your own users can send mail to domain using your Server.

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

<joe> =
This record tells the server to reroute all mail addressed to to Since this record has the (default) Relay: prefix, anybody in the world can send messages to and those messages will be successfully relayed the domain. The address will be then converted to and sent via host: the second address transition does not add the "can relay" marker, but it does not reset the "can relay" marker set during the first transition:
Operation AppliedAddressMarker
Received (Original) addressjoe@mydomain.comNO
Main Domain ( cut-off:joeNO
Router Record:
<joe> =
Router Record: =
SMTP Module:
accepted for the host

Relay Restrictions and Mobile Users

If some of your users travel a lot, they may use various ISPs to connect to the Internet, and as a result they will connect to your Server from various IP addresses. If those users use your Server as the SMTP mail relay to which they submit all outgoing messages, Relay Restrictions will not allow them to send messages when their IP addresses are not listed in the Client Addresses list.

More and more E-mail clients now support the SMTP Authentication - a draft standard that allows a mail client to authenticate the sender. If the SMTP module receives a message from a client that has authenticated itself, the message is marked as being "submitted from a local account", and this message can be relayed to any host.

To allow mobile users that have older mailer applications (those not supporting SMTP Authentication), to send messages via the CommuniGate Pro server, the POP and IMAP modules check if an authenticated user has connected from an IP address not included into the Client Addresses list. During that POP/IMAP session, and for some time after the session is closed, that IP addresses is considered to be a "Client Address", so that users can send mail via your Server right AFTER they have checked their mailboxes.

Non-Client IP Addresses
When used by an Authenticated User:
Process as a Client Address for: after the user disconnects
Remember up to: such addresses

The expiration time is used because of the "dynamic IP address" policies of most ISPs: when a user disconnects from an ISP modem, and some other user connects to the Internet via the same ISP, the same IP address can be assigned to the new user.

Inform your users about the expiration time. They should compose all their messages off-line, then they should connect to the Internet using any ISP, check their mailbox on your Server, and only then they can send the queued outgoing messages. If they want to reply to some messages they have just retrieved from the mailbox on your Server, they should use the Get Mail command in their mailer application again, and only then can they send their replies.

Since many mailer applications try to send queued messages first, the SMTP module checks the Return-Path (the address in the Mail From SMTP protocol command). If that address is an address of a registered user, a to-be-relayed message is not rejected with the "permanent failure" error code. Instead, a "temporary failure" code is returned (with the "try to authenticate first" comment). Many mailers do not interrupt the mail session when they receive such a code, and continue by authenticating the user, retrieving the user mail, and retrying to send the queued messages. The queued messages will be accepted this time, because the user is authenticated from the same address.

An SMTP (message submit) session should start either during a POP or IMAP session, or within the expiration time after the end of the POP/IMAP session. An SMTP session can then last as long as needed - several hours, if queued messages are large and the link is slow.

Note: support for the mobile users can be disabled on per-account and per-domain basis by disabling the Mobile 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 not be able to connect to that account from an internet address not included into the Client IP Addresses list.

Note: mail relaying for the 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. If this service is disabled, neither the connection IP address is remembered, nor SMTP Authentication will allow those users to relay messages via your Server. This 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 would be forced to submit messages using the WebUser Interface or any other non-SMTP methods).

Spam Traps

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
<> = spamtrap

You do not have to create fictitious accounts, you should create the Router alias records only.

Then you should do your best to help these addresses (, 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.

Filtering Mail

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 an empty string in their To: header fields:


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.

CommuniGate® Pro Guide. Copyright © 1998-2000, Stalker Software, Inc.