Mailing List Archive

HELO vs. EHLO (was: Test suite update)
Julian Mehnle wrote:

>> Strict 2821 implementations could reject "HELO ws" and "HELO ws."
>> as SMTP syntax errors.

> I don't think this is correct. A strict interpretation of RFC 2821
> requires only the "EHLO" command -- not the "HELO" command -- to
> have an FQDN. (This is obviously due to RFC 821 _not_ requiring an
> FQDN with "HELO", and due to many legacy implementations not giving
> one.)

Please join the IETF SMTP list, the 2821-to-DS effort was restarted.

For the issue at hand, 2821 claims to obsolete 821, and a strict 2821
implementation would by definition do whatever 2821 says. There are
some cases where 2821 explicitly says "look into 821 for details".

| (However, for compatibility with older conforming implementations,
| SMTP clients and servers MUST support the original HELO mechanisms
| as a fallback.) Unless the different characteristics of HELO must
| be identified for interoperability purposes, this document discusses
| only EHLO.

The details are explained in section 4.1.1.1 (EHLO or HELO), and the
specified syntax is:

| Syntax:
|
| ehlo = "EHLO" SP Domain CRLF
| helo = "HELO" SP Domain CRLF

So the syntax is in essence identical, with the (in)famous "one dot":

| Domain = (sub-domain 1*("." sub-domain)) / address-literal

So why do you think that a strict-2821 server "should" (?) not reject
HELO ws / HELO ws. but would reject EHLO ws / EHLO ws. ? Somewhere
501 is explicitly mentioned as possible reaction after EHLO:

| If the EHLO command is not acceptable to the SMTP server, 501, 500,
| or 502 failure replies MUST be returned as appropriate.

Now I'm cheating and jump to 821, where the corresponding text is:

| If the HELO command argument is not acceptable a 501 failure reply
| must be returned and the receiver-SMTP must stay in the same state.

Clearly 501 is allowed after both HELO and EHLO, but this might be
about an EHLO or HELO in a state where it makes no sense.

John has posted "HELO" as open issue for 2821bis, so far no replies.

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735
Re: HELO vs. EHLO [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > > Strict 2821 implementations could reject "HELO ws" and "HELO ws."
> > > as SMTP syntax errors.
> >
> > I don't think this is correct. A strict interpretation of RFC 2821
> > requires only the "EHLO" command -- not the "HELO" command -- to
> > have an FQDN. (This is obviously due to RFC 821 _not_ requiring an
> > FQDN with "HELO", and due to many legacy implementations not giving
> > one.)
>
> Please join the IETF SMTP list, the 2821-to-DS effort was restarted.
>
> For the issue at hand, 2821 claims to obsolete 821, and a strict 2821
> implementation would by definition do whatever 2821 says. There are
> some cases where 2821 explicitly says "look into 821 for details".

RFC 2821:

| Abstract
|
| This document is a self-contained specification of the basic protocol
| for the Internet electronic mail transport. It consolidates, updates
| and clarifies, but doesn't add new or change existing functionality
| of the following:
|
| - the original SMTP (Simple Mail Transfer Protocol) specification of
| RFC 821 [30],

| 2.2.1 Background
|
| [...]
|
| Contemporary SMTP implementations MUST support the basic extension
| mechanisms. For instance, servers MUST support the EHLO command even
| if they do not implement any specific extensions and clients SHOULD
| preferentially utilize EHLO rather than HELO. (However, for
| compatibility with older conforming implementations, SMTP clients and
| servers MUST support the original HELO mechanisms as a fallback.)
| Unless the different characteristics of HELO must be identified for
| interoperability purposes, this document discusses only EHLO.

| 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
|
| [...]
|
| [...] Older client SMTP systems MAY, as discussed above,
| use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
| support the HELO command and reply properly to it. [...]


> The details are explained in section 4.1.1.1 (EHLO or HELO), and the
> specified syntax is:
>
> | Syntax:
> |
> | ehlo = "EHLO" SP Domain CRLF
> | helo = "HELO" SP Domain CRLF
>
> So the syntax is in essence identical, with the (in)famous "one dot":
>
> | Domain = (sub-domain 1*("." sub-domain)) / address-literal
>
> So why do you think that a strict-2821 server "should" (?) not reject
> HELO ws / HELO ws. but would reject EHLO ws / EHLO ws. ?

Because all of RFC 2821 is paved with hints that compatibility with "older
client SMTP systems (as specified in RFC 821)" is to be maintained. At
the time RFC 2821 was made, EHLO could be fixed (as it didn't exist
before), but HELO couldn't.

> Clearly 501 is allowed after both HELO and EHLO, but this might be
> about an EHLO or HELO in a state where it makes no sense.

Well, I as a receiver always reserve the right to reject anything for any
reason. But we were talking about strict interpretations of RFC (2)821,
so, no, you cannot invoke RFCs 821/2821 to justify a rejection of an
"invalid" HELO name.

> John has posted "HELO" as open issue for 2821bis, so far no replies.

That's very unfortunate, since I'm currently in the middle of exam
preparations (did you notice that I haven't been posting to the spf-*
lists for a few weeks?) and thus don't have the time to visit yet another
construction site. :-(

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGBkcpwL7PKlBZWjsRAtXbAJ9yqrnQXjnlv1Kr8WUObSbplDRmowCgjtwP
sy7cKuv03vqf9zDNaUFy7n0=
=lWoK
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735
Re: HELO vs. EHLO [ In reply to ]
Julian Mehnle wrote:

> all of RFC 2821 is paved with hints that compatibility with "older
> client SMTP systems (as specified in RFC 821)" is to be maintained.

Yes. At that time there still was a more or less "hardwired" list
of TLDs, and they weren't used as hosts. And "domain completion"
(host => FQDN) was (wild guess) more common than today.

> At the time RFC 2821 was made, EHLO could be fixed (as it didn't
> exist before), but HELO couldn't.

Nope, EHLO existed, see RFC 1869, a part of STD 10 (like RFC 821).
RFC 1869 obsoleted RFC 1651, that obsoleted RFC 1425, apparently
that's where they invented EHLO (1993).

RFC 2821 tried to consolidate the various pieces as they were, a
part in 821 (STD 10), another in 1123 (STD 3), a third part in
1869 (STD 10), and the RFC 974 stuff (I need to read that). With
pointers to the DSN RFCs, etc.

> I'm currently in the middle of exam preparations (did you notice
> that I haven't been posting to the spf-* lists for a few weeks?)

The lists were generally very quiet. "Exam preparations" sounds
pretty dangerous, good luck with that.

Frank
--
<strong lang="de"> Mut zur L&uuml;cke! </strong>


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735