Re: unencrypted mail problem

Hello Mehmet,

this is an easy topic.

Why this happens?
By RFC a SMTP server has to accept incomming unencrypted connections on 
TCP/25, as this is the default SMTP port. It depends on the server if 
and what features to support. Some may be configured to only accept 
mails from other servers, some may configured to only accept user 
connections (which today is done via TCP/465 and TCP/587), but usually 
pretty much anything the SMTP server is capable of is supported on this 
default port.
As E-Mail was invented when the internet still was just a research 
project and not many had even access to it, and standards like TLS were 
invetend decades later, even todays server which comply with the 
original SMTP accept unencrypted connections.
So, why does Google complain about an e-mail was dropped over an 
unsecured connection?
Although no user credentials are transmitted when one server drops a 
mail on another server the message body itself could contain data one 
might want to protected against eavesdroppers or modification.
To ensure that the mail isn't read or modified on the way between the 
sending server and the receiving one this connection can be encrypted 
the same way as a mail client can encrypte its connection to the server: 
StartTLS.
James does support to enable outgoing StartTLS via config. The file in 
question is <james-home>/conf/mailetcontainer.xml which, as by its file 
extension, is a structured xml file. Within it there's a section 
starting with
<processor state="transport">
Within the transport processor you will find this:
<mailet match="All" class="RemoteDelivery">
This section is responsible what happens when james has figured a mail 
has to go outbound to another server. To enable outgoing StartTLS just 
add this line:
<startTLS>true</startTLS>
In my config it looks like this:

<processor state="transport" enableJmx="true">
... some stuff
<mailet match="All" class="RemoteDelivery">
           <outgoing>outgoing</outgoing>
           <startTLS>true</startTLS>
... the rest

This way when james sees the StartTLS extension after EHLO it will use 
it to establish a secured channel before dropping in the mail. This will 
get rid of gmail complain about a mail was dropped in via an unsecured 
connection.
One note: For what ever reason it is important that the spelling is 
correct: It HAS TO be lowercase "start" and uppercase "TLS": "startTLS" 
- any other spelling will just be ignored or may throw an error at start up.

Does it increase the overall security? Well, the only thing you may 
protect against is that someone along the wire between your server and 
the nearest google mail server may read or modify the mail - but as it 
rely on seeing the starttls after EHLO anyone able to modify the 
connection can just drop it which will force james to use a regular 
unencrypted connection. There're some DNS records which could be used to 
enforce encryption, like DANE and others, but unless you use MTAs which 
make actual use of them and have domains providing the required records 
it's still just a possibility - there's no way to enforce encrypted 
connections yet. TLDR: If you want to secure your mails use something 
like S/MIME or PGP/GnuPG. StartTLS is just to secure the communication 
channel itself.


greetings from Germany,

Matt

Am 09.09.2020 um 16:35 schrieb Mehmet:
> Hi there, does anyone experienced unencrypted mail problem? We are sending to gmail but says unencrypted. we are using 3.5 dockerisied version. We tried some config changes but did not worked so far.
>
> Any help / professional support would be appreciated.
>
> Regards.
>
> Mehmet