Pat and I had a good talk the other day about aliases, which I think was triggered from another conversation he had. Hula promised an Alias Agent from about day one, and it never arrived – and it is a big feature a lot of people want. “Group Objects” were misused to attempt to provide this function: I’m not totally sure the difference between a Group and an Alias, except that one relationship was potentially one-to-many.

There is also a lot of complexity to these things, notionally, with a hierarchical configuration store – like an LDAP directory – which, to my mind, results from data being put in the wrong place. For example, LDAP accounts usually have an associated e-mail address, but there is no particular guarantee that any mail system providing that user’s mailbox will accept mail for that address – you have to set it up so the two match. And when you come to see if an e-mail address is valid, you have a lot of searching to do – adding e-mail addresses and aliases to the user object isn’t great from the system point of view, and neither from the point of view of the administrator does it make much sense. Seeing which addresses a user “has” is useful admin UI, but you also don’t want to hand those things out without reference to the other addresses which exist.

Let’s talk about Bongo. If we do leave MDB behind, we do need a plan for how this kind of thing will work (I console myself that while this feels like re-writing, it isn’t really, because we don’t have this functionality right now). Here is what I’m thinking right now.

First, I think there is value in having a concept of a “canonical e-mail address”. Any user with something in our store will have one, and only one, of these. And in general, I see this as something that would come out of our auth layer: that would store (Username, Password, Real name, E-mail) primarily, which matches pretty well what real-world auth sources have (where it doesn’t know the e-mail, it will make one up based on the username and global domain, I think).

We then need a kind of map, which is just a list of e-mail addresses. It would be similar to /etc/aliases, and you would be able to map any address onto one or more canonical or foreign addresses. This gives you aliases, groups and forwarding – pretty much most everything we want. Part of this map could be partly automated – e.g., the global domain permutations – others would be setup by administrators against domains (either global or hosted).

This mapping system I don’t see as being part of the auth system – it’s completely dissociated, really. Probably it ought to go into the store, as part of QSTOR or something.