Apple provides a lot of autoconfiguration for their groupware (Mail, Address Book/Contacts, iCal Calendar) on their Desktop OS X systems and their mobile devices. However, some of this autoconfiguration was there before there were agreed-upon standards, which especially plagues Contacts and Calendar when working with the excellent SOGo groupware. Especially the AddressBook on OS X (Lion and Mountain Lion) can be rather shrewd until things work well.

Luckily, Apple supports Configuration Profiles aka .mobileconfig files, which can be created with the iPhone Configuration Utility (iPCU) or manually as XML property lists. However, the exact behavior of some of the fields remain unclear and thus it becomes more of an art than a science to create these files — not a recipe for ultimate success.

To make things easy, I created the iPhone/iPad/iPod touch configuration assistant for SOGo, which makes configuration a snap.

Information for users

1. Go to the SOGo autoconfiguration tool’s web page
2. Enter your full name and email address
3. Select the components you would like to install ^[1]Attention: Mail.app on OS X Mountain Lion ignores the email address given in the configuration and instead concatenates the login name and the IMAP server name, which is rarely what you want to see as the “From:” information in your mails. Unless your email address is of that form, you probably do not want to use this component. It works fine on iOS, though.
4. Download and install the so-created .mobileconfig
5. Enter your password once for each component as your device configures itelf (Hint: paste it, if there are more than two components)
6. Done. It has never been so easy to set up a new groupware account!

BTW: Your name and email address are only used to compose the profile according to your needs and will be forgotten immediately after returning the profile. ^[2]As your email domain is queried for their server configuration as part of the process, the part *behind* the @ sign could in theory be recorded by third parties, but the personally identifying part *before* the @ is kept secret.

Information for administrators

If you want to maximize your users’ experience, there is one thing you should do, and a few things which you can do. All of them are in line with the IETF Standards-Track RFCs on groupware autoconfiguration, so you probably should do them anyway soon.

Make CalDAV autoconfiguration work correctly

When importing a CalDAV profile on OS X, only the hostname, port and SSL status are considered, the path part of the URL is ignored. ^[3]Another one of the subtle hidden differences between the different Apple products which on the surface look like they are all of a piece. Another unnerving difference is that Contacts.app on OSX only supports a single CardDAV address book per account (unless it is an iCloud account…), but iOS happily deals with all of them. Instead, the path /.well-know/caldav is probed on the web server. If you are using Apache, then you can simply add these two lines to your site’s SOGo config

Redirect /.well-known/caldav  /SOGo/dav/
Redirect /.well-known/carddav /SOGo/dav/

or, if you already work with RewriteRules in that configuration,

RewriteRule ^/\.well-known/caldav  /SOGo/dav/ [L,R]
RewriteRule ^/\.well-known/carddav /SOGo/dav/ [L,R]

The carddav lines are not necessary, but when we are already at it, why not do a little more RFC 6764 compatibility? ^[4]Did you already have a look at the RFC and notice that it is edited by Cyrus Daboo, at Apple? Also, it is hot off the press, only a few months old.

Optional Configuration

The following host names are queried in the DNS for you mail address’ domain, the first match will be returned with the matching port:

• CalDAV/WebDAV: sogo (port 443)
• IMAP: imaps (with port 993), imap (port 143)
• SMTP: smtps (port 465), smtpauth (port 587), smtp (port 587)

If no match was found in the DNS, the domain name will be used plainly. No ports are probed. If you prefer a different hostname, it is easy and in accordance with RFC 6764 above and RFC 6186. ^[5]You noticed the editorship of Cyrus Daboo in this one as well? Just add the following lines to your DNS, of course pointing to the host names of your desire (it should not be a CNAME):

_carddavs._tcp   IN SRV 10 1 443 mysogoserver.example.com.
_carddavs._tcp   IN TXT          "path=/SOGo/dav/"
_caldavs._tcp    IN SRV 10 1 443 mysogoserver.example.com.
_caldavs._tcp    IN TXT          "path=/SOGo/dav/"
_submission._tcp IN SRV 10 1 587 mymailiin.example.com.
_imap._tcp       IN SRV 10 1 143 myimap.example.com.
_imaps._tcp      IN SRV 20 1 993 myimap.example.com.

You only need one of _imap._tcp and _imaps._tcp. The RFC recommends both (as well as _pop3._tcp and _pop3s._tcp), put into your site’s priority order, because a mail client should consider the joint priorities of all four these entries. So in this case, a client should use IMAP with STARTTLS on port 143 (priority 10) whenever possible, with IMAP over SSL on port 993 (priority 20) as a second option. The TXT records are not currently used by the autoconfiguration, but are useful to other autoconfiguration tools (RFC-compliant).

Aren’t SRV records just cool? You just have to love them!

A final word to administrators

Feel free to test the service, look at the resulting .mobileconfigs and make recommendations. If you like it, you can make a link to https://netfuture.ch/tools/autoconfiguration/?dom=your.mail.domain to your users. Like that, they will already have the domain part automatically filled in.

In addition, this might provide further components or options, as exemplified by the configuration page for the University of Konstanz, which can also serve VPN and eduroam configuration (and will also serve the certificates to make this seamless, if needed).