Downgrade protection for Opportunistic Security schemes for SMTP

Transport security in SMTP world is merely Opportunistic, there is no practice like in the Web to always require encryption with matching DNS-ID and trusted certificate. Additionally, things get complicated with the use of MX records to delegate mail handling.

Overall, here are possible options for each SMTP connection, sorted by protection "strength":
- No encryption (no protection altogether).
- TLS without authentication e.g. self-signed cert. (protects against passive attacks only, server key can be spoofed)
- TLS with server cert. authentication (protects against passive attacks, MX records can be spoofed)
- TLS with server cert. authentication and DNSSEC (protects against passive attacks, STARTTLS support can be spoofed to downgrade connection to plaintext)
- TLS with server cert. authentication and MTA-STS (protects against passive and active attacks, but policy expiry makes it unreliable)
- TLS with server cert. authentication and DNSSEC+DANE (protects against active and passive attacks, best option)

Each of these options is better than the previous one so it makes sense to support all of them without directly falling back to the weakest one (no encryption).

## Interaction with REQUIRETLS

SMTP REQUIRETLS extension requires TLS with valid and matching certificates and MX records authentication using either DNSSEC or MTA-STS. So messages using it are handled in a "strongest security or fail delivery" way instead of Opportunistic Security approach typically employed by MTAs.

Though, MTA-STS and DANE have similar but not same security characteristics (as was noted in the draft spec review, see References). This might degrade the actual security provided by extension in the long term if DANE becomes more widespread than MTA-STS (unlikely).

## Proposal

1. Implement REQUIRETLS extension (issue #123)
2. Provide policy options to require certain security level for all messages (already done, see authenticate_mx, require_mx_auth and require_tls directives for remote module).

3. (Possibly) Implement downgrade protection for non-REQUIRETLS messages by remembering the authentication/encryption status like chasquid does it.
It will help with messages sent without using REQUIRETLS extension (as practice shows, SMTP extensions support is poor and grows slowly). Though, it is not clear whether to group options by protection scope (passive/active attacks) for simplicity or provide high granularity. Later option may be better for security but also increases the chance of unexpected interactions.

## References

- Opportunistic Security: Some Protection Most of the Time
https://tools.ietf.org/html/rfc7435
- SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
https://tools.ietf.org/html/rfc7672
- The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
https://tools.ietf.org/html/rfc6698
- SMTP REQUIRETLS Option
https://tools.ietf.org/html/rfc8689
- Last Call Review of draft-ietf-uta-smtp-require-tls-07
https://datatracker.ietf.org/doc/review-ietf-uta-smtp-require-tls-07-secdir-lc-sheffer-2019-02-22/
- chasquid documentation - Security level checks
https://blitiri.com.ar/p/chasquid/docs/sec-levels/
Related: #123.

No implementation files or tests are named. Start by reviewing related issue #123 and the remote module's authenticate_mx, require_mx_auth, and require_tls directives, then compare the proposed downgrade protection with the referenced REQUIRETLS, MTA-STS, DANE, and chasquid security-level material. Done would require an agreed policy model and implementation of the selected protection behavior.

Written by the indexing model from the issue text.