Page 72 - Mercury Manual.book

67 The MercuryS SMTP Server Module
Compliance options

header, you must include the keyword (for example, "X-Blocked"), the colon character
(":") and the parameter text. Tagging a message in this way allows your users to take
advantage of the mail filtering capabilities of their mail packages to handle blacklisted
mail in the way they feel is best.

• Redirect (forward) the message to another address When this option is selected, Mer-
cury will accept the message normally, but will ignore the recipients specified for it,
instead sending it to the address you supply. The address you supply can be any valid
local user or Internet address. Mercury also adds an X-Blocked:
<definition_name> header to the redirected message.

• Drop and short-term blacklist the connection When this option is selected, MercuryS
will immediately terminate the connection with the client and will add the client’s
address to an internal Short Term Blacklist, which will prevent the client from even con-
necting for the next 30 minutes. This option is very useful if you are being hit repeatedly
by “spam zombies”.

Disable this definition (do not use it to perform queries) Check this control if you want to
prevent MercuryS from using the definition without actually removing it.

MercuryS's blacklist Definitions are stored in a single file called MS_SPAM.MER in the direc-
tory where Mercury is installed. You should not normally attempt to edit or otherwise modify
this file manually.

Compliance options

MercuryS allows you to perform a number of checks on messages as they are received, and
to reject messages if any of those checks fails. The types of test can be broadly divided into
those that examine the way the SMTP protocol is being used, and those that do basic inspec-
tion of the message data. While many of the checks that MercuryS can do can also be done
in other places within the Mercury system (especially using filtering or content control) the
advantage of doing them at the protocol level is that it prevents non-compliant messages from
even entering the Mercury processing queue, thus cutting down the time Mercury wastes
processing messages you almost certainly don't want anyway.

Restrictions to apply at the transaction level
These restrictions examine aspects of the way the connecting client is using the SMTP pro-
tocol (the "language" that two mail programs use when talking to each other to exchange mail
- covered in the Internet standards document RFC2821, available from http://
www.ietf.org).

Require clients to use an ESMTP "Size" declaration If you check this control, MercuryS will
only accept mail where the connected SMTP client declares the size of the message in ad-
vance, as part of the MAIL TO: command. Turning this on allows Mercury to enforce the
maximum size requirements you specify without ever actually having to receive the data, but
it may cause problems for some older clients that do not use the ESMTP size declaration ex-
tension. We recommend exercising caution when using this option, although it may be very
useful in some environments where a degree of "bulletproofing" is required.

Limit maximum number of failed RCPT commands to... An increasingly common technique
used by spammers to "harvest" valid addresses is to connect to an SMTP server and issue a
long list of RCPT TO: commands, building the recipient addresses using a dictionary of com-
mon usernames. If the server accepts the RCPT TO: command, the harvesting program can