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.
- If you are an email or network operator, you can continue reading this section
- If you are a user sending email and it got blocked, you should read this section instead
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 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 a DNS test of the HELO identifier sent. It is recommended in many Best Practises documents that the HELO be a fully qualified domain name that is publicly resolvable, so that others can identify the server and the responsible party for a particular mail server. Many operators have adopted this as a best practice and if you have encountered this then the ISP or mail operator has chosen to adopt this strategy. You might also like to visit valid helo domain as well. This Best Practise is becoming more widely adopted, and although there are still many email servers using internal, or non-resolvable names for the HELO it is suggested that operators start adopting this policy.
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:
Example: The following bad example(s) will also get rejected as they do not resolve:
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’.
If you are the one sending the message, and you were blocked with this message, it is most likely that you do not have your email client set up correctly, and you should read the next section.
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.