My VCSA 6.5 does not send emails – Connection refused by []

This is another issue I see from time to time in Support Requests showing up in my team

This time the DNS settings are fine but the Appliance is still not able to send the emails, and a reboot of the appliance is not helping.

So let’s have a look at the /var/log/messages.

2018-01-15T12:44:41.259549+01:00 vcenter sendmail[35923]: w0FBifp0035923: size=535, class=0, nrcpts=1, msgid=<>, relay=root@localhost
2018-01-15T12:44:41.275104+01:00 vcenter sendmail[35923]: w0FBifp0035923:, (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30535, relay=[] [], dsn=4.0.0, stat=Deferred: Connection refused by []

OK, so we will get a Connection refused by [] when the vpxd process is trying to send the email to the local sendmail server for delivery to the relay host.

When checking for the port with netstat -tulpen | grep :25 we will get no result.

In this case, restarting the service using systemctl will not help, as there will be a conflict regarding the port.

The easiest way to fix the issue is to simply open the web client, go to the vCenter email settings and remove them, save the changes and re-add them.

This will restart the sendmail daemon using the vCenter internal way of managing system services.

Now you vCenter should send emails again.

root masquerading in VCSA 6.0

Hi all,

I blogged about it in the past on my other blog, which got eaten by the Internet ūüėČ

So as I already blogged about email notifications in the vCenter Appliance 6.5. But I guess there are still some 6.0 appliances out there.

Here are my old notes, hope they help.

Set the mail server config on the vCenter UI

Set the SMTP Server to and the E-Mail Adress to the E-Mail Adress the vCenter should use to send the email.

Configure the Address Translation for the root user

Edit the File /etc/mail/genericstable

# /etc/mail/genericstable
# Author: Werner Fink
# Please send feedback to
# Description:
#  map outgoing sender addresses from the (unqualified) left hand side
#  to the qualified addresses on the right hand side.  The same types
#  of addresses as for masquerading are looked up, i.e., only header
#  sender addresses unless the allmasquerade and/or masquerade_envelope
#  features are given (/etc/sysconfig/mail -> FROM_HEADER). Qualified addresses
#  must have the domain part in the list of names given by the by the
#  macro GENERICS_DOMAIN (/etc/sysconfig/sendmail -> SENDMAIL_GENERICS_DOMAIN).
# Format:
#user@uqhost        realuser@fqhost

Configure the

Download the

Please edit the following Lines so the represent the customer enviroment and save it as /etc/ on the vcsa:

# "Smart" relay host (may be null)


# class E: names that should be exposed as from this host, even if we masquerade
# class L: names that should be delivered locally, even if we have a relay
# class M: domains that should be converted to $M
# class N: domains that should not be converted to $M
#CL root
# who I masquerade as (null for no masquerading) (see also $=M)


Cwlocalhost  vcsa.repro.benslab.local

Last but not least:
Run the following commands to build the new genericstable and to restart the sendmail service

makemap -r hash /etc/mail/genericstable.db < /etc/mail/genericstable
service sendmail restart



Meltdown and Spectre in VMware Products

Update: You may want to have a look at my new blog post on this topic

Hi all,

as I am getting quite a few tickets regarding Spectre and Meltdown on vSphere Products and I just want to point you all to the official communication.

First of all, there are the Security Advisories for vSphere and Photon:

Then there is a good meta post on the official VMware Security Blog:

And last but not least there are two KB Articles containing some more Information on this Topic:




My VCSA 6.5 does not send emails

Sometimes a VCSA is not able to send emails, as it is not able to validate the sender domain. For example.

The vCenter is configured to send an email as over the mail server

Screenshot from 2017-12-13 13-40-56

As sendmail cannot get the correct MX Record for the domain the from-field in the email header will stay empty and the /var/log/messages.log will show something like this.

2017-10-23T10:48:59.567720+02:00 vcenter sendmail[55361]: v9N8mxa7055361: v9N8mxa8055361: DSN: Data format error
2017-10-23T10:48:59.592809+02:00 vcenter sendmail[55362]: v9N8mxkl055362: from=<>, size=429, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=photon-machine []
2017-10-23T10:48:59.607661+02:00 vcenter sendmail[55362]: v9N8mxkm055362: from=<>, size=2421, class=0, nrcpts=1, msgid=<>, proto=ESMTP, daemon=MTA, relay=photon-machine []
2017-10-23T10:48:59.644144+02:00 vcenter sendmail[55361]: v9N8mxa8055361:, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=31453, relay=[], dsn=2.0.0, stat=Sent (v9N8mxkm055362 Message accepted for delivery)
2017-10-23T10:49:03.964029+02:00 vcenter sendmail[55364]: v9N8mxkm055362: to=<>, delay=00:00:04, xdelay=00:00:04, mailer=relay, pri=122421, [], dsn=2.0.0, stat=Sent (Ok: queued as A5EA0B40C3)

To solve the issue we can help the sendmail daemon to find the right mail server for domain

For this we need to edit the /etc/hosts file and add something like this.

# email workaround;
# vCenter Email Address:
# Smarthost IP:

After this, we have to remove the Mail Settings in the vSphere Web Client, and after saving the changes, add them again.

Now the vCenter should be able to send emails again.

vCenter 6.5 – Machine_SSL Certificate with multiple DNS Names

Please note that you should not use this workaround in production.

From time to time it is needed to have multiple DNS Names in your Certificate.

First, create a File called machine_ssl.cfg on your vCenter.

default_bits = 2048
prompt = no
encrypt_key = no
default_keyfile = machine_ssl.key
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
[ req_ext ]
subjectAltName = @alt_names
subjectKeyIdentifier = hash
keyUsage = digitalSignature, nonRepudiation, keyEncipherment

[ alt_names ]
email.1 =
DNS.1 = vcsa.benslab.local
DNS.2 = vcsa.test.local
DNS.3 = vcsa.home.lab

Now as we have the configuration file we need to create the Certificate Signing Request.

 openssl req -new -config machine_ssl.cfg -out machine_ssl.csr

This CSR needs to be signed by the CA and the Machine_SSL Cert can be replaced.
If you just want to use the VMCA to sign the Certificate you may find this KB useful.