Thanks Wietse,
I agree that end-to-end use cases are difficult.
At the moment users usually get neither any feedback on security aspects of
messages they send nor can they request specific security properties.
Thunderbird "advertises" end-to-end-encryption only and confuses users that
actually use/benefit from SMTP-DANE where it tells "unencrypted". Some web-MUAs
provide visual feedback, but often also inconsistent. Also if someone
establishes a communication channel based on the assumption that SMTP-DANE will
be used cannot really rely on that unless the admin configures the target
domain specifically e.g. with dane-only if postfix is used as configuration can
change.
Imho there are two approaches to improve these usability aspects:
1) a MUA could query target the target email server and figure out, whether it
support SMTP-DANE or MTA-STS or just unauthenticated encryption or not even
that, and also query the local email server whether it also supports that
standard outbound (in fact there are email services that support different
standards inbound and outbound). The local query could of course be replaced by
configuration, but typical users will not know the setting unless they run a
test.
2) allow MUAs to signal whether they want authenticated encryption and leave
the rest to the MTAs. This is imho one use case of RFC 8689, but even if a MTA
supports RFC 8689 and RFC 8641, it could fail to enforce encryption to a
destination using RFC 7672. In fact I am wondering whether RFC 8689 in practice
would require an MTA to support both RFC 7672 and RFC 8641.
And yes, ideally it should be a combination of both, as the configuration can
change while in transit.
More thoughts?
Joachim
-----Ursprüngliche Nachricht-----
Von: Wietse Venema via Postfix-users <postfix-users@postfix.org>
Gesendet: Freitag, 13. Oktober 2023 20:10
An: Postfix users <postfix-users@postfix.org>
Betreff: [pfx] Re: SMTP Require TLS Option?
Joachim Lindenberg via Postfix-users:
> Hello,
>
> are there any ideas or plans to implement SMTP Require TLS Option (RFC 8689)
> in postfix?
It is not on the calendar. Below is a preliminary analysis of the
implementation effort. Rumor has it that there was a preliminary implementation
for Exim based on an obsolete draft of REQUIRETLS.
> I am aware of that in order to really leverage that, one needs a MUA
> using it, plus a MTA supporting SMTP-DANE (RFC 7672) or MTA-STS (RFC
> 8461), but sure I may be missing something.
This is something that must be used selectively: all SMTP servers in the
forward path must support (and enforce) the REQUIRETLS option in the MAIL FROM
command. When such a message is bounced it must also be protected with
REQUIRETLS, unless the bounce message returns only the message header.
Similarities/differences with SMTPUTF8:
- This requires Postfix changes for the propagation of the REQUIRETLS
option in the MAIL FROM command in the normal delivery path,
similar to SMTPUTF8.
- This requires changes to message stores (Dovecot, etc.) to announce
REQUIRETLS support in their SMTP or LMTP server, even if they do
nothing with it. To work around this, the Postfix SMTP/LMTP client
could have a 'fake REQUIRETLS' setting (do not send REQUIRETLS
and pretend that the message store SMTP/LMTP server supports it).
- This requires changes to SMTP-based content filters to pass
through the REQUIRETLS option, similar to SMTPUTF8. To work around
this, Postfix can't 'fake REQUIRETLS' in the after-filter SMTP
server because that would request REQUIRETLS for all mail.
- No need to propagate REQUIRETLS for header-only bounce messages,
unlike SMTPUTF8.
- Milters are not affected.
New mechanisms in Postfix would involve:
- A Postfix sendmail command-line option to request REQUIRETLS.
This is unlike SMTPUTF8 which can rely on autodetection.
- Propagating the REQUIRETLS option through a "pipe to command"
content filter, to the Postfix sendmail command at the other end
of that filter.
- Overriding server certificate verification (PKI, DANE, MTA-STS)
with a "TLS-Required: No" message header (ignored when REQUIRETLS
was requested).
- Returning email as undeliverable when all SMTP or LMTP server
certificates fail to verify.
Often when some end-to-end feature is added to SMTP, it is a royal pain to make
it work with a "pipe to command" content filter. I'd like to get rid of that.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an
email to postfix-users-le...@postfix.org
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
