 |
Protection |
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
In order to distribute their messages to 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 server to route the message to several hundred addresses. This practice not only overloads your Server resources, but it places you at risk of being recognized as a spammer (since "spam" messages come from your Server).
The CommuniGate Pro Server has Anti-Spam Options that can help you to deal with "spam".
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 as an open relay.
To protect your site from spammers, you should restrict the Server relaying functionality. Basically, only your own users should be able to use your Server to relay mail to other places on the Internet. Messages coming from other sources should go only to your own Accounts, and should be relayed to other Internet sites only when you explicitly allowed that type of relaying.
The simplest way to decide if an incoming SMTP message is coming from your own user is to look at the network (IP) address it is coming from. If all your users connnect from one or several LAN(s), you can treat all messages coming from those networks as "messages from Clients", and your Server will relay them to the Internet.
Use the WebAdmin Interface to open the Network pages inside the Settings section (realm), and click the Client IP Addresses link.
Enter the IP addresses on your client connect from, as well as the IP addresses of other systems that should be allowed to use your server as a mail relay:
The IP addresses are specified in a multi-line format. See the System Administrator section for more details.
If you provide dial-up services, enter the IP address ranges you have allocated to your dial-up users.
You can specify your Client IP Addresses using the reverse lookup domain names.
When a client connects from an IP address not listed in the Client IP Addresses list, and the Detect Clients 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.dd.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 windcard (*) symbols). If the retrieved name matches one of the table strings, the server retrievs the DNS A record for the retrieved domain name, and checks that the IP address is included into the IP addresses in that record. If it is included, the address is considered to be a "Client IP Address", and it is processed in the same way as if it was entered into the Client IP Addresses list.
Note: while this method was popular with legacy mail servers, it can be very expensive for large-scale systems. It requires the server to make 2 DNS trasactions for each incoming connection not coming from explicitly specified Client IP Addresses, and these transactions can take a lot of time. Use this method only when absolutely necessary, for example when your server needs to support a large (and unknown) set of campus networks, and the only thing known about those networks is the fact that all their IP addresses can be "reversed-resolved" into some subdomain of the school domain. Even in this case, try to enter all known addresses and networks into the Client IP Addresses list, decreasing the number of required "reverse-resolving" operations.
When a message is received with the SMTP module, 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 Client IP Addresses list either, the message can be rejected.
As a result, servers and workstations included into the Client Addresses list can use your Server to send (relay) messages to any mail server on the Internet. But any message coming from an unlisted address and directed to some other unlisted system can be rejected. This will prohibit spammers from using your Server as an "open mail relay".
Since this functionality can affect your legitimate users if you do
not specify their IP addresses correctly, the Relay to non-Clients option
is available on the SMTP Settings page.
Set that option to "if received from Clients", and
"stranger-to-stranger" relay attempts will be rejected.
The Client IP Addresses list can include addresses of some other mail servers. The Server can relay mail sent by anybody and addressed to a server with a network address included into the Client IP Addresses list, but it can also check if the message address is a "simple" one.
On the SMTP Settings page you can set the Relay to Clients option. Set this option to "to simple addresses" to prohibit relaying of "complex addresses" (such as username%somehost@otherserver) to servers listed in the Client IP Addresses list. This setting will prevent spammers from using your servers for "two-server relays".
When the "two-server relay" method is used:
To avoid problems with old mail servers that ignore the quote marks in addresses, the addresses with the local part containing quotes cannot be relayed to Client IP Addresses servers if the "simple" option is selected.
If the Relay to Client IP Addresses option is set to "no", these addresses are not processed in any special way - messages sent to servers with Client IP Addresses are processed in the same way as messages sent to servers with non-Client IP Addresses.
If you do not plan to support mobile users, you may want to select the Reject all Logins from from Non-Client IP Addresses option to allow any type of "login" operations from the Client IP Addresses only. Connections from other addresses are accepted, but only the services that do not require "login" operations will be available: SMTP mail transfer, Personal File Sites, public Mailing List browsing, etc.
Note: Please check that your Client IP Addresses field is filled with your client addresses and read the Security section before you select this option.
You should not select the Reject all Logins from from Non-Client IP Addresses option if you want to support mobile users. Select the Allow Mobile Users to Login option instead.
Many E-mail clients (including Microsoft Outlook Express, Netscape Messenger, Qualcomm Eudora, and many others) now support "SMTP AUTH" - the standard SMTP Authentication method that allows a mailer to authenticate the user (the sender). If the SMTP module receives a message from an authenticated user, the message is marked as being "submitted from a local account", and this message can be relayed to the Internet.
To allow mobile users with older mailer applications (those not supporting SMTP AUTH) to send messages via the CommuniGate Pro server, the POP, IMAP, and other "access-type" modules check if an authenticated user has connected from an IP address not listed as one of the Client Addresses. During that POP/IMAP session, and for some time after the session is closed, that IP address is considered to be a "Client Address", so that users can send mail via your Server right AFTER they have checked their mailboxes.
The expiration time is used because of the "dynamic IP address" policies of most ISPs: when a user disconnects from an ISP modem pool, and some other user connects to the Internet via the same ISP, the same IP address can be assigned to that other 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. Then that SMTP session can last as long as needed (several hours), if the queued messages are large and the link is slow.
Support for 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.
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. If a user or a domain has this service disabled, the IP address from which they log in are not remembered as "temporary client IP addresses", and the SMTP Authentication will not allow those users to relay messages via your SMTP module. 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).
The SMTP module parses the message Return-Path (Mail From) addresses and rejects it if:
When the Verify HELO and Return-Path option is selected in the SMTP Service Settings, the SMTP module refuses to receive a message if:
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 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.
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.
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.
Use the WebAdmin Interface to open the Network pages inside the Settings section (realm), and click the Blacklisted IP Addresses link.
Enter the IP addresses of offending hosts in the Blacklisted IP Addresses field:
Each line can contain either one address:
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.
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. 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, Unblacklistable, or Client Addresses lists, the module composes a fictitious domain name ddd.ccc.bbb.aaa.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 aaa.bbb.ccc.ddd 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.
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.
When a client connects from a network address not listed in the Client IP Addresses and 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.dd.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 windcard (*) symbols). If the retrieved name matches one of the table strings, the address is processed as a blacklisted one.
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:
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:
Note:Addresses listed in your Client IP Addresses list are never checked using any Blacklisting method, so there is no reason to include the Client IP Addresses into the UnBlacklistable IP Addresses table once again.
You can "unblacklist" addresses using their DNS (PTR) names:
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.
The Header field string can contain the following macro combinations:
Use the Test Address panel located on the Client IP Addresses and Blacklisted IP Addresses pages:
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:
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
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 (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.
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 page in the Settings section of the WebAdmin Interace, and click the RFC822 Receiver link.
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.
For example, the following Rule can be used to reject all messages that have a missing or empty To: and/or Cc: 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.
If you place an alias record into the Router table:
NoRelay:<user> = user@other.hostthen all mail from strangers to that user will be rerouted to that other.host 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@other.hostWhen 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).
<user> = user@other.host
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: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.viaWithout 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:
<joe> = joe5@bigprovdier.comThis record tells the server to reroute all mail addressed to joe@mydomain.com to joe5@bigprovdier.com. Since this record has the (default) Relay: prefix, anybody in the world can send messages to joe@mydomain.com and those messages 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: <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 Module: accepted for the host relay3.com | joe5@bigprovdier.com | YES |
The cluster-wide Address Tables (Client IP Addresses, Blacklisted IP Addresses, Unblacklistable IP Addresses) are processed as extenstions 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 IP domains" (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 "blacklisted IP domains" (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.
