Page 68 - Mercury Manual.book

63 The MercuryS SMTP Server Module
Authenticated SMTP

Authenticated SMTP

Mercury supports an Internet standard called Authenticated SMTP (RFC 2554): when this
feature is enabled, Mercury will advertise to connecting clients that it can accept SMTP au- It is very important to un-
thentication. If a client then authenticates correctly, it will be allowed to relay. Pegasus Mail derstand that SMTP au-
and other widely-used Internet mail clients support authenticated SMTP, and it is an excellent thentication does not
secure the connection -
way of allowing your roving users to use your server without opening yourself to relay abuse. the data is still unencrypt-
Mercury supports three Authentication methods - CRAM-MD5, PLAIN and LOGIN, although ed and can be intercepted
in transit.
PLAIN and LOGIN are very weak and you should avoid clients that use them if possible.

Authenticated SMTP requires that both the client and server have access to a common pass-
word. For that reason, you need to provide Mercury with a list of usernames and the pass-
words that correspond to them - Mercury typically cannot get this information from the
operating system. Enter the name of the file where Mercury should store the user/password
combinations, then click the Edit button to edit it. Each line contains one username/password
pair. For the purposes of SMTP authentication, there is nothing to stop you from assigning a
single username/password combination and giving that to all your users – most sensibly-writ-
ten mail clients will permit the user to enter specific SMTP authentication credentials rather
than depending on POP3 or other unrelated information. Using this kind of en masse author-
ization can greatly simplify the maintenance of your server.

If you check the control called Authenticated SMTP connections may relay mail, then any au-
thenticated connection will be permitted to relay messages even if it would otherwise have
been prevented from doing so by either the normal or strict relaying tests (see above).

If you check the control called Only Authenticated SMTP connections may relay mail, then
SMTP authentication becomes mandatory - a non-authenticated connection will not be per-
mitted to relay mail even if it would otherwise have been permitted to do so by either the nor-
mal or strict relaying tests. Because this option supersedes all other tests, selecting it will
disable the normal and strict controls in the dialog.

Spam control via Realtime Blacklists (RBLs)

SPAM, UCE, cruft – call it what you will, the fact remains that unsolicited commercial e-mail
is probably the single biggest problem facing the Internet at present: while clearly a social
and regulatory problem, legislators around the world – but particularly in the USA where
most of this stuff originates – have been incomprehensibly slow or reluctant to do anything
about it. As a result, we are left with trying to find technical solutions to the problem, but by
its very nature, it is not an area that lends itself to ready technical solution. Mercury/32 has
several powerful tools that will help you reduce the amount of unwanted clutter you get in
your mailbox; the first of these is via blacklist definitions, which allow you to tie into "black-
list databases", such as Paul Vixie's MAPS RBL, or the now-defunct ORBS open relay data-
base. These "blacklist databases" are essentially just Internet name servers that list either
machines or Internet domains that are known to be sources of unwanted mail.

When an incoming mail connection is made, a query-enabled server, such as Mercury, can
send a simple name server query to these databases to find out if the machine or the sender
of the incoming mail message is listed; if the blacklist database reports that it knows the ad-
dress or domain, then the server can take whatever action has been programmed for it, such
as rejecting the mail, or maybe quarantining it somewhere.