Configure MAPI to use non-standard ports

Question asked by Seph Parshall - 7/6/2020 at 7:21 PM

Unanswered

I'm trying my best to jump thru hoops to configure MAPI for my clients in a way that I can keep them segregated from each other. I do not want some of the clients to see other domains or customers in their SSL certificate in the case that they might be curious and download and view a cert. I do not want them to see other domains using their cert.

So my question is: In the interest of using IP addresses sparingly, has anyone out there configured their email protocols [IMAP, MAPI, SMTP] to use non-standard ports in order to bind more SSL certificates to a single IP address?

i.e.: SMTP SSL using ports: 465, 466, 467, etc. - each port on the same IP address and using different SSL certificate for each port -OR- MAPI using ports: 443, 444, 445, etc.?

I can easily do this in IIS - bind a different SSL certificate for different web sites using the same IP address. I wish I could do this with SmarterMail.

I'm also making the assumption that "Autodiscover" for MAPI would work if I configured the DNS record with the non-standard port.

6 Replies

Reply to Thread

Kyle Kerst Replied

7/7/2020 at 4:24 PM

Employee Post

Seph, while I'm not familiar with this specific scenario, I do know that you can leverage Lets Encrypt to set up a single certificate that will handle all of the configured domains per this post here:

https://www.smartertools.com/blog/2017/08/14-secure-smartermail-with-lets-encrypt

Once you have all of the customer domains added to IIS as bindings, Lets Encrypt/Certify will read in the domain names, then issue a request for a certificate that will support each of them. At that point your users can connect using the hostname specific to their domain and should not be aware of other domains other than by doing a deep review of the SSL certificate.

Additionally, MAPI/EAS/EWS require HTTP port 80 and HTTPS port 443 in order to function, so I believe this is your best bet in getting things working without a lot of extra hoops. Hope that helps!

Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com

Seph Parshall Replied

7/7/2020 at 4:37 PM

I've tried Let's Encrypt and understand how it works. I just didn't want any of the clients viewing the SSL cert and seeing other client domains. I can keep them separate on the IIS website, but there is no way to do this in SmarterMail - having multiple SSL certificates [one for each customer domain] and all of them use the same port and IP address [like it is possible on IIS].

I just wanted to see if anyone had used the workaround by having different domains/certificates use different ports that don't overlap. That seems to be the only workaround with SmarterMail if you want them to use the same IP address - for SMTP, IMAP and POP3.

It would be awesome if SmarterMail could do this like IIS. IIS responds if there is a binding for the hostname even if other hostnames are bound to the same IP address as each other and on the same port - in this case port 443.

echoDreamz Replied

7/7/2020 at 6:43 PM

I dont think it is possible. HTTP/the browser when it connects to a server states what hostname it is connecting for and IIS can easily determine what SSL certificate it needs to provide to the client. I dont believe POP, SMTP and the other non-HTTP-based protocols do this, so there is no way for SM to know what certificate to serve up.

echoDreamz Replied

7/7/2020 at 6:49 PM

https://wiki.dovecot.org/SSL/DovecotConfiguration#With_client_TLS_SNI_.28Server_Name_Indication.29_support Looks like it is possible with Dovcot, but support is limited to certain clients that support TLS SNI.

Sébastien Riccio Replied

7/8/2020 at 9:28 PM

Seph, while I'm not familiar with this specific scenario, I do know that you can leverage Lets Encrypt to set up a single certificate that will handle all of the configured domains per this post here:

For info, this uses Subject Alternative Name (SAN) to add additionnal domains to the same certificate, but this is limited to 100 domains per certificate, so it's not a real solution if you have 100+ domains.

If you need to have for example mail.<domain>, autodiscover.<domain> in your cert for each domaine, it will already divide the domains you can use in a single cert by 2, therefore "only" 50 domains.

I dont think it is possible. HTTP/the browser when it connects to a server states what hostname it is connecting for and IIS can easily determine what SSL certificate it needs to provide to the client. I dont believe POP, SMTP and the other non-HTTP-based protocols do this, so there is no way for SM to know what certificate to serve up.

Like you said, Dovecot supports SNI and it works quite well. We tried it using Dovecot in POP/IMAP/SMTP(submission) proxy mode in front of SmarterMail with SNI.

Dovecot does the SSL/TLS negotiation and serves the correct certificate if the mail client send the servername it connects to in the SSL/TLS handshake.

It needs a certificate per domain but there is no problem to handle this with certbot and a little bit of scripting.

However I think the best practices for these protocols is to have autodiscover configured to announce an unique servername for all domains, like for example mail.yourhostingcompany.com and have a certificate for this host and/or to give your customers this unique name as servername for pop/imap/smtp.

This prevent problems for mail clients that are not SNI compatible.

Sébastien Riccio System & Network Admin https://swisscenter.com

Employee Replied

7/27/2021 at 9:14 AM

Employee Post

Hello all,

I want to provide an update on the SNI feature request for SmarterMail. We have been in the process of implementing SNI in SmarterMail, along with dynamic certifications from SSL providers like Let's Encrypt or ZeroSSL. However, we ran into a limitation with the .NET Standard Framework that will not allow us to integrate at this time. To fully implement SNI support, it will require a transition to .NET Core.

.NET Core is on our roadmap and will also enable Linux integration for SmarterMail. Now that we've found that SNI requires it, it will urge us to move this up transition even more.

So, we are now reconsidering our plan for the remainder of the year and will share more information shortly. (The joys of constantly changing technologies!)

Thank you,

Back to Community Threads

Please leave this box unchecked

6 Replies

Reply to Thread

Tags

Related Knowledge Base Articles