ietf-smtp
[Top] [All Lists]

Re: Strict RFC x821 Compliant: HELO/EHLO

2005-07-04 18:56:03

Hector Santos wrote:

I'm hope Klensin is following the thread for consideration

For 2821bis it's ot strictly necessary, its domain-literals
are _always_ enclosed in square brackets.  IIRC dito STD 66,
but the latter is better:  No funny tag for IPv6, no leading
zeros (and therefore no questions about "octal" ;-), and no
CTL-chararacters in <IPvFuture>, the <General-Address-Literal>
in 2821 inherited the <NO-WS-CTL> nonsense from 2822.

security aspects, etc, to basically remove ambiguity
[...]
If ICANN do allow for numeric TLDs, in order to comply with
RFC 2821 Today, it could be allowed for number values over
255.  So for example, .911  will the following be possible:
 
        miami.911
        newyork.911
        houston.911

That's a horrible idea, do you know how many...

   if verify( arg( 1 ), '0123456789.' ) = 0
      then if SockGetHostByAddr( arg( 1 ), 'P.' )
              then return P.NAME ;  else  return ''
      else if SockGetHostByName( arg( 1 ), 'P.' )
              then return P.ADDR ;  else  return ''

...or similar constructs I have on my box ?  Many published
scripts, so it's not guaranteed to be only my box.  For an IP
one simple strategy is "if no GetHostByAddr() try it anyway".

That it won't work for IPv6 is documented elsewhere, but that
it cannot work for a numerical FQDN could be a security issue.

in my view, for proposals, like SPF and CSV to have any hope
of success in the future, the client domain name will have to
be clearly worked out, with some level of enforcement.

As far as RfC 2821 is concerned:  no square brackets => no IP,
and no dot => no FQDN,  For 2821bis John proposed to allow a
trailing dot for cases like FQDN ai. (= TLD is also a host).

For SPF and CSV I don't see any problems with the first rule:
(square brackets) <=> (IPv4 or IPv6 or IPvFuture).

before I can make the presumption the client domain is CSV
or SPF ready, I need to make sure it is syntax/value ready
first.

If you're not sure you're free to `nslookup -q=txt 127.0.0.1`
for an SPF result NONE.  That part of the SPF spec. made it to
two SPF Council reviews - roughly the same as an IESG [Discuss]
- until it was "correct" from my POV.  The old draft Lentczner
proposed a FAIL "malformed domain" for domain literals.

                           Bye, Frank