How to automatically configure email (Thunderbird, Outlook, and iOS/OSX Mail) with Nethserver

v7
mail

(Dan) #1

In an earlier thread, I discussed using static configuration files in a virtual host to automate configuration of your users’ email clients, with techniques that will work with Thunderbird, Outlook, and compatible email clients. One notable limitation of that method is that it does not work for iOS/OSX mail, so your Apple users will still need to configure their mail clients manually.

Here, I’m going to cover installation of automx, a small web tool which will generate the same configuration information for Thunderbird and Outlook (and compatible client) users, and will also generate custom configuration files for your Apple users.

Caution: This module is in a pre-beta stage. It shouldn’t hurt anything, but may not behave as expected. If you notice unexpected behavior, let me know here and I’ll see what I can do.

DNS Configuration

Just as before, you’ll need to set a couple of DNS entries. Since every DNS host is different, I can’t walk you through the details of this, but you’ll need to set two records:

  • You’ll need to set a CNAME or A record for autoconfig.yourdomain pointing to your Neth server.
  • You’ll need to set a SRV record for _autodiscover._tcp.yourdomain pointing to 0 0 443 autoconfig.yourdomain.

TLS Certificate

You’ll need to update your TLS certificate to include a hostname of autoconfig.yourdomain, in addition to any other hostnames it may already include.

Installation

Now you’re ready to install automx. First, you’ll need to have my repo configured; see the wiki for instructions. Then simply install nethserver-automx:

yum --enablerepo=danb35 install nethserver-automx

At this point, if you’re only concerned about Thunderbird and Outlook, you’re done. Automx will listen for autoconfiguration queries from either of those clients and respond appropriately. But if you want to use automx for iOS/OSX mail, there’s some more work to do.

iOS/OSX Mail

iOS/OSX Mail is configured by downloading and installing a profile, contained in a small file with an extension of .mobileconfig. Automx will generate these profiles, and optionally it will also cryptographically sign them. Signing the profiles is encouraged–your users’ devices will complain loudly before installing an un-signed profile.

Signing profiles

In order to sign the .mobileconfig files, automx must have access to a trusted certificate and the corresponding private key. For security reasons, this should not be your main server certificate. Rather, you should have a separate certificate for just autoconfig.yourdomain. Create a directory at /etc/automx/, and place the full chain and private key files there as fullchain.pem and privkey.pem, respectively. Then, do:

config setprop automx SignMobileconfig enabled CertPath /etc/automx/fullchain.pem KeyPath /etc/automx/privkey.pem
signal-event nethserver-automx-update

Your automx installation is now configured to sign the .mobileconfig files

Web forms

Now that your server will generate and sign the .mobileconfig files, you need to give your users a way to get those files. You’ll do that by giving them a web form into which they’ll enter their name, email address, and password, and click to download the profile. Automx provides such a form, or you can integrate your own into whatever web page you like.

automx-web

To install the default form, simply run

yum --enablerepo=danb35 install automx-web

This package includes forms in English and German; you’ll need to choose which one you want to present to your users. To use the English form, do:

cd /usr/share/automx
ln -s index.html.en index.html

Now, when your users visit autoconfig.yourdomain, they’ll see a form that looks like this:
image

Custom web form

If you don’t want the automx branding for your users, and/or you just want to put this into another page, you simply need to add the following HTML code:

      <form action="/mobileconfig" method="post">
	<input type="hidden" name="_mobileconfig" value="true" />
	<label for="emailaddress">Email address</label>
	<input name="emailaddress" id="emailaddress" type="email" placeholder="john.doe@example.com (mandatory)">
	<label for="cn">Full name</label>
	  <input name="cn" id="cn" type="text" placeholder="John Doe (optional)">
	</span>
	<label for="password">Password</label>
	  <input name="password" id="password" type="password" placeholder="Password (optional)">
	</span>
	<input type="submit" value="Request configuration!" />
      </form>

Of course, you can adjust styling, tool tips, etc. to suit your website. The look is up to you, but the input names have to stay the same.

TO DO

  • Test, test, test
  • See if I can get LDAP working as expected
  • Integrate the .mobileconfig form into the server-manager (or, better yet, into the user-manager that doesn’t exist yet)
  • Figure out why signing .mobileconfig files isn’t including the full certificate chain in the profile. This is causing the profiles to be marked as “unverified”.

How to automatically configure Thunderbird and Outlook email with Nethserver
We Are NethServer - Community Overview - Sep 18
(Stéphane de Labrusse) #2

Idea: you could retrieve the language needed by the nethserver rpm translation


(Stéphane de Labrusse) #3

we could have a chat one day on this.


(Dan) #4

It’s a possibility. Since the only options are English and German, though, I’m not sure it would be terribly useful. My own preference, in any event, is to have my own form rather than to use the automx-branded one.


(Markus Neuberger) #5

Great work! :clap:
I have no apple device but it worked well with Outlook except of it configures the full name to “prova”. I had no success with Thunderbird, it was autoconfigured as POP3.

I didn’t use the original domain name, I used another domain (where I am allowed to set SRV) so I had to tweak it a little bit:

I added some props…

config setprop automx ServerName autoconfig.domain.com
config setprop automx ServerAdmin webmaster@domain.com
config setprop automx ServerAlias autodiscover.domain.com

…and changed /etc/e-smith/templates/etc/httpd/conf.d/virtualhosts.conf/05autoconfig_vhost to use them:

my $servername = ${'automx'}{'ServerName'} || "autoconfig.".$DomainName;
my $serveradmin = ${'automx'}{'ServerAdmin'} || "webmaster@".$DomainName;
my $serveralias = ${'automx'}{'ServerAlias'} || "autodiscover.".$DomainName;

EDIT:

I found it has the letsencrypt bug - it’s not working because of the virtualhost.


(Dan) #6

Oops, bitten again–I’ll try to push out a fixed RPM tonight.

Edit: Should be available now.


(Thorsten) #7

Hi Dan,

there are days I feel small and insignificant. You made today such a day… in a positive manner: I was allways wondering why Thunderbird does not configure my e-mail accounts correctly out of the box. I was thinking of “my fault - I did not set up the thunderbird or myserver” correct. It did not even cross my mind that there might by an autotool for this. You did not only solve one of my issues, you also tougth me something new :slight_smile: … Works yout of the box, thank you so much.

As I do not know much on certificates and I do not want to make an error, can you explain / code this steps in more detail? Additionally, would this require an update if Letsencrypt certificates are renewed? I think there is some script provide by … do not rember, it was about using certificate for AD server … maybe same mechanism can be applied, too, will try to find it…

EDIT:

Best regards
Thorsten


(Dan) #8

I left that deliberately vague, as there are a number of ways you could use Let’s Encrypt with your Neth installation. But if you got your primary cert using the server manager, you should be able to just run certbot certonly webroot -w /var/www/html -d autoconfig.yourdomain --fullchain-path /etc/automx/fullchain.pem --key-path /etc/automx/privkey.pem. No events should be needed on renewal, and this cert should be renewed when your normal renewal task happens.

Edit: In case it wasn’t clear, you do need to create the directory first: mkdir /etc/automx.


(Thorsten) #9

Sorry for requesting futher help :slight_smile: :

   How would you like to authenticate with the ACME CA?
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    1: Spin up a temporary webserver (standalone)
    2: Place files in webroot directory (webroot)
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

… my letsencrypt certificate is valid for several vhost A records, e.g. autoconfig.mydomain, sogo.mydomain, www.mydomain, mail.mydomain as well as for AD (not exlusive list).

From details before, I suppose it is [1], as I set up an A record & collected an certificate update for autoconfig.mydomain.tld

TIA
Thorsten


(Dan) #10

You’d use option 2, webroot.


(Thorsten) #11

Tried that, but my apple phone reported an error for autoconfig. As it used myservername.myname.tld instead of autoconfig.myname.tld, I think there is an error for my SRV record. I will put this to my provider to set up correctly according to your requirements.


(Dan) #12

What error, exactly? I’ve seen some errors with properly signing the .mobileconfig file, but haven’t been able to track down the cause as yet. But the SRV record shouldn’t affect anything on an iPhone; it would only affect Outlook.


(Thorsten) #13

From Internal (green) Netwerk, it reports an Certificate Error reporting the DNS of Nethservers FQDN as invalid. I suppose it expects an Certificate for autoconfig.myname.tld instead of nethservername.myname.tld. I am wondering at as as no virtual host vor autoconfig.myname.tld is set up. However, I did not manage to fullfill all steps of installation procedure for iphone. Additionally, I am wondering, why I use option [2] - webroot - instead of autoconfig. Or is this because webroot meens any DNS not explicetly defined -> autoconfig.myname.tld = webroot as long no vhost ist defined?

From External source, no error is reported, it does simply not work. I leads me to manual configuration.

TIA
Thorsten


(Dan) #14

No, I don’t think that’s what’s going on. To autoconfigure an iPhone (or iPad, or the Apple Mail app on MacOS), you need to generate and download a .mobileconfig profile. You can do that by either creating your own web form (using the code posted above) or by using the automx-web package. iOS Mail will not auto-configure by just entering name/email address the way that Outlook and Thunderbird will.

If you’re getting a certificate error, it’s because the server is presenting a certificate that doesn’t match the hostname being requested. Your iPhone shouldn’t be requesting autoconfig.yourdomain, but even if it were, your main server cert should include autoconfig.yourdomain. I think I need to clarify those instructions a bit.

The nethserver-automx RPM sets up a virtual host for autoconfig.yourdomain, but it doesn’t appear in the server manager.

Because you have a web server running already. The standalone option would only work if you didn’t have one running.


(Dan) #15

In order for Thunderbird to autoconfigure for user@maildomain, autoconfig.maildomain must respond to queries with appropriately-formatted XML. Therefore, I’m thinking that this property:

isn’t really a good idea. Outlook can use any FQDN you want, as long as the SRV record is set appropriately, but if you want Thunderbird to work, you need to use autoconfig*.

*Well, there is an alternative for Thunderbird, which makes the XML available at maildomain/.well-known/(something), but automx doesn’t implement that.


(Thorsten) #16

Dear Dan,

Still does not work on my Iphone. Ok, my failure is that I mixed up the command you provided with the the manual copy step of certificates. I guess I will need to add the certificates: Which files do I need to copy in /etc/automx/

> config show automx
   automx=service
     CertPath=/etc/automx/fullchain.pem
     Debug=disabled
     KeyPath=/etc/automx/privkey.pem
     SignMobileconfig=enabled
     UseLdap=disabled

Edit:
Is there a missunderstanding? Initially I supposed to set up a user profile on my iPhone from “Accounts & Passowords” -> Add Account -> Exchange Account.
Indeed, I need to call autoconfig.mydomain.tld from Safari which resulted in a IMAP profile instead of an ActiveSync account

TIA
Thorsten


(Dan) #17

/etc/letsencrypt/live/autoconfig.yourdomain/fullchain.pem and /privkey.pem.

Yes, I think so–that isn’t at all the way you’d do it. The options are:

  • Thunderbird users: Create new email account, enter name and email address, and Thunderbird will retrieve the remainder of the account settings.
  • MS Outlook users: Same as Thunderbird–the backend mechanism works differently, but the UX is pretty much the same.
  • Apple Mail users (iOS or MacOS): Import the .mobileconfig file. Ideally that would be done by visiting the web form on the device in question, entering name/email/password, and clicking the button. This will let you open (import) the .mobileconfig file. Importing that configuration will create the email account with the name, email address, password, and all the correct server settings.

I understand there are other clients that implement either Thunderbird-style or Outlook-style auto-discovery, but I don’t know what they are.


(Markus Neuberger) #18

Thanks, lets encrypt is working now! :+1:


(Markus Neuberger) #19

My intention was to be able to change the domainname so I can have autoconfig.mydomain.com. The domain where I can setup SRV records is not the same I used as domainname on my server.

I’ll do some more tests with thunderbird and report back…

EDIT:

Now thunderbird just works! :+1:


(Dan) #20

Fortunately, Thunderbird doesn’t care about SRV records–they’re there only for Outlook’s benefit. To do automatic configuration with the method provided by automx, for a user user@domain.tld, Thunderbird needs to be able to connect to autoconfig.domain.tld and retrieve the appropriate XML configuration. Outlook, by default, will connect to autodiscover.domain.tld, unless it finds a SRV record telling it to look elsewhere. You could make Outlook work without the SRV record by setting up autodiscover.domain.tld to point to your server (and adding that FQDN onto your TLS certificate), but it seemed to me that the method I’m using was the simplest way to do it.