Best practice for specifying a valid HELO and EHLO during email communication
12/14/15 4:35 PM
Last modified on:
12/14/15 4:35 PM
Valid HELO/EHLO identifier
Xeams checks for a valid HELO/EHLO identifier when assigning score to emails. An incorrect value may result in an email to be considered as spam.
Information for Email and Network Operators
Although email servers can (by RFC) accept connections that have a poorly formatted HELO or server identification string sent during email transmission dialog most best practices documents insist that all identifiers are correctly used, and in the case of HELO (or EHLO) this applies as well. The principal is that the HELO should identify the sending server in such a way that it can be used to identify servers with problems, such as leaking Spam or incorrectly formatted emails.
Xeams performs simple checks on the format of the HELO sent. It requires that the HELO (or EHLO) string that is sent is in the format of a fully qualified domain name (FQDN).
Additionally, Xeams also check if you are sending this email from mta01.yourcompany.com.
The following bad example will get rejected:
HELO 192.168.1.1 (just an IP)
HELO .com (starts with a period)
HELO @(&$ (characters not normally allowed in domain names)
Spammers will often be caught by this rule, when they take over a PC to act as a spam bot. They just use the hostname as the PC has it configured, which is normally not set up as a FQDN. Also, often administrators might install email server software without intent, that gets compromised or activated, and often it will use just 'localhost'.
Xeams does not apply this rule if the message is being sent by an authenticated user, local user or the IP address is open for relay or is white-listed.
Add a comment to this document
Do you have a helpful tip related to this document that you'd like to share
with other users? Please add it below. Your name and tip will appear at the
end of the document text.