On Mon, Sep 05, 2005 at 03:50:46PM +0200, Julian Mehnle wrote:
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 didn't mean that RFC2821 modifies HELO. I am saying that RFC2821
has an implicit "or HELO" every time the reader sees "EHLO", unless
it is made clear that the RFC only talks about the new form.
And RFC2821 _DOES_ define HELO, as the document is "a self-contained
specification" which "obsoletes RFC 821".
Read the abstract in RFC 2821.
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.
It does, indeed, mean what it says. A distinction is made between two
cases. Only the new form of the command has "and I support service
extension requests". It does not refer to RFC 821, after all this
RFC is to be obsoleted by 2821.
They could have done it the other way around: Mention HELO (and the
reader should add an implicit EHLO) unless it was really EHLO specific.
This sentence would then have read:
"In the HELO 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")."
Note how I changed the first ehlo, not the second.
They probably didn't do it this way because people would never stop
using HELO otherwise.
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:
Yes, address literals, inbetween brackets, are allowed.
Yes, the less seen form "# <number>" is allowed (in RFC821 only).
I remind you of your statement, 2005-09-03:
" Actually only EHLO is required to be a valid FQDN, HELO isn't.
Read RFC 2821 carefully.
"
By your own reasoning, RFC2821 would forbid address literals. You didn't
mean to say that, I know, because we were talking about a specific
subject. Well, so was I.
My point is: it is not allowed to use arbitrary strings. If the FQDN is
"smtp.microsoft.com" then it is not allowed to say "HELO smtp".
The example in RFC2821 (...nothing more than a local alias...) clarifies
what was already specified in RFC821. It is not new.
This makes "SMTP", "#666", and "[127.0.0.1].microsoft.com" all legal
values for a <domain>.
No. That is not allowed. You are mixing up syntax and semantics.
"[127.0.0.1]" needed to be added because that is allowed. Unfortunately
this was done in a poor BNF.
Simplified example:
English words could be expressed as: word ::= <c> | <word> <c>
where <c> is defined as "a" to "z", plus "'"
It does mean that >>>can"t<<< isn't valid.
It does not mean >>>qnsnkjwrhq<<< is an English word.
There are more rules, described elsewhere, that do not (easily) fit in BNF.
Just above the part you quoted, I find this:
Hosts are generally known by names which are translated to
addresses in each host. Note that the name elements of domains
are the official names -- no use of nicknames or aliases is
allowed.
Sometimes a host is not known to the translation function and
communication is blocked. To bypass this barrier two numeric
forms are also allowed for host "names". One form is a decimal
integer prefixed by a pound sign, "#", which indicates the
number is the address of the host. Another form is four small
decimal integers separated by dots and enclosed by brackets,
e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
Address in four 8-bit fields.
Clearly, "[123.255.37.2]" is not ment to be appended by s domain.
Alex
-------
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