ietf-smtp
[Top] [All Lists]

RE: domain name definition in RFC2821

2006-04-22 12:30:19

(For instance, on my Fedora Linux box, the default resolv.conf
setting of 'options ndots:1' means that 'ws' will be
canonalized to a FQDN, while 'ws.' will behave the way Yuri
apparently expects 'ws' to work.  Now try to explain to your
average end user why 'postmaster(_at_)ws' and 'postmaster(_at_)ws(_dot_)' do
different things....

That is, indeed, an issue.

That's an understatement comparable to saying the Pacific Ocean is a little
wet.

The situation here at Sun is a good example. There's a vast infrastructure that
makes heavy use of short form names. Considerable effort has been expended to
switch away from, say, ned(_dot_)freed(_at_)west to FQDN forms like 
ned(_dot_)freed(_at_)sun(_dot_)com(_dot_) But
an essential ingredient in making this work is to canonicalize short form names
into FQDNs. And this applies not only to email but also to web services.

It you told the folks in SunIT that, say, postmaster(_at_)ws needs to work
"correctly" my guess is they'd just about fall over laughing. And they'd only
laugh harder if you pointed out that the current behavior is a standards
violation.

I've dealt with dozens of other companies with email setups of comparable scale
to Sun's, and I can tell you that plenty of them make extensive use of short
form name canonicalization. And some of them do stuff in this space that makes
what Sun does look _rational_.

Add to this the fact that many systems besides Fedora Linux are set to
canonizalize short form names out of the box, and I'm afraid this particular
genie is not going back in the bottle.

There are lots of standards battles worth fighting. This IMO isn't one of them.

                                Ned