OTOH, the converse is likely to be relevant to quite a lot of domains,
even if it does not apply to aol.com.
Really? Can you provide some examples of domains that use so many
subdomains for mail that it's impractical to cover the ones they use
individually? (Not counting wildcards, we know that's a swamp.) For
the domains I know, the mail comes from one or a handful of fixed
subdomains, and any random subdomain is bogus.
First of all, let me state up front that I have no skin in this particular game
and therefore don't feel strongly about this issue one way or the other.
That said, I do have a data point to offer here. Some years ago we inherited an
LDAP schema from a previous product incarnation. The schema was designed to
support complete provision of email through LDAP for ISPs and large enterprises
and it turned out to be surprisingly tricky and complex - when I first looked
at it I thought it was way too complex. But as I started seeing actual customer
usage I realized that most of it's capabilities were there for a reason. I also
realized that the attempt to standardize this sort of thing in the IETF (the
LASER project) was overly simplistic to the point of being of very limited
value.
One of the key features of this schema turned out to be uplevel domain
matching. For example, if there's a domain entry for example.com, subdomains of
example.com are also matched. (Or not - it turns out you want this to be
controllable on a domain-by-domain basis. And of course an explicit entry for
foo.example.com matches before the example.com entry does.) This in turn means
all it takes to create a subdomain is to have an address in a user entry
specifying that subdomain - very low overhead.
Now, I have no idea what limits were placed on this capability by provisioning
systems. What I do know is that several customers used this feature to create
very large numbers of subdomains. (I know this because this particular usage
exposed several bugs.)
Another thing that's surprisingly common is for sites to have very large
numbers of explicitly configured domains and subdomains - like on the order of
tens of thousands. (This one came to my attention because of an issue with
fetching all attributes of a domain from the directory server. It turns out
that there were some performance issues when virtual attributes or so-called
class-of-service attributes are used and there are lots of entries of the same
type as the one you are reading. This and several other factors led to a total
rewrite of our domain lookup code.)
It gets worse. Another characteristic of the original implementation of this
was that if a user's entry had an address of the form
user(_at_)example(_dot_)com, this
would also match user(_at_)foo(_dot_)example(_dot_)com for any value of "foo".
I thought this
was a bug so I didn't implement it. Mistake: At least one customer relied on
this feature to allow use of essentially arbitrary subdomains! I thought this
was stupid as hell at the time and still do, but the fact remains we had to add
support for it. (And yes, it is off by default.)
Want more? Another feature was so-called "virtual domains". These are domains
that only exist as attributes on user entries - there's no separate entry in
the directory for the domain at all. We ended up having to implement this as
well, but we've managed to wean most sites off of it, mostly because there are
some access control issues surrounding this model that are very hard to get
right.
Of course this is just my own experience. It may be the that the handful of
sites I have encountered doing this sort of thing are the only ones on the
planet that are doing it. Or it could be that this practice isn't all that
uncommon. I've pointed out previously the risks of assuming that our individual
experiences reflect any real understanding of what's out there.
FWIW.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html