Setting up your email, either on your phone, or on a traditional desktop mail client (yes, some of still use those), used to be a real pain. You'd need to find the documentation from your email provider that told you which protocols they supported, which servers to connect to (that can be different for sending and receiving email), which port numbers to use, whether to use a secure connection (!), and then figure out where on your email client you needed to put all this information.
These days, it's much easier. There's a standard, RFC-6186, which email providers can use to publish the relevant settings as part of their DNS records. That way, email clients can look all of that information up just from the domain portion of your email address. Simples.
So why am I writing about it?
Well, before RFC-6186 was created, different email clients came up with their own methods of autoconfiguration. Normally, this was done by publishing the details, in a format they invented, in a special place on a website associated with the email domain.
Now, while the recent versions of these email clients are mostly capable of automatically configuring themselves with RFC-6186 style information, old versions of those email clients still exist in the wild. Also, users who are unable (for whatever reason) to upgrade to newer versions of software - like email clients - are probably the ones you want to be able to help the most. Therefore, supporting these legacy autoconfiguration systems would be really useful.
One principle widely regarded as important, or a "best practice" in software development and system administration, is Don't Repeat Yourself. Briefly, if you have multiple copies of some code or data somewhere, then if they ever need to change it's possible that they won't all be changed together. Copies can get out of synchronisation. Therefore, each piece of code or data should have one canonical location, and each other use should refer to that same one. That way, it's impossible for copies to get out of sync.
Hence, when setting up legacy autoconfiguration systems, they should not require their own copies of the email settings, but load the settings from the canonical RFC-6186 data as-needed.
The two most commonly-used legacy autoconfiguration methods I'm aware of (and the two I wanted to actually support), are Microsoft's Outlook, and Mozilla's Thunderbird.
Outlook's legacy autoconfiguration details can be found here, whereas Thunderbird's can be found here. They both involve fetching an XML file containing the settings from a given location on a website, but each uses a different XML schema, a different location, and sometimes a different website.
Fortunately, it's possible to generate XML files dynamically, while loading external information (like RFC-6186 records), without too much difficulty.
Enter emailautoconf, which I put together to generate those files in that way.
If you own the domain example.com
and have set up email for it, have
configured your RFC-6186 records appropriately, and are running a
website at https://example.com/
(note: no www.
) with the Apache2
web server and PHP, then setting up emailautoconf can be as easy as
grabbing a copy of the sources, installing it with sudo make install
,
and adding the following line to your Apache2 configuration file:
Include /usr/local/share/emailautoconf/apache2/main.conf
More information can be found in the
README,
including about how to configure it on the autoconfig
and
autodiscover
subdomains which are also specified by those
configuration systems.
Note that while emailautoconfig currently only supports the Outlook and Thunderbird legacy autoconfiguration systems, and the Apache2 web server, that's only because those are all I needed right now. I'm open to support other systems or webservers, if anyone is interested in contributing patches.
posted at: 16:31 | path: / | permanent link to this entry