Peer Heinlein: > At the moment it's a soft failure if a TLS connection fails due to > cipher or protocol mismatches and if tls-encryption is enforced. > > F266840008 3238274 Tue Feb 25 08:32:09 x...@example.com > (TLS is required, but was not offered by host > mx3.me.com.akadns.net[17.172.34.64]) > > I'd like to have this error hard, not soft. In my eyes it's not a > tempoary failure, but a fatal error.
Assuming that you haven't configured a global policy of "all mail deliveries shall use TLS", I think that this is an excellent use case for the "delay_warning_time" feature, perhaps combined with notify_classes and delay_notice_recipient. Clearly (to me) the intent is to deliver mail; the system administrator has even configured a non-default mandatory TLS policy for this destination. As for changes to Postfix source code, the Postfix SMTP client has an smtp_reply_filter feature that can modify error messages that are generated externally (i.e. remote SMTP server responses), for example from soft errors into hard errors. As of now there exists no "filter" feature to transform error messages that the Postfix SMTP client generates internally (after DNS lookup failure, server unreachable, lost connection, TLS required but unavailable, and so on). However, as you might expect these errors are handled in one central place. If there is a need to change the handling of these internally-generated error messages, then it should be done at that central place, and it should be configurable, similar to smtp_reply_filter. After all, error messages are nothing but partly-structured text. Wietse