From the Help:
Controlling relaying
SMTP relaying was originally the standard method of propagating mail on the Internet: in normal operation, an SMTP host would accept any message destined for any user, even if that user was not a local user on the system: after it had accepted the message, it would relay it to the correct host for delivery. Mail agents like Pegasus Mail and Outlook) routinely depend on relaying to send mail - in essence, a smaller client (Pegasus Mail or Outlook) is asking a larger implementation (in this case, Mercury) to send the mail on its behalf.
In recent years, relaying has been abused by perpetrators of mass unsolicited commercial e-mail (or "spam"), and many sites wish to control the way relaying is managed. Mercury provides two anti-relaying modes, normal and strict. Normal mode is turned on by checking the control labelled "Do not permit SMTP relaying of non-local mail". Strict mode is turned on by also checking the control labelled "Use strict local relaying restrictions". The default mode is Normal relaying control, although this can be overridden during installation and at any later time.
In either mode, Mercury will always accept mail addressed to any local address. Similarly, mail to any address for which Mercury holds an alias will also be accepted, even if the alias resolves to a non-local address. Both modes can be overridden by an optional requirement for SMTP authentication (see below for more information).
In normal anti-relaying mode, Mercury will accept mail for delivery if either the recipient or the originator has a local e-mail address. If neither address is local, Mercury will compare the IP address of the connecting host to its connection control list (see above): if it finds an "allow" entry in that list that explicitly includes the connecting machine, then it will accept the mail, otherwise it will be failed with a diagnostic like "553 - We do not relay...".
In strict anti-relaying mode, Mercury follows the normal rules described above, but if the "From" address appears to be local, then Mercury will search the connection control list and will only accept the mail if an "allow" entry appears that explicitly permits the connecting host. Note that enabling strict mode automatically checks and disables the normal mode button as well.
The difference between the two modes is that normal mode requires less setup and maintenance, but is less secure, while strict mode practically guarantees that no unauthorised relaying can occur at the expense of having to manage a list of permitted relay hosts.
When you configure Mercury to operate in strict mode, you must ensure that you add "allow" entries to your connection control list for every machine that is to be permitted to relay mail via this copy of Mercury. Note that this does NOT mean that you have to enter the address of every machine from which you want to accept mail - mail to local recipients is always accepted, regardless of the relaying mode. Strict mode only requires "allow" entries for machines from which Mercury is to accept mail to be delivered to non-local addresses. Please note that this use of the allow/refuse list is an overload - that is, it means that the allow/refuse list is being used for two separate purposes, connection control and relaying control. This overloading is possible because relay control only uses allow entries, and any host that can relay from your machine is by definition also allowed to connect to it. You should never use refuse entries to handle relay control - only allow entries.
It is almost always safe to turn on normal anti-relaying mode.
Authenticated SMTP
Mercury supports an Internet standard called Authenticated SMTP: when this feature is enabled, Mercury will advertise to connecting clients that it can accept SMTP authentication. If a client then authenticates correctly, it will be allowed to relay. Pegasus Mail and other widely-used Internet mail clients support authenticated SMTP, and it is an excellent way of allowing your roving users to use your server without opening yourself to relay abuse. Mercury supports three Authentication methods - CRAM-MD5, PLAIN and LOGIN, although LOGIN and PLAIN are very weak and you should avoid clients that use them.
Authenticated SMTP requires that both the client and server have access to a common password. For that reason, you need to provide Mercury with a list of usernames and the passwords that correspond to them - Mercury typically cannot get this information from the operating system for security reasons. 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.
Important note: There is nothing that requires you to have a different SMTP Authentication password for every user on your system, nor is there anything that says that your SMTP Authentication username has to match any real user on your system. If you wish, it is perfectly permissible for you to set up a single AUTH username/password pair and provide it to all your users, although clearly this will have some ramifications for security.
If you check the control marked Authenticated SMTP connections may relay mail, then any authenticated connection (one where the user has provided any valid username/password pair defined in your SMTP Authentication file) 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 marked Only Authenticated SMTP connections may relay mail, then SMTP authentication becomes mandatory for relaying - a non-authenticated connection will not be permitted to relay mail even if it would otherwise have been permitted to do so by either the normal or strict relaying tests. Because this option supersedes all other tests, selecting it will check and disable the other three controls in the group.