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

Reply via email to