Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

tl;dr: - sendmail is configured to use a relay server but still insists on using 127.0.0.1 as the relay, which results in mail not being sent.


We have the open source vCenter appliance (v 5.0) managing our ESXi cluster. When connected to it via vSphere Client, you can configure the SMTP relay server to use by going to Administration > vCenter Server Settings > MAIL. There you can set the SMTP Server value. I looked through their documentation and also confirmed on the phone with support that all you have to do to configure mail is to put in the relay IP or fqdn in that box and hit OK.

Well, I had done that and mail still wasn't sending. So I SSH into the server (which is SuSE) and look at /var/log/mail and it looks like it's trying to relay the email through 127.0.0.1 and it's rejecting it. So looking through the config files, I see there's /etc/sendmail.cf and /etc/mail/submit.cf. You can configure items in /etc/sysconfig/sendmail and run SuSEconfig --module sendmail to generate those to .cf files based on what's in /etc/sysconfig/sendmail.

So playing around, I see that when you set the SMTP Server value in the vCenter gui, all that it does is change the "DS" line in /etc/mail/submit.cf to have DS[myrelayserver.com].

Looking on the internet, it would appear that the DS line is really the only thing you need to change in order to use a relay server. I got on the phone with VMWare support and spent 2 hours trying to modify ANY setting that had anything to do with relays and we couldn't get it to NOT use 127.0.0.1 as the relay. Just to note, any time we made any sort of configuration change, we restarted the sendmail service.

Does anyone know whats going on? Have any ideas on how I can fix this?

share|improve this question
    
If you have the appliance, then you probably also have support. Please ask VMWare for help. THe better long-term solution is to use a real vCenter running on Windows, though... –  ewwhite Dec 1 '12 at 18:12
    
I'm guessing you skipped the line where I said I spent 2 hours on the phone with them. And is there a specific reason I should have my company spend money on the "real" vCenter? Or was that a "Linux sucks, Windows rules!" type of comment? The way I see it is the Windows version costs money only to give us features that we won't use anyway. That doesn't seem like a better long term solution to me. –  Safado Dec 3 '12 at 15:00
    
The reason is that the vCenter appliance has many known limitations. It seems like a poorly-implemented product. From my perpective, VMWare hasn't dedicated the resources to making it operate at the same level as the Windows-based vCenter. Due to that and the limitations I linked to, I've had to abandon it in several installations. –  ewwhite Dec 3 '12 at 15:09
    
Thanks for that link. That's good to know. –  Safado Dec 3 '12 at 15:31

4 Answers 4

On Red Hat systems, there's an /etc/mail/access file for sendmail.

And example of the contents is:

# Check the /usr/share/doc/sendmail/README.cf file for a description
# of the format of this file. (search for access_db in that file)
# The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc
# package.
#
# by default we allow relaying from localhost...
Connect:localhost.localdomain           RELAY
Connect:localhost                       RELAY
Connect:127.0.0.1                       RELAY
172.16.2.116                            RELAY
172.16.2.17                             RELAY

You should define your vCenter's IP in that file (or its SuSE equivalent) and restart the daemon.

Edit:

I assumed you set Sendmail to listen on something other than its loopback address. Go into the sendmail.mc file and look for this stanza.

dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

You want to comment-out the last line there by adding dnl. So you should end up with:

dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

Restart the sendmail service and try again.

Edit:

The OP is trying to configure their Linux-based vSphere appliance to relay through another mail server. This is just a case of defining a SMARTHOST. In your sendmail.mc file, find the line that says:

dnl define(`SMART_HOST', `smtp.your.provider')dnl

Remove the comment line and enter the name of your mail server. If your mail server's name is mail.bootylicious.com, your resulting sendmail.mc line will look like:

define(`SMART_HOST', `mail.bootylicious.com')dnl

Please make sure that you can ping the name you use...

Restart Sendmail.

share|improve this answer
    
So here's the odd thing. Whenever I restart the service with service sendmail restart it gives me a success message. But when I check for anything listening on port 25, there's nothing (which explains the denied messages) Finally, after 2-3 minutes, the mail log shows that the sendmail daemon has started and netstat finally shows something listening on port 25. Then when I send emails, it says message accepted for delivery, with the relay still at 127.0.0.1... it never attempts to send it on (neither the destination nor the relay server) –  Safado Nov 28 '12 at 21:05
    
The emails that it says "Message accepted for delivery" are just going to the queue and sitting there. –  Safado Nov 28 '12 at 21:08
    
@Safado See my edits above. –  ewwhite Nov 28 '12 at 21:25
    
Well, our end goal is to have it use a relay and not localhost. However, I finally got the "relay" part to say the IP address of my relay server and not 127.0.0.1, but it just immediately queues it. I added my relay's IP address to access and relay-domains, but still no joy. I feel I'm getting closer though –  Safado Nov 28 '12 at 21:35
    
@Safado Oh, nevermind. I misread... I thought you were trying to set up a Linux server to be a mail relay. For your vSphere appliance, you just need to set a SMARTHOST... See my edits above. –  ewwhite Nov 28 '12 at 21:55

There are two configuration files that newer versions of sendmail work with. These are submit.cf and sendmail.cf. Do not change either sumbit.mc (which is used to produce submit.cf) or submit.cf itself. They are used when a local mail program forks sendmail in order to send email and all they do is to relay the mail to be sent to the sendmail daemon that listens on 127.0.0.1:25

So all you need to do is either change DS by hand in sendmail.cf and give it a value like:

DS[relay.server]

including the brackets, or modify the SMART_HOST macro in sendmail.mc:

define(`SMART_HOST', `[relay.server]')dnl

If you modify sendmail.mc you need to produce a new sendmail.cf and then restart the sendmail daemon. In Debian you run sendmailconfig. In CentOS you run both /etc/mail/make followed by service sendmail restart. I am not using SuSE, sorry.

share|improve this answer
up vote 0 down vote accepted

This is bizarre, but this is the only way I could get it to work ...

The name I wanted it to be masqueraded with is mydomain.com. The vCenter server had a hostname of mycluster with mycluster and mycluster.vmware.com in the /etc/hosts file (why vmware.com, I have no idea... is this required for the appliances or did our contractor that configured it do it wrong? Or does the appliance do it by default? Anyone know?).

To get everything working, I had to add mydomain.com to the /etc/hosts file of the vCenter server for both 127.0.0.1 and ::1. But not only that, I had to have it listed BEFORE the mycluster and mycluster.vmware.com. It would appear that sendmail looks at /etc/hosts and grabs the first name listed under 127.0.0.1 and sets that as the sending domain??

Anyway, it works now. When a trigger in vCenter goes off and sends an email, vCenter reports that it could not send the email, but then about 60 seconds later I actually get it. So something still isn't right, but at least it's working.

share|improve this answer

The following worked for me on Suse Enterprise Linux 11 SP2:

vi /etc/sysconfig/sendmail


# change SMARTHOST to your relay
SENDMAIL_SMARTHOST="[x.x.x.x]"

# change to YES, to not resolve DNS
SENDMAIL_NOCANONIFY="yes"

SuSEconfig --module sendmail

service sendmail restart
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.