Relaying Denied/Allowed (in sendmail 8.8/8.9-8.12)

Last Update 2001-09-19

Relaying Denied

Starting with version 8.9, sendmail denies unauthorized relaying by default, for sendmail 8.8, HACKs are available to accomplish this task. In both cases, the ruleset check_rcpt is used.

If you get a

550 Relaying denied
or similar, e.g.,
550 5.7.1 <rcpt@some.domain>... Relaying denied
error message from your own mailserver (running sendmail) even though you think it shouldn't happen, you need to find out why. If you don't allow relaying based on authentication (STARTTLS or AUTH) then there are basically three slightly different logfile entries which can give a hint about the possible problem. So find the entries ( grep check_rcpt /PATH/TO/LOGFILE ) about the blocked relay attempts in the logfile and check which case applies to you.
  1. Correct DNS data
    QAA02454: <ESCAPEFOUR@AOL.COM>... Relaying denied
    QAA02454: ruleset=check_rcpt, arg1=<ESCAPEFOUR@AOL.COM>,
    	relay=170-51-209.ipt.aol.com [152.170.51.209], reject=550
    	<ESCAPEFOUR@AOL.COM>... Relaying denied
    QAA02454: from=<Anonymous@aol.com>, size=0, class=0, pri=0, nrcpts=0,
    	proto=SMTP, relay=170-51-209.ipt.aol.com [152.170.51.209]
    

    Here, the machine with hostname 170-51-209.ipt.aol.com and the IP address 152.170.51.209 tried to deliver an e-mail to <ESCAPEFOUR@AOL.COM>. However, this has been denied since neither the recipient <ESCAPEFOUR@AOL.COM> is a local recipient nor is the relaying machine 170-51-209.ipt.aol.com a local sender.

  2. Missing DNS data
    QAA02454: <ESCAPEFOUR@AOL.COM>... Relaying denied
    QAA02454: ruleset=check_rcpt, arg1=<ESCAPEFOUR@AOL.COM>, relay=[134.245.85.93],
        reject=550 <ESCAPEFOUR@AOL.COM>... Relaying denied
    QAA02454: from=<Anonymous@aol.com>, size=0, class=0, pri=0, nrcpts=0,
    	proto=SMTP, relay=[134.245.85.93]
    
    This is the same as above, but this time no PTR record for the IP address 134.245.85.93 was found. This causes problems if that machine is a local sender, but relaying is enabled only based on host/domainnames (e.g., FEATURE(relay_entire_domain)). You can either add PTR records for these IP addresses to your DNS, or add IP numbers (or nets) to the relevant classes or maps ( see below, first case).
  3. Inconsistent DNS data
    QAA02454: <ESCAPEFOUR@AOL.COM>... Relaying denied
    QAA02454: ruleset=check_rcpt, arg1=<ESCAPEFOUR@AOL.COM>,
    	relay=some.domain [10.0.0.1] (may be forged),
        reject=550 <ESCAPEFOUR@AOL.COM>... Relaying denied
    QAA02454: from=<Anonymous@aol.com>, size=0, class=0, pri=0, nrcpts=0,
    	proto=SMTP, relay=some.domain [10.0.0.1] (may be forged)
    
    Here the (may be forged) is the important part: it means that the DNS data for the host is inconsistent, and hence the name is not used for the relaying check but only the IP number. So this is the same situation as before. If the host name would be used, it would be simple to circumvent basic anti-relaying checks because the PTR records might be under the control of an attacker, so he can chose any name he wants for his IP address. That is, he can select a name for which you allow relaying because that name is one that you control (your domain name). However, the forward (A) lookup will fail or give at least a different IP address, hence the name is marked as (may be forged)

Note: Newer sendmail versions provide additional information about possible problems:

There are two cases in which you may get an undesired 550 Relaying denied:

  1. local sender to external recipient: Then the relay (relay=host.domain [IP.ADD.RE.SS]) must be in the relevant classes or maps:
  2. external sender to local recipient: Then the recipient (to=<recipient@address>) must be in the relevant classes or maps:

There may be some problems even though you've added the relevant entries to a file or to a class. For example, due to the tighter permissions checks in sendmail 8.9, file classes may not be read, so you need to check the content:

sendmail -bt
> $=R
(substitute R with the name of the class you want to check).

Similar tests can be performed for the access map.

Relaying Allowed

There are a few cases in which relaying is allowed even though it isn't intended. The most common is case is the use of FEATURE(relay_entire_domain) which allows relaying for every system in class m. If class m is wrong, then the system may open up relaying for other hosts in that domain. Check it with
echo '$=m' | sendmail -bt -d0.4
Sometimes class m is set wrong to be just a TLD (e.g., com). In this case, fix your hostname to be host.sld.tld instead of sld.tld or change $m, or remove FEATURE(relay_entire_domain) and use other means instead.
[(links)] [Hints] [Avoiding UBE] [cf/README] [New]
Copyright © Claus Aßmann Please send comments to: <ca at sendmail.org>
Disclaimer: the information provided may be inaccurate or outdated or incomplete. Please contact me if you find an error.