> > 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 [EMAIL PROTECTED], this would also match [EMAIL PROTECTED] 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