-----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