On Wed, Nov 11, 2015 at 12:59:49PM +0100, Tobias Reckhard wrote:
> I've got a client who wants to do mandatory TLS for e-amils to as well
> as from several parties, identified by their domains. Outbound mandatory
> TLS is easy enough using smtp_tls_policy_maps. We have also enabled
> opportunistic TLS on the smtpd and have explained to our client that
> he'd be in conflict with RFC 3207 if he were to demand that we set
> smtpd_tls_securitylevel=encrypt. Now they're asking whether it would be
> possible to leave smtpd_tls_securitylevel=may and still enforce STARTTLS
> use for e-mails coming from certain domains.
>
> Since smtpd can't decide what the MAIL FROM is going to be when a client
> connects, and since we don't know which SMTP clients we're supposed to
> expect e-mail from the domains in questions from, it obviously has to
> allow the client to proceed until it has received the MAIL FROM command.
> Then it might be possible to use smtpd_sender_restrictions to reject an
> attempt to send mail without TLS. However, I have not yet found a way to
> do so.
You can do this, as Wietse already pointed out, with
"reject_plaintext_session". Keep in mind:
http://www.postfix.org/TLS_README.html#client_tls_limits
One may be tempted to try enforcing TLS for mail from specific
sending organizations, but this, too, runs into obstacles. One
such obstacle is that we don't know who is (allegedly) sending
mail until we see the "MAIL FROM:" SMTP command, and at that
point, if TLS is not already in use, a potentially sensitive
sender address (and with SMTP PIPELINING one or more of the
recipients) has (have) already been leaked in the clear. Another
obstacle is that mail from the sender to the recipient may be
forwarded, and the forwarding organization may not have any
security arrangements with the final destination. Bounces also
need to be protected. These can only be identified by the IP
address and HELO name of the connecting client, and it is
difficult to keep track of all the potential IP addresses or
HELO names of the outbound email servers of the sending
organization.
Consequently, TLS security for mail delivery to public MX hosts
is almost entirely the client's responsibility. The server is
largely a passive enabler of TLS security, the rest is up to
the client. While the server has a greater opportunity to
mandate client security policy when it is a dedicated MSA that
only handles outbound mail from trusted clients, below we focus
on the client security policy.
Perhaps precluding forwarding is "acceptable collateral damage",
but one must be careful with such policies. The right place to
enforce TLS policy is in the sending system.
--
Viktor.
