Mail relaying is the practice of sending mail to a remote mail host other than direct to the recipient host itself or to the host specified in the Domain Name System (DNS) by the MX resource records for the recipient address.
Until recently, most mail hosts on the Internet freely permitted relaying to ensure that the SMTP mail transport system could route around temporary losses of connectivity and other network related problems. However, unscrupulous junk mailers eventually learned to abuse that trust-based system by offloading their messages onto any mail service which offered them the opportunity of hiding the true origin of their messages. It is becoming exceedingly rare, therefore, to find a mail host which offers to accept mail for delivery to anything other than recipients which it regards as being local to itself.
Uncontrolled mail relaying places the viability of your own mail service at risk. If detected and placed on a black list, many mail destinations may refuse to accept mail directly from your host and may also refuse to deliver mail to your host. Further, whilst it is very easy to get on blacklists, getting removed from blacklists can be inordinately difficult, particularly where private schemes are involved. Consequently, understanding the concept of mail relaying is vital for all responsible Internet mail administrators.
If Mailtraq's configured Domain Name (or a Domain Alias) is example.com and a local SMTP client (that is a client whose IP address falls within its local LAN firewall) sends a message addressed to user@example.com, Mailtraq delivers the message locally and there is no relaying involved.
If, however, the message from that local client is addressed to a remote domain, for example user@foo.fastraq.com, Mailtraq relays the message onwards. That is an example of authorised relaying.
If a remote mail client (a client whose IP address falls outside Mailtraq's local LAN firewall) sends a message addressed to user@example.com, Mailtraq delivers the message locally and there is no relaying involved.
If, however, the message is addressed to a remote domain, user@foo.fastraq.com as in the first example, Mailtraq would be performing unauthorised relaying if it accepted the message and attempted to deliver it onwards.
Note the crucial difference between those two examples. Unless SMTP Authentication is enabled in Mailtraq, the IP address of the sending client is the only factor which can be used to discriminate between authorised and unauthorised relaying. For installations where Mailtraq is connected to the Internet, it is very important that relaying is not permitted based on the domain name announced by the connecting client. The SMTP reverse path (as supplied in the SMTP envelope in a parameter to the MAIL command) is trivial to forge and must not be relied upon under any circumstances.
Forward Path Resolution
Where possible, Mailtraq resolves the ultimate SMTP envelope forward path (i.e. destination domain) even if source routing, for example <@local.host:user@remote.host> or the percent hack, for example , exploits are used and refuses to relay with an appropriate SMTP protocol response, "550 cannot relay for remote.host" or "550 forwarding percent hack is not permitted" respectively.
However, Mailtraq cannot resolve UUCP style bang paths, for example , or the various types of quoted forward paths employed, for example <"user@remote.host"@local.host"> so it treats them as being locally deliverable in accordance with the settings on the Undelivered Mail tab. Note that, although those types of relay exploits are accepted at the SMTP envelope level, the messages to which they are attached are not subsequently relayed out of Mailtraq by default.
To block those types of relay exploits at the SMTP protocol level, add the following three patterns, one per line, to the Bar mail addressed to listing on the Inbox Properties dialog. For clarity, and to avoid barring legitmate mail due to misreading the wildcard patterns, their ASCII equivalents are also provided for information only:-
| Pattern |
ASCII Equivalent |
| *!* |
(ASCII 42) (ASCII 33) (ASCII 42) |
| "*@*" |
(ASCII 34) (ASCII 42) (ASCII 64) (ASCII 42) (ASCII 34) |
| "*@*"@* |
(ASCII 34) (ASCII 42) (ASCII 64) (ASCII 42) (ASCII 34) (ASCII 64) (ASCII 34) |
Mailtraq refuses forward paths which match the above patterns with a "550 " protocol response, adding the text string specified by the user in the Message to send when address is barred edit box.
Authorised Relaying
If Mailtraq should accept mail for other domains, that is, act as an MX relay for remote domains, the remote domain should be added to the ‘Always allow relaying to these recipients’ control in the following format:-
*@domain.example.com
Mailtraq then accepts mail addressed to that non-local address and places it in the outbox. The outbox MUST contain a suitable custom static route to forward such messages direct to the correct remote destination. If such messages are allowed to be routed normally by Mailtraq, a mail loop has been formed and the messages will eventually bounce.
Relay Testing
Relay tests should be carried out regularly on all SMTP service instances exposed to the Internet. Two alternative tests are currently available. John Levine has a browser triggered test at http://www.abuse.net/relay.html and MAPS (Mail Abuse Prevention System) have a telnet triggered test described at http://mail-abuse.org/tsi/ar-test.html. If configured correctly, Mailtraq refuses all currently known relay exploits at the SMTP envelope level.
Further information on the detailed setup of Mailtraq's relaying controls is available on the Relaying tab
