How to require secure connections for E-mail

IT_Architect

Verified User
Joined
Feb 27, 2006
Messages
1,114
Why do we need it?
With the ubiquitous nature of mobile devices in the hands of non-technical users, they are at risk of them compromising their log in credentials at at poorly implemented or old technology hotspots. This translates into a problem for the hosting company when their credentials get into the hands of the spammers, the server gets blacklisted, and everyone else on the server are holding hosting company responsible for the service interruption. Moreover, every time such an event occurs, it requires hours of time to determine if the problem is due to a bad form on their site or by compromised credentials, and responding as necessary to the data center and spam lists to return the server to full usability.

The cert strategy:
1. Use the server's snake oil cert.
2. Buy a low cost cert from a CA
I went with number number two. However, I encourage the user to use their own domain as usual in their E-mail clients, and then against the warning, install the cert. The advantage is you can move their domain to a different server, and the users won't have to change their E-mail client settings. They would simply need to accept the certificate again. If they were to use the name of the server's cert, if you move them to another server, every device in the company would need to have their E-mail clients edited to reflect the new E-mail server. Where the problem comes in some software will only allow the cert to work for a day, or until you reboot. Then they have to re-accept. Instead of getting annoyed every day, they can edit the mail server in their E-mail client to reflect the name of the CA server cert.

The changes:
Secure Web Mail (http)
Credit goes to zEitEr for this one. Add near the bottom of the /etc/httpd/conf/extra/httpd-includes.conf the following:
Code:
################################################################################
#                          Mod_Rewrite
################################################################################
<location /phpMyAdmin>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /webmail>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /squirrelmail>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /roundcube>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /atmail>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
- Restart Apache

Secure Dovecot (POP3 & IMAP)
- ssh in as root
- cd /etc/dovecot
- cp dovecot.conf dovecot.conf.ssl
- Edit /etc/dovecot.conf.ssl
- Change:
Code:
disable_plaintext_auth = no
to
Code:
## Begin Change
disable_plaintext_auth = yes
## End Change
- mv dovecot.conf dovecot.conf.orig
- cp dovecot.conf.ssl dovecot.conf
- Restart dovecot

Secure Exim (SMTP)


SpamBlocker 4.5.3+, put the #Change Begin to #Change End code into this file
Code:
/etc/exim.acl_check_recipient.mid.conf
and no need to edit the exim.conf directly.

OR

older SpamBlocker.exim.conf.2.1.1-release 05-Jun-2007. Open /etc/exim.conf and find the following block of code:
Code:
# to block certain well known exploits, Deny for local domains if
# local parts begin with a dot or contain @ % ! / |
  deny  domains       = +local_domains
        local_parts   = ^[.] : ^.*[@%!/|]
and place this directly below it:
Code:
[B]# Change Begin[/B]
# Prevents unencrypted mail submission.
  drop
          !encrypted     = *
          authenticated  = *
          message        = Your connection must be encrypted.
          log_message  = Connection from \
                          [$sender_host_address]($authenticated_id) was \
                          not encrypted.
# Change End
The code that should show directly below this is:
Code:
# to restrict port 587 to authenticated users only
# see also daemon_smtp_ports above
accept  hosts = +auth_relay_hosts
        condition = ${if eq {$interface_port}{587} {yes}{no}}
        endpass
        message = relay not permitted, authentication required
        authenticated = *
- Restart Exim

Other:
The # Change Begin and # Change End comments simply highlight your changes for when it becomes advantageous to move to a newer version of the configs. If you find any errors or omissions, let me know, and I'll correct them.
 
Last edited:
Thanks for this, IT_Architect.

Could you please be so kind as to let us know which of these will survive custombuild updates, which won't, unless we make custom templates, and which won't survive at all?

Thanks.

Jeff
 
>Could you please be so kind as to let us know which of these will survive custombuild updates, which won't, unless we make custom templates, and which won't survive at all?<

I comment my changes in everywhere and keep a .current so that I can easily migrate to a new version of a config if I want to, or something happens due to my own carelessness or an update surprise.

1. httpd-includes.conf will survive. It begins life as basically an empty file that DA includes specifically to preserve user changes through updates. It also loads late. It's where I do all of my tuning and overrides.

2. I've never had exim.conf get overwritten unless I've asked it to be.

3. Dovecot I've no previous experience making configuration changes to, so I had no basis for an opinion at to what will happen there.

Update: I found a server that needed an update in all three areas, Apache, Dovecot, and Exim. All configs survived the update. This is also consistent with my experience with DA updates. My update issues usually stem from custombuild NOT replacing the current configs.
 
Last edited:
Hello,

Thanks for the guide, it should be very useful for Admins.
I've added a link to it as point #16 in the basic system security

We can discuss the default settings, or options to have then enabled/disabled at install time in your other thread:
http://www.directadmin.com/forum/showthread.php?t=43504

Please keep discussion regarding these possible changes to the 43504 thread.
Any question regarding the use of this guide can be made here.

John
 
and what about non ecrypted mail submission?

Hello IT Architect

I do not understand why you recommend allowing only encrypted mail submissions, what about the servers that do not submit mail encrypted?

I had a few clients that tried to sent me mail with and that was rejected because it was not encrypted.

The rest the instructions make sense to me, why do you disallow unencrypted mail submission then?

Very curious Joris :confused:
 
Hello IT Architect

I do not understand why you recommend allowing only encrypted mail submissions, what about the servers that do not submit mail encrypted?

I had a few clients that tried to sent me mail with and that was rejected because it was not encrypted.

The rest the instructions make sense to me, why do you disallow unencrypted mail submission then?

Very curious Joris :confused:
I may be missing your point. The entire communication is encrypted between your users mail clients and your mail server when your mail box users send and receive messages, but the message on the disk is not encrypted on either end. When your mail server sends mail to another mail server, or when their mail server sends mail to yours, no authentication occurs between the mail servers, and neither the communication nor files are encrypted during transmission. If your data center were to put a packet sniffer on your server's switch, they could read every communication and message coming from another mail server. They could not read any communications from your mail box users. Thus, a hacker at a coffee shop or on a hospital network, etc., cannot eavesdrop on your mail box users communications with your e-mail server because those communications are encrypted.

Summary: If you set up your mail server to only accept secure connections from your mail box users, they will need to connect securely to access their mail. Whether or not your client's e-mail server also requires a secure connection for their mail box users is not relevant. You will be able to exchange messages either way.

Message encryption:
Message encryption is an entirely different matter. In this case, the message itself is encrypted between the source e-mail client and destination e-mail client, including when stored on the mail servers and when sent between the source and destination mail servers. This is not a web hosting function. This is something that your users must set up on their mail clients, and have their own personal certificates so they can read the messages. It is not commonly implemented except for very sensitive information. Since they are binary files when encrypted, scanning is not effective and they may end up in the spam/virus trap. However, message encryption does nothing to prevent your users from giving away their user name and passwords at the coffee shop after which spammers can use your mail servers for their own purposes.
 
Maybe one minor change to a nice secure addition:

Secure Dovecot (POP3 & IMAP)
- ssh in as root
- cd /etc/dovecot
- cp dovecot.conf dovecot.conf.ssl
- Edit /etc/dovecot/dovecot.conf.ssl

Because (at least on my CentOS installs) the /etc/dovecot.conf.ssl doesn't exist. Actually the /etc/dovecot.conf is a symlink to /etc/dovecot/dovecot.conf.
 
@IT_Architect:

From where did you get this:
Code:
# Change Begin
# Prevents unencrypted mail submission.
  accept  encrypted     = *
  drop    message       = Your connection must be encrypted.
          log_message   = Connection from \
                          [$sender_host_address]($authenticated_id) was \
                          not encrypted.
# Change End
According to one poster (see post #12 in this thread), this code prevents incoming email from Amazon Seller Services and other senders). What exactly does it do? Please give full details of how you came to find and use this as it appears it may not be a good idea to use it.

Thanks.

Jeff
 
Same point

This was my point too, the script requires all connections to be encrypted including the mail submission done by ANY MAIL SERVER SUBMITTING MAIL TO ANY EMAIL ADDRESS ON YOUR SERVER and not just the new emails send by your users.

As far as I understand it will stop you from receiving mail from users with a server that does not encrypt mail submissions. A possible example Amazon Sellers below but I had others too. This recommendation is still in the Basic System Security #16 so please can anyone review and clarify this.

@IT_Architect:

From where did you get this:

According to one poster (see post #12 in this thread), this code prevents incoming email from Amazon Seller Services and other senders). What exactly does it do? Please give full details of how you came to find and use this as it appears it may not be a good idea to use it.

Thanks.

Jeff
 
This was my point too, the script requires all connections to be encrypted including the mail submission done by ANY MAIL SERVER SUBMITTING MAIL TO ANY EMAIL ADDRESS ON YOUR SERVER and not just the new emails send by your users.
I'm not sure it does that; I'd think we'd get a lot of complaints if everyone's mailserver just stopped working if it worked that way.

Which you'd think it would, because all mailservers send mail between servers unencrypted on port 25, and use port 587 only for submitting mail which will go on to another server.

Hopefully DirectAdmin staff will look at this thread and reply.

Jeff
 
Hello,

The Exim step is likely going to vary as per differing needs of different Admins.
If I'm reading the Exim changes correctly, yes, it will force everything to encrypted.
This will block older mail-servers that do not support SSL from sending you email, so some Admins may not want to set this option in the exim.conf.
Note that if you skip the Exim step and keep the default, Exim will be able to accept either, but wont force encryption.
The other side of the argument is that any mail-server that doesn't support SSL should really get with the times.. but that's not in our control (unless we block them for being archaic and they have no choice)

Forcing port 587 to be encrypted would likely be acceptable, since it forces Users to use encrypted password (may be able to add a "condition" to the encryption acl, to only check 587).
However, it doesn't work if they still use smtp-auth on 25... it would only work if they do it on 25 (perhaps forcing all smtp-auth requests to use encrypted 587 would be a balanced, all-round solution)

John
 
I've found this, which would help, as it forces TLS for any sort of authentication, but still allows standard plain-text deliveries
Code:
auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}
http://www.exim.org/exim-html-4.20/doc/html/spec_13.html#IX968

Note that this will break squirrelmail and roundcube, since they send plaintext locally, eg:
RC: /var/www/html/roundcube/config/main.inc.php
Code:
$rcmail_config['smtp_server'] = 'tls://localhost';
SM: /var/www/html/squirrelmail/config/config.php
Code:
$use_smtp_tls = true;
John
 
Digging up an old thread but something has me stumped.

Code:
################################################################################
#                  		Mod_Rewrite
################################################################################
<location /phpMyAdmin>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /webmail>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /squirrelmail>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /roundcube>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /atmail>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>

When I implement this I'm getting a 403 for /webmail. https for /phpmyadmin is fine.

I have the following in httpd-alias.conf and works fine in http:

Code:
Alias /config /var/www/html/redirect.php
Alias /webmail /var/www/html/roundcube
Alias /phpMyAdmin /var/www/html/phpMyAdmin
Alias /phpmyadmin /var/www/html/phpMyAdmin
Alias /pma /var/www/html/phpMyAdmin

I have private_html sym linked to public_html in DA for this domain.

I've checked permissions and everything is fine. It's simply only when I go to https://domain.com/webmail that I get a 403.

I could use someone's brain cells on this as I've burned all of mine trying to figure this out.

Thanks.
 
I removed the Mod_Rewrite rules from the includes file and now it redirects to https and works fine.

I'm confused, have I missed something in some updates that already do this?

UPDATE: Nevermind, even though I had restarted httpd several times it was still redirecting to https but working ok. Now, suddenly, it won't redirect and I have to manually go to https://.... /webmail.

So basically, I still have the 403 Forbidden if I have the mod_rewrites in place and only for /webmail.... which doesn't make a bit of sense. Without the rewrites it https works fine but is not forced.

Still need some help dealing with the 403. I just wonder why it doesn't do this with /phpmyadmin?
 
Last edited:
And what do apache error logs (general and for particular virtual host) say?
 
First thing I checked and that's the crazy part... they don't show any errors. I tail -f all of the logs and got nothing.

Just doesn't make any sense...
 
Tried it again real quick and got the domain error log to give me a an error:

[Tue Jul 08 23:44:16.450032 2014] [core:crit] [pid 1610] (13)Permission denied: [client 99.191.37.110:49375] AH00529: /home/dogman/domains/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/dogman/domains/' is executable

There is no .htaccess file as it still has the default DA placeholder... index.html..etc in the public_html dir.

I ran ./set_permissions.sh all but that didn't fix it either.

Tried this.. no worky: http://help.directadmin.com/item.php?id=363

It may be something along these lines but this is brand new install: http://forum.directadmin.com/showthread.php?p=199700#post199700

Also... after restarting everything I'm getting this:

Forbidden

You don't have permission to access /webmail on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

and I'm still getting the Permission denied error above in the httpd domain error log.
 
Last edited:
Hello,

Test with this:
http://help.directadmin.com/item.php?id=532

in both the:
/home/dogman/domains/domain.com/public_html

and:
/var/www/html/webmail (whever it's pointing to)

Things to check:
Code:
ls -lad /home/dogman
ls -lad /var/www

Lastly, if you've not already done so, try:
Code:
./build update
./build rewrite_confs
if the php type was changed at all, would need a rewrite.

John
 
[root@mail roundcube]# ls -lad /home/mailman/ drwx--x--x 9 mailman mailman 4096 Jul 9 02:50 /home/mailman/

[root@mail roundcube]# ls -lad /var/www dr-xr-x--x 9 webapps apache 4096 Jul 7 10:38 /var/www

and...


[root@mail roundcube]# ls -lad /var/www/html/roundcube lrwxrwxrwx 1 webapps webapps 19 Jul 8 17:59 /var/www/html/roundcube -> roundcubemail-1.0.1

I went ahead and did another rewrite_confs and now it's worse....


Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator at [email protected] to inform them of the time this error occurred, and the actions you performed just before this error. More information about this error may be available in the server error log. Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

I sent you the test php info links.

I appreciate your help.
 
John hopped on our server and finally figured it out... very odd.

I was able to debug it down to the .htaccess file in the roundcube directory, to this line:

RewriteRule ^(?!installer)(\.?[^\.]+)$ - [F]

Once I commented it out, /webmail worked fine.

These 2 lines explain it's documentation, but still confused as to how that even applies:

# - deny access to files not containing a dot or starting with a dot
# in all locations except installer directory

Once removed, it worked.

I certainly appreciate his help, had me stumped for sure. I'm wondering if it's a fresh install issue with 1.0.1. I've updated my other servers DA via custombuild which include RC 1.0.1 and they work fine even with the same lines in the /roundcube/.htaccess files.

I'd love to know why...
 
Last edited:
Back
Top