Thanks to everyone who replied. As always, you were a great help.
> For reasons of company politics, I've got a Solaris 2.5.1 machine that is
> really in a subdomain of .alcatel.fr but must be able to receive mail as if
> it were in alcatel.com. The machine now has an A record in the alcatel.com
> 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 alcatel.com 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
> Here's what I've done so far:
> The machine has an A record in the alcatel.com domain, like I said. It
> does not have a reverse-lookup entry in that domain, because the
> alcatel.com 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 alcatel.com".
> In sendmail.cf, I've even tried a "Dw" to define the hostname as it should
> be in the alcatel.com domain. It looks like:
> I've also set:
> That's the mail server for the alcatel.com 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.: [188.8.131.52]
> a.k.a.: [127.0.0.1]
> a.k.a.: [184.108.40.206]
> a.k.a.: frhost.frdomain.alcatel.fr
> SYSTEM IDENTITY (after readcf):
> (short domain name) $w = comhost
> (canonical domain name) $j = $w.$m
> (subdomain name) $m = alcatel.com
> (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 "subsidiary.cf".
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/sendmail.pid 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 sendmail.cf. YMMV:
Dwcomhost #Force hostname to match that in the .com domain
Cw alcatel.com comhost comhost.alcatel.com #All variations of host name
Cmalcatel.com #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, email@example.com (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
sendmail.cf 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