Can Dovecot reject unencrypted mail?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Can Dovecot reject unencrypted mail?

David Seaward
Hi,

Is it possible to configure Dovecot to reject mail that is not
encrypted. In other words:

1. If the user tries to send an unencrypted message from their MUA,
the server rejects it.

2. If a third-party tries to send an unencrypted message to the user,
the server rejects it.

The end result would be that no mail stored on the server can be
decrypted by the administrator.

I am aware that:

* "Encrypted" could mean a lot of things. I'm imagining GPG
encryption, but am open to other supported methods.

* This configuration would not suit everyone, e.g. someone posting to
a public mailing list :)

Regards,
David
Reply | Threaded
Open this post in threaded view
|

Re: Can Dovecot reject unencrypted mail?

Aki Tuomi-2

> On January 10, 2018 at 2:08 PM David Seaward <[hidden email]> wrote:
>
>
> Hi,
>
> Is it possible to configure Dovecot to reject mail that is not
> encrypted. In other words:
>
> 1. If the user tries to send an unencrypted message from their MUA,
> the server rejects it.
>
> 2. If a third-party tries to send an unencrypted message to the user,
> the server rejects it.
>
> The end result would be that no mail stored on the server can be
> decrypted by the administrator.
>
> I am aware that:
>
> * "Encrypted" could mean a lot of things. I'm imagining GPG
> encryption, but am open to other supported methods.
>
> * This configuration would not suit everyone, e.g. someone posting to
> a public mailing list :)
>
> Regards,
> David

You can make a global Sieve script that will e.g. pipe your email to some verification script. Or you can use some header based checks. This is probably not very simple thing to do.

Aki
Reply | Threaded
Open this post in threaded view
|

Re: Can Dovecot reject unencrypted mail?

Ryan Beethe
In reply to this post by David Seaward
Hi David,

I don't know how to do what you want with dovecot, but what you are
asking is easy and straightforward with Postfix.

Postfix can easily be configured to feed mail through a milter ("mail
filter") interface.  You would just need to write a milter (there is a
nice python library) that checks if the messages is "encrypted" to your
specifications and tells Postfix to bounce the message if its not.  This
would be a nice backscatter-free solution.

After you have the milter written, you specify it with the
"smtpd_milters" option for Postfix.

Ryan

On Wed, Jan 10, 2018 at 02:08:38PM +0200, David Seaward wrote:

> Hi,
>
> Is it possible to configure Dovecot to reject mail that is not
> encrypted. In other words:
>
> 1. If the user tries to send an unencrypted message from their MUA,
> the server rejects it.
>
> 2. If a third-party tries to send an unencrypted message to the user,
> the server rejects it.
>
> The end result would be that no mail stored on the server can be
> decrypted by the administrator.
>
> I am aware that:
>
> * "Encrypted" could mean a lot of things. I'm imagining GPG
> encryption, but am open to other supported methods.
>
> * This configuration would not suit everyone, e.g. someone posting to
> a public mailing list :)
>
> Regards,
> David
>
Reply | Threaded
Open this post in threaded view
|

Re: Can Dovecot reject unencrypted mail?

Jochen Bern-2
In reply to this post by David Seaward
On 01/10/2018 01:08 PM, David Seaward wrote:
> Is it possible to configure Dovecot to reject mail that is not
> encrypted. In other words:
> 1. If the user tries to send an unencrypted message from their MUA,
> the server rejects it.
> 2. If a third-party tries to send an unencrypted message to the user,
> the server rejects it.

a) In a typical setup, neither of these two services uses dovecot.
b) In order to be able to exchange encrypted e-mails, the two parties
   need to exchange their public keys / certs beforehand. Which is
   usually done by - signed, but not encrypted, on purpose - e-mail.
c) Any other mail server the user has an account on can be used to
   circumvent your securing scenario 1, at least for a large number
   of recipients.
d) You're breaking pretty much every sort of autoreplies on this planet
   for your users.
e) Checking an e-mail for *every* sort of encapsulation that encryption
   may use is not quite trivial. Making sure that *the recipient* can
   actually decrypt it is impossible, as you assume that the system
   does *not* hold the recipient's private key. Nailing it down so that
   *only* the recipient can decrypt it (when the sysadmin might fool
   the sender into encrypting it for one of *his* pubkeys as well)
   should be quite a while of fun, too.

What I *have* done, in postfix, is to take every (single-recipient)
delivery to our own domain, look up a map that tells me whether the
server has a PGP/GnuPG, S/MIME, or neither type of pubkey/cert on
record, encrypt the incoming mail in the first two cases, and log a
warning (and allow the mail to pass unchanged) in the latter. Mind, that
was on peripheral mail servers where I could *assume* the mails not to
already be encrypted, not the actual MX. Also, keeping the map and
pubkeys updated didn't come for free, either, even though I'm the one
handing our staff their S/MIME certs in the first place.

Regards,
--
Jochen Bern
Systemingenieur

www.binect.de


smime.p7s (5K) Download Attachment