On 5 Jul 2013, at 19:19, Alessandro Vesely <vesely(_at_)tana(_dot_)it> wrote:
On Fri 05/Jul/2013 19:03:57 +0200 Keith Moore wrote:
Yet, there seem to be quite some users who happen to download and
install MTA software on their laptops, unwittingly. It is not at all
obvious how to provide an even barely working default configuration for
that kind of thing, which leads to frustration. OTOH, it might
sometimes be handy to be able to exchange email messages across an
ad-hoc LAN, possibly disconnected from the rest of the Internet.
Yes, exactly. I do think it has potential uses, even for a client that is
otherwise unconfigured to send email across the public Internet. Of course,
the parallel question of how to send mail across the public Internet without
configuration is also interesting, but I imagine some anti-anti-abusers would
not like that thought much :-) .
All I'm saying is that there's a lot of existing and useful practice
which expects to be able to distinguish an alias (presumably without a
dot) from a FQDN. People shouldn't expect email to a domain name that
consists entirely of a TLD (any TLD) to work reliably. This is one of
a long list of reasons why vanity TLDs were a Really Bad Idea.
I'm neutral on this. I see no technical reason to ban dotless domains,
and no traction to make them work. Any chance we can catch some wind by
rocking the boat with mDNS?
I don't really understand the indifference. Well, actually, I don't really
understand the entire discussion, to be honest. (But also, I'm late to it,
sorry. :-) ) My Sendmail site set up in 2005 handles dotless domains by
design; all the domain search resolver magic is turned off. Why would anybody
be set against that? RFC 2821 language said I was supposed to expect dotless
domains (the text, anyway) so I did. It's also consistent with the use of full
email addresses. While I agree that advising people to depend on it would be a
bad idea, it's something that can be easily solved in code. I also don't see
why a name is any less significant for being a global one rather than a local
one, although I suppose that giving all that glory to the root isn't always
desirable either. Still, people should, as per spec, not be surprised when
unpredictable things happen if you use unqualified domain names, in either case.
As for mDNS, what's the trouble there? It should work just fine. Won't be
very secure, of course, but anyone in the local namespace should be able to set
up MX and address records to send mail wherever they'd like, at whatever
priority. It can be, at least in theory, the apex or any name underneath, and
if you have a resolver that knows to match "local" to mDNS, i.e. in practice
all of them, you just replace managing zone files with responding to the right
multicast messages, basically. For convenience, you put "local" in the domain
search list, and so it goes. (On OS X, this is actually implemented rather
better than glibc with the nss module, since the same process is responsible
for both DNS and mDNS, so searching actually works.)
Cheers,
Sabahattin
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp