Monday, October 15, 2012

Sendmail 550 Access denied with 127.0.0.1 Relay

Ran into this little sendmail issue today on a CentOS box.

My Linux server was configured to relay mail to a main corporate exchange server. The M4 configuration already had a proper SMART_HOST configured.

I was doing a simple test with sendmail and was getting an access denied error like this:


[root@server]# sendmail -v root
ppp
ppp
.
root... Connecting to [127.0.0.1] via relay...
220 server.com ESMTP Sendmail 8.13.8/8.13.8; Mon, 15 Oct 2012 13:41:19 -0400
>>> EHLO server.com
250-server.com Hello server.com [127.0.0.1], pleased to meet you
250 ENHANCEDSTATUSCODES
>>> MAIL From:<user@server.com>
550 5.0.0 Access denied
user... Using cached ESMTP connection to [127.0.0.1] via relay...
>>> RSET
250 2.0.0 Reset state
>>> MAIL From:<>
550 5.0.0 Access denied
postmaster... Using cached ESMTP connection to [127.0.0.1] via relay...
>>> RSET
250 2.0.0 Reset state
>>> MAIL From:<>
550 5.0.0 Access denied
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 server.com closing connection



This shows us that the first hop in the relay process is to itself.  This was where it was failing.

The fix was to add the following line to /etc/hosts.allow file:
sendmail: ALL :allow

This cleared up the issue and got mail flowing once again. This works since the hosts entries also apply to traffic for system daemons.

Viewing communication using the sendmail -v command is one way to view what's happening, however in my case once things were working again with the local relay I needed to look at the /var/log/maillog file to see that messages were making the next hop out to the corporate mail server. I could then see the relay=corporate.mail.server.com.   in the logs with a status of "Sent"


3 comments:

  1. it should be

    sendmail: ALL : ALLOW

    ReplyDelete
  2. I'm so happy that I found this. I was spinning my wheels and never thought about the TCPwrappers that I'm running on the host.

    ReplyDelete
  3. It helped me on RHEL, thank you very much

    ReplyDelete

Let us know if you found anything helpful, or have an even better solution. Thanks for your participation in the discussion.