GoDaddy? Helo? Ehlo?

Earlier this week we learned that GoDaddy was blocking legitimate mail from Modwest customers to GoDaddy customers. A quick call to their HQ revealed that they were blocking one of our mail servers because of a "bogus helo" problem, which, in their words, generally indicated the presence of a spam or virus outbreak. Once we eliminated this possibility and ensured our strict spam policies were being followed, I asked Mike, our senior sysadmin and Operations Manager, for his analysis of the GoDaddy's policy. Here's what he had to say:

Why is the policy of checking SMTP/ESMTP HELO/EHLO bad?  RFC2821 (which supersedes RFC821 as the SMTP/ESMTP standard) Section 4.1.1.1 describes the SMTP HELO and ESMTP EHLO Command, response, and requirements.  An EHLO or HELO is a MUST for SMTP clients.  RFC2821 Sec. 4.1.1.1 states exactly this "The argument field contains the fully-qualified domain name of the SMTP client if one is available."  There are many cases where one is not available.  Or where an accurate one is not available.

Now, strictly speaking, if one can't determine a valid domain you're supposed to use what RFC2821 calls an "address literal".  This amounts to your IPv4 or IPv6 address enclosed in [].  All of this is problematic.  In the case of using a domain name, what is the "correct" domain name?  Well RFC2821 makes that very clear.  Section 3.6 addresses what a domain name is in this case.  Specifically it states:

   * The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
   * The reserved mailbox name "postmaster" may be used in a RCPT command without domain qualification (see section 4.1.1.3) and MUST be accepted if so used.

So the second bit isn't applicable in this case.  We're talking about a domain, not an address, but the second first part is.

In our case we have a large mail cluster whose primary host name is mail.modwest.com, which has an associated A record.  The RFC does NOT make any requirement as to that A record matching the IPv4 or IPv6 address we're connecting to the remote host from.  But when presented with this as a HELO/EHLO domain, GoDaddy refuses the message with a hard failure.  So our case of using the HELO/EHLO is clearly supported by the RFC.  GoDaddy refusing to accept the mail at that point, claiming a violation of HELO/EHLO being refused is unsupported by the governing standard in the case that our server says "EHLO mail.modwest.com".

Now, it is possible that GoDaddy is rejecting mail because of suspected virus load coming from a particular machine, but again, it should not be stating the problem to be an invalid HELO/EHLO if this is the case.  If you can't accurately identify to the sender the reason why you're rejecting a message, at the time you reject it, you should not reject it.

So why might the domain name not be available for HELO/EHLO?  It may be a case of DHCP environments, where you don't know what your rDNS should be. It may be the case of a large cluster of machines that appear as the same machine.  It may be the case of a single machine with multiple interfaces. (Only the kernel initially knows the interface and therefore IP that was used for an outbound connection, unless you explicitly force them to come from a particular IP, but that can have other nasty interactions with stateful firewalls and reverse path filters. )

So there you have it. GoDaddy, we'd love to work together with you to reduce spam and malware. But can you let our customers' legitimate mail through to your customers now? We're pretty sure both sides would appreciate it.

UPDATE 4/20: GoDaddy says they've unblocked the mail server in question, and it seems to be the case.

-JM

Comments

[Michael Akers]

Yep, I am having the same problem with a mail server I manage and GoDaddy blocking it. We have mutliple domains on the mail server and all mails go out under one primary host mail.xxxxxxxx.net. Which is perfectly correct under the RFC but GoDaddy blocks it with the bogus HELO message. I am not happy.

[Bill]

I have a different problem. I have a standards compliant postfix mail server on a static IP assigned by the ONLY broadband carrier in Northern Idaho. It is a cable carrier. I have rDSN resolving correctly. They are rejecting me as "dynamic" though I am legitimate, static, business server. I understand the issue, and the reasons for rejecting(which I don't agree with, MANY legit business operate on "dynamic" ip blocks as they have no alternative) but can't seem to find ANY contact number to see about getting whitelisted so I can contact my client. (I am a consultant) Can anyone help? Thanks. bill * at * blmservices * dot * com

[John Masterson]

Hi Bill,

Modwest rejects mail from certain dynamic ranges too if the range in question is also inhabited by zombie PCs blasting spam. (See http://www.modwest.com/help/kb9-266.html #3)

The solution in our case is for the legitimate business in that range to request alternate rDNS from their IP provider. So, rather than "123-123-123-123.dyn.isp.com", something like "gateway.legitbusiness.com" would resolve the situation in our case.

-JM

[Bill]

As I stated before, I have rDNS as you state. I host several virtual domains which all rDNS to the parent domain which is blmhosting.com. I would expect that your system would not have a problem with my server. I am unable to find contact info for godaddy to see about getting this resolved: I know this is not your problem, but as you posted that you were able to contact them, perhaps you could share some contact info with me so I might be able to resolve this issue with them. I check all my incoming mail against spamhaus, et. al. as do they. I do not use dul.dnsbl.sorbs.net, etc. as they are the ones that simply allow reject based on "dynamic pool" only. I think this is an unreasonable practice. I do, however support you policy of using rDNS to weed out the "junk". I would be happy to contract a different internet provider if there was another option here: there simply isn't. Thank you for any help you can provide in this matter (i.e. helping me with some contact info... :P)

[John Masterson]

Have you tried this yet?
http://unblock.secureserver.net/

That's what worked for us (on multiple occasions). I don't know whether GoDaddy (aka secureserver.net) has changed their policy since this original post.

[Alan Doherty]

MORONS: if as you claim "In our case we have a large mail cluster whose primary host name is mail.modwest.com, which has an associated A"
why then does your clusters primary hostname not resolve to all of it's ip's

you via dns are telling them that it's a forgery of your name, they are simply following what you say in your dns

if in fact this is the identity that you want sharered by all the nodes in your cluster then update your DNS to have all the ip's of all the nodes resolvable to that name

{my COMPITENT isp does this mail.esat.net does resolve to all the ip's of the cluster}
{and they don't even have the nodes helo with one identity as they find forgery tracking easier if each node uses its own unique hostname {also resolvable} in helo}

i also reccomend you note this is to prevent spammers impersonating your mailserver these checks are done, using a helo name that has an A record or AAAA for all ipv4 and ipv6 address's of the host is not rocket science and easily fixed by having compitently run dns or mailservers

[John M]

Hi Alan, thanks for your interest.

I think we may be speaking apples and oranges. The fact that 'mail.esat.net' returns multiple IP addresses is essentially equivalent to having multiple MX records with the same priority, which leaves it up to the client (or the spambot) to decide which server to connect to.

With a true cluster, you advertise your load balanced IP and then you can manage the rest internally, adding and removing machines to the cluster as the need arises. In addition to the control this gives the network operator (in terms of # of connections per server, for example), it also avoids the situation where a client has cached the IP of a dead machine.

This is how the big providers like Hotmail do it -- of course each of their clusters is probably thousands of machines, and they likely run clusters of clusters.

-JM

[Alan Doherty]

i was referring to an outgoing server cluster {not one referanced by any mx records}
and "you advertise your load balanced IP and then you can manage the rest internally" {dns is used for the internal management, to add/remove nodes clients cant cache records longer than the dns record allows, which is also controlled by the admin}

but either way with or without ip load balancing if you connect out from the cluster and claim to be xx.domain.tld then ensure xx.domain.tld resolves to the ip you connected from

take my own server for example 193.2.202.63
if you connect to it it greets as mx10.alandoherty.net
{as you are likely sending in mail and thus connecting to the name given in mx records}
if you send a mail subject "test" to echo at alandoherty.net you will get an autoreply
sent out with our server helo/ehloing as its client name bigsvr.alandoherty.net
its client name btw having a matching A record {required} a matching SPF and CSV record

and to ensure no malware on the server can send mail if it helo'd as its fqdns name {the only name malware could easily obtain} of hosting.alandoherty.net that names SPF record would cause all {compliant} sites to refuse the connection

sending client identity and recieving server identity {even if on the same ip and/or application are entirely unrelated functions}

your name for helo/ehlo on client {outgoing} connections must relate to the source ip

your helo/ehlo name for server {incomming} connections to the loadbalanced ip is largely irrelevant and unchecked by anything other than optional tls