Quite apart from anything else, this requires an email routing protocol.
Getting the policy statements right in such a protocol is a non-trivial
task; it will make BGP look simple, because of the implied liability a
mail sender would incur under this scheme.
Let me be very specific. I own a 1U server in a rack somewhere. (The
concept has been discussed here many times, of course; thanks to some
friends, I can actually do it.) How do I send email?
Well, maybe the colo operator has a mail server. Maybe the rack
operator has mail-forwarding contracts with his upstream IP (i.e., BGP)
peering providers. To whom can they send mail? More precisely, with
whom have they signed contracts that will let them deliver mail, and
under what conditions? Maybe one of the upstreams has better contracts
in some countries than the other does, or maybe the other will charge
me less for delivering my email, but with a hefty chargeback to me if
it's found to be spam. Or maybe one of them won't talk to (or listen
to) mailers in certain parts of the world -- we've seen that alleged
and/or bragged about on this list -- because of perceptions of where
spam comes from. But the better mail server I'd prefer to use is down
today, because of a fiber cut/DDoS attack/spam overload. How do I
know, and how do I fall back to an alternate?
We can all invent more scenarios. I think we can all see the analogies
to BGP, too -- and we all know how hard it is to get that to do what we
want.
The scheme you're suggesting might work without new protocols in a
purely hierarchical world. It might even work with a fully-connected
cluster of Tier 1s, each of which is a tree root. But the Internet
doesn't work that way, or we'd all be using EGP for routing.
Besides, as I mentioned the other day, there are policy side-effects.
See http://news.com.com/Your+ISP+as+Net+watchdog/2100-1028_3-5748649.html?tag=nefd.top
for an example of the kind of thing I'm worried about.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb