Final remark on general email config improvements in R75.

When connecting to a mail server over SSL/TLS, it's not uncommon for the server to present a certificate that doesn't match its hostname.

In particular, this happens when a custom domain is used with a managed (shared) mail service. You'd grab a domain, set its MX to mx.domain, add CNAME for mx.domain to point at mx.mail-service and - voilà! - you are served with mx.mail-service cert when connecting to mx.domain.

Ultimately, this is a mail server mis-configuration issue - your MX should really be pointing at mx.mail-service. In theory this shouldn't be happening, but in practice it does.

To address this, it's now possible to specify the exact domain the app should be looking for in an SSL certificate:

In the above example, you'd simply set this field to mx.mail-service and that's it.

To make things a bit easier that app now also helps you to pre-populate this field with the actual domain from the server's certificate.

It does that when you send out a test email and the field is left blank. As you can see from an opening screenshot, the app will recognize the certificate mismatch and re-run the test, accepting any and all certificates. It will then make note of the domain in the cert and copy it into the "SSL domain" field for you.

Finally, setting "SSL domain" to * will effectively disable all certificate checks and force the app to accept any certificate that the server sends, even if it's an expired or a self-signed one.
Made by IO Bureau in Switzerland

Updates Newsletter
Blog & RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms