Normally, the reason you have reached this page is because a mail server has sent you a message when it rejected an email from you, or one of your users.
Although email servers can (by RFC) accept connections that have a poorly formatted HELO or server identification string sent during email transmission dialogue (eg MTA to MTA communications) most Best Practises 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.
This rule performs simple checks on the format of the HELO sent. Although it is recommended in many Best Practises documents that the HELO be a fully quailifed domain name that is publically resolvable, this rule does not check for that, as some operators may still be using a fully quailifed domain name that is only used internally at their location.
It requires that the HELO (or EHLO) string that is sent is in the format of a fully qualified domain name (FQDN).
Note! This only applies to MTA to MTA traffic. End users who send email to mail servers are usually exempt from this rule as most email clients only use the hostname, which may or not be defined on a PC.
In order to ensure that messages are not stopped by this check, make sure the HELO is a FQDN.
The HELO string sent should in the style of:
The HELO string sent should in the style of:Example:
HELO mta1.mycompany.comThe following bad example(s) will get rejected:
HELOSpammers 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'.
HELO 192.168.1.1 (just an IP)
HELO .com (starts with a period)
HELO @(&$ (characters not normally allowed in domain names)
If your email was blocked, and the link sent you here it is probably because your email client is not set up correctly.
Normally this should never affect you, as it is meant for mail server to mail server communication. When you are allowed by your ISP or email provider to use their mail server to send email (eg your 'Outbound Mail Server') they will not check this rule. They only check it for email sent to them from other locations. However, IF you do not have your email client set up properly, your ISP may not be able to tell if you are one of their customers. Normally this is done by setting your email client to use 'SMTP Authentication', or you have to be on specific IP addresses your ISP allows to 'relay' through their email server.
The main problem will usually be in your email/account settings, (eg. in OutLook or Thunderbird)
Make sure you are using SMTP authentication, or contact your ISP for more information.
Normally, this rule will only block spammers who have 'hacked' or compromised personal computers like yours and try to send blanket email blasts to real email servers. A real email server will be able to tell that any machine who doesn't know their own identity is probably a compromised PC, and not a real email server, and use this to block spam. As well, email servers need to send this so email administrators can track down how email was moved around between servers, especially in companies that may have many different email servers at one location.
Please check that you use the correct method to connect to your ISP in your email client, or contact the administrator of your outbound email server, or ISP for more information.