On Tue, Mar 22, 2016 at 10:28:48AM -0400, Wietse Venema wrote:
> In order to protect the stability of the Postfix SMTP client, I
> propose a new feature that builds on smtp_tls_policy_maps that
> allows experimentation with STS and other features.
>
> The design is similar to the way that Postfix SMTP server policies
> build on access maps.
>
> 1) An optional smtp_check_tls_policy client in the Postfix SMTP
> client that speaks TCP or local IPC just like the SMTP server's
> check_policy feature.
>
> /etc/postfix/main.cf:
> smtp_check_tls_policy = inet:127.0.0.1:12345
Unfortunately, this is not quite sufficient for STS. There are
two complications:
1. STS policies are "validated" at time of first use, and
caching of the policy is only enabled on successful delivery.
2. STS domains will likely solicit authentication failure feedback.
So the STS policy service will need to receive success/failure
reports for deliveries to domains that publish STS policy.
> Is this all paractical, or will we be stuck with C code?
Not yet clear...
===========
On Wed, Mar 23, 2016 at 10:16:15AM +0100, David Schweikert wrote:
> > Q1: What point in time is the call made?
>
> Maybe after the TLS-protected HELO?
That's much too late. The right time to locate policy is before
the connection is made. TLS policy affects connection re-use and
TLS cipher selection, ...
> > Q2: What attributes to send? E.g., nexthop, recipient, SMTP_SESSION,
> > SMTP_ITERATOR, what else?
>
> Probably also information about the TLS connection, so that a policy
> daemon can do the verification that it needs. Possibly the CA CN and
> certificate CN plus the information if it's considered trusted or not?
> I guess you could also send the certificate over the wire?
No, chain verification needs to be in Postfix not the policy lookup
service.
> > 3) The reply is exactly the same as with smtp_tls_policy_maps. The
> > rationale for this is to simplify implementation, user interface, and
> > documentation (less code to write and fewer new things to learn).
>
> I would have thought something more in line with access restrictions. I
> mean: I probably want to tell Postfix if it needs to keep the mail in
> the queue (with a defer reason), or possibly bounce it, in case I am not
> happy with what the next hop gives me. How to do that with a reply like
> in smtp_tls_policy_maps?
If the TLS session meets the security requirements established
prior to connection start then the message should be delivered.
Connecting with a weak policy only to then disconnect makes little
sense.
--
Viktor.
