On 3 Jun 2015, at 9:15, John Allen wrote:
Is there any way of testing for and refusing un-encrypted email?
The generic answer is "yes" but you need to define what you mean to pick
a mechanism.
If you mean email must be sent and received over an encrypted transport,
e.g. TLS, it is simply a matter of 2 postfix settings:
smtp_tls_security_level=encrypt
smtpd_tls_security_level=encrypt
Note that using those will BREAK YOUR MAIL SERVER for normal use and
violate RFC2487, which defines the STARTTLS extension to SMTP. Many SMTP
servers still do not support TLS; requiring it with no plaintext
fallback means no mail to or from those peers.
If you mean the email must be encrypted internally, e.g. S/MIME or PGP,
the task will fall to a content filter of some sort. To determine
whether a message is encrypted you'd need to look at its MIME structure
carefully for *known* indications of an encrypted message (i.e.
mechanisms that strictly fit an encryption standard) and reject messages
that do not match. This might be possible using header_checks and
mime_header_checks, but I suspect that it may ultimately require a more
sophisticated tool like Amavis or MIMEDefang to examine a message as a
whole rather than those limited line-at-a-time internal checks.
secondary, would it be possible to do this based upon the recipient.
default would be encrypted, but email directed at some recipients may
be in plain text.
Per-recipient differences can be split out via Postfix's "Restriction
Class" feature or by defining different transports for different sets of
users and filtering them differently but IMHO the best approach would be
to do it outside of Postfix proper in a full content filter. I'd point
at MIMEDefang as the obvious tool, especially if you're fluent in Perl.
Note that if you want maximal protection for both message metadata
(headers and SMTP envelope) and content both in transit and after
delivery, you have a very large problem space that has ultimately
frustrated some very smart people, including Phil Zimmermann (the
original author of PGP) who recently started to try to create a fully
secure email service and gave up on it as impossible. The first step
would be to enforce TLS encryption all of the time, because without that
envelopes and headers would all be sniffable on the wire. Getting all
messages to use a standard (i.e. detectable) encryption mechanism is a
necessary next step, but even after that you have an issue of
post-delivery storage (see the current thread here with the subject
"encrypt incoming emails with my public gpg key") and transport security
for users retrieving their mail via POP, IMAP, or other mechanisms like
webmail. In the final analysis you need to define your scope very
clearly and strictly in making an email system "secure" and simply
ignore out-of-scope issues.
