--On January 7, 2010 3:54:58 PM +0000 Tony Finch <dot(_at_)dotat(_dot_)at>
Frankly something akin to XRDS/Yadis (XML configuration file on an HTTP
server) would suffice (with perhaps something like XCAP in play too).
Couple that with the new .well-known URI mechanism
(<http://tools.ietf.org/html/draft-nottingham-site-meta-05>) and finding
a service would be as simple as doing an HTTP request on the primary
domain with request-URI .well-known/XXX.
You need a layer of indirection between the mail domain and the web
server, e.g. SRV or NAPTR, to accommodate sites like cam.ac.uk which do
not have a web server on their zone apex, or customers who delegate email
service to a service provider.
Why? Just setup an HTTP server at the domain that is used for email
addresses if you want this sort of simple configuration to work. If one is
there already just have it support .well-known or redirect to a server that
can support it.
In fact I have been thinking that one option here is to register
.well-known/srv and then any of the registered SRV service types could
have meta-data stored underneath that. e.g.:
MUA configuration should be in one file. If you split it up by protocol
then it is too easy to perpetuate problems with POP vs. IMAP
Well the XML data for imap, pop3 and submission could list all the
available mail services in addition to the actual service requested so that
clients would only need to do HTTP request. Or we could just define
.well-known/mail-service and have it all there.
If data needs to varying on a per-user basis, then defining a simple
RESTful api to include the userid in the request would be easy.
The MUA doesn't have a userid at this point: it only knows an email
By userid I meant whatever identifier the user is expected to enter in
their client. If something like Kerberos is in use, users may not even have
to enter anything.