Email HELOs with machine short name and not FQDN

[gerdesj]

Please see "4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)" in https://www.ietf.org/rfc/rfc2821.txt

Many SMTP daemons drop connections for short named HELO/EHLO.

[Sneddo]

uhhhh sure...what exactly is the problem?

[gerdesj]

vCheck-vSphere has the option to send an email with the results. When it sets up the email transfer, the first stage is to identify itself to the other end (ie the SMTP server). You can try it yourself, here I am connecting to a GMail server:

$ telnet gmail-smtp-in.l.google.com. 25 Trying 64.233.184.27... Connected to gmail-smtp-in.l.google.com. Escape character is '^]'. 220 mx.google.com ESMTP n190si27562671wmg.90 - gsmtp helo me 250 mx.google.com at your service

I typed in the line "helo me" where I claim to be a system called "me". Many mail systems do not allow a short helo and will drop the connection, considering it as likely spam. What I really should have put was "helo me.example.co.uk". In this case GMail is not that fussy but many are.

All that needs changing is to get the part of vCheck-vSphere that determines the hostname of the system it is on is to also gather it's fully qualified (DNS) domain name and use that in the emailing routine.

[Sneddo]

Not that easy I'm afraid. This is actually a limitation of the SmtpClient class of the .net framework, which we obviously have no control over. Look like support for this was added, but depends on .net version as the property was renamed at some point. Needs further investigation... https://msdn.microsoft.com/en-us/library/system.net.configuration.smtpnetworkelement.clientdomain(v=vs.110).aspx