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