How to require secure connections for E-mail

FYI.. updated to RC 1.0.2 and Apache 2.4.10 today and ran in to the same issue... had to comment out that same line in /var/www/html/roundcube/.htaccess and add

Alias /webmail /var/www/html/roundcube

to /etc/httpd/conf/extra/httpd-alias.conf to access webmail again.
 
Last edited:
Didn't /etc/httpd/conf/extra/httpd-alias.conf have any webmail aliases in it? Also, what is your PHP mode set in CustomBuild?
 
It did... my changes, but blew them out after updating apache.

This is how it looks now:
Code:
[root@mail extra]# cat httpd-alias.conf
Alias /config /var/www/html/redirect.php
Alias /roundcube /var/www/html/roundcube
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 added the /webmail alias, the others were already there.

Relevant settings in options.conf
Code:
#PHP Settings
php1_release=5.4
php1_mode=mod_php
php2_release=no
php2_mode=php-fpm


#WEB Server Settings
webserver=apache
apache_ver=2.4
apache_mpm=auto
mod_ruid2=yes
secure_htaccess=yes
harden_symlinks_patch=yes
use_hostname_for_alias=auto
redirect_host=mail.mydomain.us
redirect_host_https=no

#WEB Applications Settings
phpmyadmin=yes
phpmyadmin_ver=4
squirrelmail=no
roundcube=yes
 
Last edited:
...

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)
...

John

I'm dealing with this as well, email from GoDaddy and a bank of mine being bounced because I'm forcing an encrypted connection. Also, forcing this is keeping a ton of backscatter type spam from being processed too..which is good. Guess spammers typically don't do encrypted submissions.

http://forum.directadmin.com/showthread.php?t=49439&p=254353
 
John hopped on our server and finally figured it out... very odd.



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...

I have the same issue, and it also works when I comment out that rewrite rule. I'm not using /webmail but just /roundcube

If I leave the line there I get this error with Forbidden:

AH00529: /home/myusername/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/myusername/' is executable

Where 'myusername' is the user I try to access roundcube under.
 
Secure webmail with NGINX

Why do we need it?

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

I'm running Nginx instead of Apache, does anybody know to apply this in a Nginx environment? I figured that I need to use a redirection like the one in this example:

Code:
server {
       listen         80;
       server_name    my.domain.com;
       return         301 https://$server_name$request_uri;
}

server {
       listen         443 ssl;
       server_name    my.domain.com;

       [....]
}

Is that correct? And if so where should I apply it?

Kind regards,

medieja
 
With exim.conf 4.4+, 4.5+ I believe you are open-relay due to this:


Code:
# Change Begin# Prevents unencrypted mail submission.
  accept  encrypted     = *
  drop    message       = connection is not encrypted, contact host
          log_message   = Connection from \
                          [$sender_host_address]($authenticated_id) was \
                          not encrypted.
# Change End


you accept all encrypted connections even without authentication. I'd try with:


Code:
# Change Begin# Prevents unencrypted mail submission.
  drop  !encrypted     = *
          message      = connection is not encrypted, contact host
          log_message  = Connection from \
                          [$sender_host_address]($authenticated_id) was \
                          not encrypted.
# Change End


Not much tested... a quick test shows it should work
with exim.conf 4.4+, 4.5+
 
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

This didn't work for me, unauthenticated TLS connections were still accepted.

I've come up with the following:
Code:
deny
   condition	  = ${if and{{eq{$interface_port}{587}} {eq{$tls_cipher}{}} } }
   message        = All port 587 connections must use TLS

# block connections on port 25 that are authenticated but do no use encryption
deny
   condition	  = ${if and {{eq{$interface_port}{25}} {eq{$tls_cipher}{}} }}
   authenticated  = *
   message        = All authenticated connections over port 25 must use encryption

This requires that connections on port 587 (and 465, because this one only accepts TLS connections by default If I recall correctly) use TLS.
Also, as discussed before you generally want to allow server-to-server traffic on port 25 that is unencrypted. Hence, the second ACL rule prevents authenticated users from using port 25 without TLS.
 
With exim.conf 4.4+, 4.5+ I believe you are open-relay due to this:


Code:
# Change Begin# Prevents unencrypted mail submission.
  accept  encrypted     = *
  drop    message       = connection is not encrypted, contact host
          log_message   = Connection from \
                          [$sender_host_address]($authenticated_id) was \
                          not encrypted.
# Change End


you accept all encrypted connections even without authentication. I'd try with:


Code:
# Change Begin# Prevents unencrypted mail submission.
  drop  !encrypted     = *
          message      = connection is not encrypted, contact host
          log_message  = Connection from \
                          [$sender_host_address]($authenticated_id) was \
                          not encrypted.
# Change End


Not much tested... a quick test shows it should work
with exim.conf 4.4+, 4.5+

I just noticed this same. With the config mentioned in the opening post, you are essentially allowing to be an open relay as long as the connection is encrypted.. very dangerous.
 
Thanks for the report. I've edited the first post to drop non-encrypted messages, but only for authenticated Users.
We don't usually want to block normal server-to-server transmissions based on non-encryption (you can if you want), as it may block email from remote servers that are not trying to encrypt the data. Ultimately, yes, it's more secure to enforce it for everyone, but the main goal is to prevent passwords from being sniffed, where that wouldn't apply to server-to-server transfers.

Anyway, your call if you want the "authenticate = *" in the first code block swap or not. I would likely add it there if it were my server.

John
 
Are these instructions still valid? Last update was 2018. Specifically, I do not have a /etc/exim.acl_check_recipient.mid.conf on this new server I just setup DA on with AlmaLinux. Should I just create it and add the suggested text?
 
Are these instructions still valid? Last update was 2018. Specifically, I do not have a /etc/exim.acl_check_recipient.mid.conf on this new server I just setup DA on with AlmaLinux. Should I just create it and add the suggested text?
With no answers from anyone and some of the files to be edited not even existing, we can probably safely say that these instructions are no longer valid.
 
Back
Top