More Comments about Anti-Relaying

Last Update 1999-11-24

I've already explained in detail how check_rcpt prevents unauthorized relaying. Here are some more thought about the rulesets which are available and about their subtle differences.

Simplest Case

In the simplest case, the prevention of unauthorized relaying is straightforward: this case refers to having just one mailhost: here all mail must either originate from that host or it must end there. No ruleset should have problems with this.

Simple Case

It's getting a bit more complex if there are some mailclients. However, it's still easy to deal with that: since they are only sending e-mail (never receiving), their IP addresses (or hostnames) need just to be added to an appropriate file (or map) to allow outbound mail (from the client to anywhere).

Problem Case

The complex case is: there are several mailhosts. Let's start with a simple configuration that exhibits the problem: There is just one domain to deal with and two mailservers, one of which is the backup server for this domain. To give a concrete example: The domain is

our.domain

the mailservers are

main.our.domain
back.our.domain

where only main.our.domain is responsible for local delivery of mail sent to our.domain. Now there is a problem: back.our.domain must allow incoming mail to be relayed to main.our.domain if it is sent to our.domain. So we add our.domain to an appropriate file (or map) to allow incoming mail (from anywhere to main.our.domain).

The Problem

Now we may have a problem: the usual setup allows back.our.domain to relay any mail through main.our.domain. And hence we have a problem with the normal rulesets against relaying: Just use a route address of the form @our.domain:victim@remote.system (or some variant thereof) and the mail will get through.

The ruleset check_rcpt proposed at this site is very aggressiv to provide protection against unauthorized relaying. For the example just given, it will remove all parts of the recipient address which match domains that are local or which we relay to. However, this isn't correct for all cases. For example, let's assume there is some system connected to main.our.domain which is only reachable via a routing address: @our.domain:user@local.system (or some variant thereof). This address will not be accepted by back.our.domain: it will be rejected as an authorized relaying attempt (1). Other rulesets will allow this address to get through, and hence open up a chance for unauthorized relaying.

What to do?

If you can't (or don't want to) use the strict check , there's another way to deal with the problem: treat back.our.domain as an external system at main.our.domain. This also requires back.our.domain sending its external e-mail not via main.our.domain.

Risk?

The question is: is there a chance an "attacker" can make use of this hole? This has to be decided by each system administrator herself, and hence the choice of a ruleset is up to her. Just in case: the check_rcpt ruleset which is standard in sendmail 8.9 has an option to disable the stricter check.

Cases to test

If you have developed your own ruleset against relaying, here are some cases you may try:

<@our.domain:victim@remote.domain>
<@our.domain,@back.our.domain:victim@remote.domain>
<victim%remote.domain@our.domain>
<"victim%remote.domain"@our.domain>
<"victim@remote.domain"@our.domain>
<remote.domain!victim@our.domain>
<"remote.domain!victim"@our.domain>

Try these on your main and on your backup mailservers.

Footnote(s)
(1) Unless local.system is added as allowed recipient , too. However, this may become an administrative nightmare in some cases. Either all system "behind" our.domain must be listed, or these systems must have main.our.domain and back.our.domain as MX servers and an appropriate option is used.

[(links)] [Hints] [Avoiding UBE] [cf/README] [New]

Disclaimer: the information provided may be inaccurate or outdated or incomplete. Please contact me if you find an error.