[Top] [All Lists]

HELO/EHLO questions [was Re: New guy to this list..]

2005-05-11 08:13:04

----- Original Message -----
From: "Vijayan" <vijayan(_at_)jataayusoft(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Wednesday, May 11, 2005 9:52 AM
Subject: New guy to this list..

This is Vijayan from Bangalore,India, working as a Soft.Engr.
Presently i'm doing a project in a Mailing application.. my module is


I have some couple of doubts in SMTP standards..

You mean you have a couple of misunderstanding in the SMTP standards?  :-)

1. What is the actual difference between HELO and EHLO commands.. what is
use of these two different commands.. when to use which... and why..???

EHLO stands for "Extended HELO."

Extended SMTP (ESMTP) offers developers a way to add new features, commands
or keywords, etc.

For a standard HELO,  you don't except to see multiline responses:

    C: HELO <our client domain host name>
    S: 250 <your host domain name>, welcome string

When EHLO is sent, the response is usually a multi-line response that
exposes the "extended options available" by the server:

    C: EHLO <our client domain host name>
    S: 250-<your host domain name>, welcome string
    S: 250-SIZE 5120000
    S: 250-ETRN
    S: 250-AUTH=LOGIN
    S: 250 HELP

So the EHLO response contains keywords to tells the ESMTP compliant client
software what features are available at the ESMTP compliant server software.

Since ESMTP is optional,  legacy SMTP client systems will use the HELO

If a SMTP client system supports ESMTP, then it must use EHLO first, and
fall back to HELO if the remote hosting server does not recognize EHLO.

    C: EHLO <our client domain host name>
    S: 502 unrecognized command
    C: HELO <our client domain host name>
    S: 250 <your host domain name>, welcome string

 2. I had read in the RFC , that this commands (HELO/EHLO) r used to tell
is the Client SMTP the SMTP Server. (is it correct ??)..

If I understand your question,  I believe it is just a BCP (Best Current
Practice) and not a required standard where the the initial connection
server 220 welcome response string *may* include a tag "ESMTP" to indicate
this server is ESMTP ready, some like so:

        Incoming connection:
        S: 220 <your domain> [product name version ] ESMTP ready

But you can't rely on this and the standard for ESMTP clients is to try EHLO
first and fall back to HELO if EHLO is not supported.

then in that case even if i'm sending a command like

  EHLO 123 or EHLO junk / EHLO pheeeen"

it is accepting.. why..??

Because SMTP does not have real "strong" rules about the validity of the
helo/ehlo client domain name.

However, this is changing as part of the new era of client
authentication/authorization systems being explored.  So you are best to
follow the RULES and supply a valid client domain name.

To John Klensin:

This is what I am talking about the outdated specifications.  We need to get
them updated to guide and change the mind set for new developers.   The
spirit of the document has to mandate technical compliance and security
first in the new era.  We need to get server developers "more" authority in
enforcing the rules without being condemned.

This is the only way the new proposals are going to have a chance to be
effective.  It will take a while, but atleast we will have it written in

Hector Santos, Santronics Software, Inc.

<Prev in Thread] Current Thread [Next in Thread>