On Mon, Jul 07, 2008 at 12:25:09PM -0400, John C Klensin wrote:
>
>
> --On Monday, 07 July, 2008 10:30 +1000 Mark Andrews
> <[EMAIL PROTECTED]> wrote:
>
> >...
> > If / when MIT stop using ai.mit.edu, "[EMAIL PROTECTED]" will not longer
> > mean [EMAIL PROTECTED] This will mean that any configuration
> > file that has "[EMAIL PROTECTED]" will now, suddenly, get a different
> > meaning. This is a latent security issue.
>
> Mark,
>
> While I'm basically sympathetic to the position you are taking
> on this, we have recommended for years and years (since the CS.
> incident, if not earlier), that things like configuration files
> use FQDNs and only FQDNs. SMTP imposes the same requirement on
> addresses in MAIL and RCPT commands.
>
> If [EMAIL PROTECTED] is in a config file with the intent of identifying
> [EMAIL PROTECTED] then the config file is broken. Conversely,
> if the config file format is intended to permit references to
> TLDs, I would hope that it would be possible to write "ai." if
> the TLD were intended.
>
> Personally, I'm very concerned about what users type and what
> happens after that. For configuration files and the like, I
> believe that we have a case of bad design if the interpretation
> of the configuration is dependent on things outside the scope of
> that file and, in particular, if there is a dependency on DNS
> search procedures rather than one explicit FQDNs.
>
> Quoting from your comment about Firefox, "Two wrongs don't make
> a right. They just make two things that need to be fixed."
>
> john
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
John, do you beleive that DNS host semantics/encoding that form the bulk
of the IDN work (stringprep, puny-code, et.al.) are applicable -only- in
the context of zone file generation or are they also applicable in
configuration and acess control for DNS?
path/alias expansion/evaluation will be interesting if "." is not what
7bit ASCII thinks of as "."
--
--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
