SUMMARY: Sendmail problem: receiving mail at alias name.

From: Rodney Wines (
Date: Tue Aug 12 1997 - 09:10:26 CDT

Thanks to everyone who replied. As always, you were a great help.

Original question:

> For reasons of company politics, I've got a Solaris 2.5.1 machine that is
> really in a subdomain of but must be able to receive mail as if
> it were in The machine now has an A record in the
> domain, and is accessible via telnet, etc. Mail works when sent FROM the
> machine. However, when I try to send mail TO that machine, the mail
> bounces, and I get:
> 553 ... config error: mail loops back to myself
> If I send a message to that machine, I can then log onto the machine and
> type "mailq" and actually see the mail in the queue. However, sendmail
> doesn't seem to know that it is OK to deliver the message locally, and the
> mail eventualy bounces.
> I faced this same problem with another machine, and I wasn't able to solve
> it until I ran "sys-unconfig" and told the machine that it really was in
> the domain. I'm trying to avoid doing this again, because the
> machine is at a remote location, and there's nobody on-site that would be
> able to correctly answer the configuration questions. Any help would be
> appreciated!
> Here's what I've done so far:
> The machine has an A record in the domain, like I said. It
> does not have a reverse-lookup entry in that domain, because the
> name servers aren't authoritative for the IP address range the
> machine is in. The reverse-lookup points to an address in a subdomain of
> /etc/resolv.conf does have "domain".
> In, I've even tried a "Dw" to define the hostname as it should
> be in the domain. It looks like:
> Dwcomhost
> I've also set:
> That's the mail server for the domain.
> II also have:
> I also tried adding Cw, but it didn't make any difference.
> Running "sendmail -d0.4 -bt </dev/null" shows something like:
> # /usr/lib/sendmail -d0.4 -bt </dev/null
> Version SMI-8.6
> canonical name: frhost
> a.k.a.: loghost
> a.k.a.: []
> a.k.a.: []
> a.k.a.: []
> a.k.a.:
> SYSTEM IDENTITY (after readcf):
> (short domain name) $w = comhost
> (canonical domain name) $j = $w.$m
> (subdomain name) $m =
> (node name) $k = frhost
> I've changed the host names and IP address to protect the innocent, but the
> actual IP address does have two "a.k.a" entries, as shown above.
> I'm using the "out of the box" Solaris 2.5.1 sendmail, and the above hacks
> are all the changes I've made to the basic "".

I'm not sure exactly what I did to fix the problem. Several people told me
to add "Cw", but I'm not sure that I got the syntax right the first couple
of times I tried. Also, I was lazy when restarting sendmail. Instead of
doing a ps -ef | grep sendmail and killing the process, I did:

        /etc/init.d/sendmail stop ; /etc/init.d/sendmail start

At some point, the /etc/mail/ file no longer had the pid of my
running sendmail, so I wasn't killing the running version, and so a new
version couldn't start. I didn't get any errors, but sometimes when I tried
to stop sendmail, I'd get "no such process". I just thought that
sendmail was dying due to my hacked config file. I finally got suspicious
enough to check closely.

Anyhow, here are the things I did to YMMV:

Dwcomhost #Force hostname to match that in the .com domain
Cw comhost #All variations of host name #Hard-code domain name

I made sure those three lines were physically above:

        # my official hostname

I suspect that this might've been my problem with "Cw" all along; at first,
"Cw" was below these lines. Since I don't know what any of this meant when
I first started (I've spent a LOT of time with O'Reilly's sendmail book
since), it didn't occur to me to worry about order.

Finally, (Padmanabh M Padaki) suggested replacing rule
S11 with the following:

R$*<@$+>$* $@$1<@$2>$3 already ok
#R$=D $@$1<@$w> tack on my hostname
#R$+ $@$1<@$k> tack on my mbox hostname
R$=D $@$1<@$w.$m> tack on my hostname
R$+ $@$1<@$k.$m> tack on my mbox hostname

If you use any of that, and you cut and paste, remember that the fields in are separated by tabs and not spaces.

I don't know if the rule change helped, but it did make the return address
look better for mail sent from the machine.

As I said, I don't know which of these changes actually solved my problem.
If I get time, I'll try various combinations in the hope of finding the
minimum changes required. If I do, I'll post another summary.

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:00 CDT