Can Dovecot reject unencrypted mail?
Hi,
Is it possible to configure Dovecot to reject mail that is not encrypted. In other words:
If the user tries to send an unencrypted message from their MUA, the server rejects it.
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
On January 10, 2018 at 2:08 PM David Seaward dseaward925@gmail.com wrote:
Hi,
Is it possible to configure Dovecot to reject mail that is not encrypted. In other words:
If the user tries to send an unencrypted message from their MUA, the server rejects it.
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
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: the server rejects it.
- If the user tries to send an unencrypted message from their MUA,
- 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
participants (3)
-
Aki Tuomi
-
David Seaward
-
Jochen Bern