Years ago D. J. Bernstein wrote “I recommend that server implementors let clients skip HELO, to support a future transition to a world without HELO”. I suppose that anyone who has spend enough time “speaking” SMTP as part of debugging mail systems must have wondered about the need for HELO to even exist in SMTP.
Well it was not always there. RFCs 722 (Sep 1980) and 780 (May 1981) do not include it. It first appears in RFC 788 (Nov 1981). But why?
Back in 2005 in comp.mail.imap Mark Crispin explained why:
The purpose of HELO (and the Received: header line) was to fix a problem that went away with the NCP->TCP transition.
He goes on to explain that in the NCP days the IMPs that relayed messages knew only of the destinations of them and how that could lead to loops delivering the messages to the sender’s machine instead of the recipient’s. HELO solved the loop probelm. The transition from NCP to TCP/IP took place in 1/1/1983 in what is known as the Internet Flag Day. That should have effectively ended the life of HELO. But no, “people felt strongly about making this never happen again” and with the introduction of SMTP:
the SMTP client identified itself (HELO), and you were allowed to barf if the HELO claimed to be yourself since that meant that the network was in loopback.
HELO not only survived, but also a trend emerged as it started to be used as a weak authentication mechanism. People started checking whether the IP addrees of the connecting machine and the argument supplied with HELO had matching A and PTR RRs. This lead to the RFC 1123 prohibition:
However, the receiver MUST NOT refuse to accept a message, even if the sender’s HELO command fails verification.
This prohibition stands even with the current SMTP specification (RFC 5321):
Information captured in the verification attempt is for logging and tracing purposes. Note that this prohibition applies to the matching of the parameter to its IP address only
This is not to be interpreted as that no connection can be rejected based on the argument supplied with HELO. This thread over at RFC Ignorant discusses such valid cases where rejection is possible.
So there, now you not only know the history of HELO and why it was invented, you also know that it is not needed since 1983.
→ SMTP servers should not require, or ascribe meaning to, HELO or EHLO.
Managing organized complexity 
I think the next to last link in the post is incorrect. You mention it leads to a thread on rfc ignorant but it leads to a javascript implementation of QBasic!
This is what happens when you simultaneously tweet and blog post :) It was spotted earlier by @stsimb and I have updated the post with the correct link. Just in case, the correct thread over at RFC Ignorant is this one.