> Max Mazurov:
> I would like to start a discussion on how this extension can be useful for
> postfix users and whether there is a possibility of getting its support.
This proposal appears to have multiple moving parts that involve
- signaling intent in a header (TLS-Required),
- a remote SMTP client requesting a promise (send REQUIRETLS),
- a Postfix SMTP server offering to make a promise (announce REQUIRETLS),
- a Postfix SMTP client enforcing that promise (send REQUIRETLS),
- overriding local MTA preferences in smtp_tls_policy_maps,
- overriding remote receiver preferences in TLSA or MTA-STS records,
- overriding local or remote preferences when TLS-Required=yes,
- overriding local or remote preferences when TLS-Required=no,
- propagating the server's promise when:
- the message passes through email content filters,
- the message has to be returned as undeliverable.
- the message is redistributed (including multi-recipient aliases).
- oh, it requires MTA-STS support. That is not cool.
(Unclear about:
- the appropriate SMTP client TLS settings (mandatory or not)
- The message is not received over SMTP but contains "TLS-Required:
yes", perhaps something along the lines of smtputf8_autodetect_classes,
- the message is redistributed by a mailing list manager; the RFC
suggests enforcing the REQUIRETLS promise,
- the message is not delivered over SMTP, e.g., the pipe(8) mailer.)
BTW the above analysis is incomplete.
Based on this triage I estimate that the REQUIRETLS invasiveness
is less than SMTPUTF8, perhaps more like MIME and DSN. With REQUIRETLS
the bulk of the work would happen in the Postfix SMTP client, with
the other parts of Postfix mainly concerned with propagation of the
REQUIRETLS promise.
Data points:
- I implemented MIME and DSN in ~month when I had time,
- Someone sponsored a developer (not me) to contribute SMTPUTF8,
and then I spent o(weeks) on editorial work.
- RFC 6531 (SMTPUTF8) is from 2012, Postfix SMTPUTF8 is from 2014.
Wietse
