outdated thinking about domains and hosts

Some of the arguments being put forth here about the use of AAAA records 
as fallback for missing MX records seem to be based on a very old and 
long-obsolete idea of the relationship between domain names and hosts.
Many years ago, it used to be the case that a domain name was the name 
of a host.  More precisely, a domain name was associated with a host's 
IP address, and the vast majority of hosts had exactly one network 
interface and one IP address.  In that world, it was easy to think of 
the host and domain and IP address as all being more-or-less pointers to 
the same thing.
Of course, in those days the vast majority of hosts were also multi-user 
timesharing computers.  Hosts were expensive and because of this it was 
generally expected that a host would serve a community of users rather 
than a single user.  So it was natural to think of a community of users 
as having a host that provided computing resources, and to associate 
that community with the host's domain name and an IP address.   Several 
of the early Internet services were built around the idea of being able 
to remotely access a user's resources or information on a host: finger, 
ftp, telnet, and of course email.
The first nail in the coffin of this idea was RFC 974.  The introduction 
of MX records broke the host=domain=address relationship because MX 
records allowed email to be sent to hosts that were not even connected 
to the Internet.  More generally, MX records made it possible to create 
domains for use in email addresses that didn't correspond to any actual 
host anywhere.  All that mattered was that the primary MX servers for a 
domain knew what to do with mail that was sent to a user at that domain.
Since then a number of things have further weakened the 
host=domain=address relationship:
- As the Internet grew, in order to make various services scale to 
handle the demand, it often became necessary to implement a service with 
 large numbers of host that shared a single domain name - or even 
sharing a single IP address using special-purpose load-sharing NATs.
- Eventually it was realized that it was very convenient to associate a 
service with a domain name (say for marketing purposes or ease-of-use) 
even when the service required only a small fraction of the resources 
available on a single host.  The result was what is known as "virtual 
hosting" where a single host provides services that are associated with 
a large number of domains, at much lower cost than would have been 
required to provide a separate host for each domain.  Extensions to HTTP 
 made it possible for a web server to handle requests for URLs in 
different domains even though they were associated with the same IP 
address.  Other workarounds have been found for other protocols (e.g. 
the common POP/IMAP/FTP convention of using usernames of the form 
"user(_at_)domain" during login).
For similar reasons, it is now common for a single host to be accessible 
via multiple IP addresses.
- SRV records further weakened the relationship between domains and 
hosts by allowing that relationship to be specified on a per-service 
basis, for application protocols defined to use SRV.
Today, the vast majority of references to a domain name, whether in 
email or in a URL or otherwise, DO NOT refer to a specific host. 
Domains are no longer equivalent or even nearly equivalent to host 
names, and haven't been for a long time.
----

How does this relate to AAAA fallbacks?  Simply this:

The argument that a host ought to be able to run email without 
registering an MX record for its domain is specious.  In general, a host 
does not have a designated domain name or even a designated address 
anymore.  Even a host as modest as a typical desktop PC can support an 
arbitrary number of services that are associated with an arbitrary 
number of domains.
Yes, there might be a domain associated with a host's IP address via DNS 
PTR lookup, but that's irrelevant because very few applications care 
what domain the PTR record points to.  Certainly email doesn't care, 
except for logging.  And quite often that domain is meaningless - just 
something provided by the ISP because certain stupid applications won't 
work unless there's a PTR record there.  (As if having a PTR record 
pointing to a meaningless domain name were an indicator of anything useful.)
One consequence of this is that the owner of a host isn't really 
prevented from running an email server on that host by his inability to 
write an MX record to any particular zone.  I see three cases:
1) The owner of the host also owns one or more domains that he can 
associate with the host, and he has write permission to the DNS zones 
for those domains.  He can create MX records for those domains.
2) Like case (1) but for some reason the interface to those DNS zones is 
dysfunctional and won't let him create MX records.  But since the owner 
of the host also owns those domain names, he can move them to other DNS 
hosting providers with less dysfunctional interfaces.  And DNS providers 
will get their act together when they realize they're losing business. 
problem solved.
3) The owner of the host doesn't own the domain name that someone has 
associated with that host.  In that case, the host owner simply doesn't 
have the right to create email addresses at that domain.  That right 
belongs to the domain owner.  The host owner can still run an email 
server on his host, he just can't insist that email addresses that are 
associated with someone else's domain should be handled by his host.

Keith