-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alex van den Bogaerdt wrote:
Julian Mehnle wrote:
And did you read:
"Unless the different characteristics of HELO must be identified
for interoperability purposes, this document discusses only EHLO."
?
Of course I did. This statement implies that, unless explicitly
specified otherwise, all specifications of EHLO in RFC 2821 don't
affect HELO. And since there is no explicit statement saying that
the semantics of HELO should change from RFC 821, HELO is not
affected by RFC 2821.
I was under the impression that EHLO and HELO are largely the same.
EHLO has extentions, HELO has not. EHLO is HELO+Extensions.
I read the quoted part above as:
Unless there is a difference between EHLO and HELO, only EHLO is
mentioned by RFC2821 but this also applies to HELO (again: unless there
is a difference).
I don't agree with this interpretation. Note that HELO is addressed in
RFC 2821 only as a legacy feature in order to provide backwards
compatibility with systems that only comply to RFC 821. It would not
make sense for RFC 2821 to modify the semantics of HELO from RFC 821.
I use RFC 2821 3.2 to show my point:
"In the EHLO command the host sending the command identifies itself;
the command may be interpreted as saying "Hello, I am <domain>"
(and, in the case of EHLO, "and I support service extension
requests")."
This can only be explained if the first EHLO ("In the EHLO command...")
talks about both EHLO and HELO, wereas the second EHLO ("...in the case
of EHLO, ...") talks about the difference between HELO and EHLO.
No, it really means just what it says. It talks about EHLO only. "For
the obsolete HELO command, see RFC 821" is implied.
Well, if you search for something like "HELO is not required to
contain a valid FQDN", then you're out of luck. There has _never_
been such a requirement for HELO, not even in RFC 821.
I think you are wrong.
RFC 821 3.7:
"Whenever domain names are used in SMTP only the official names
are used, the use of nicknames or aliases is not allowed."
Clearly this addresses cases like "example" in stead of "example.org.".
It also means CNAMEs aren't allowed.
RFC 821 4.1.2 (command syntax):
"HELO <SP> <domain> <CRLF>"
You can't read this as anything else than FQDN (a term introduced later
than RFC821 I think?)
Yes, you can -- many implementors of RFC 821 obviously did. <domain> is
defined in RFC 821 as follows:
<domain> ::= <element> | <element> "." <domain>
<element> ::= <name> | "#" <number> | "[" <dotnum> "]"
<name> ::= <a> <ldh-str> <let-dig>
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig> ::= <a> | <d>
<let-dig-hyp> ::= <a> | <d> | "-"
<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
<number> ::= <d> | <d> <number>
<snum> ::= one, two, or three digits representing a decimal
integer value in the range 0 through 255
<a> ::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
<d> ::= any one of the ten digits 0 through 9
This makes "SMTP", "#666", and "[127.0.0.1].microsoft.com" all legal
values for a <domain>.
Another problem is that RFC 821 does not use clear language with regard to
what features are optional or mandatory ("SHOULD", "MUST", etc.), so
while {FQDN,IP-address-literal} might be the most sensible interpretation
of what is allowed as an argument to HELO, this just is not what RFC 821
says.
Interpretation of RFCs is like interpretation of laws -- if something can
be misunderstood, rest assured that someone _will_ misunderstand it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDHE03wL7PKlBZWjsRArY6AKDkvgvspr74AleJp7yyInie+vy5TwCdFLq+
fnuaBw3MlHCWFE4tcsQtV7Y=
=GFf9
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://spf.pobox.com/
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com