On Thu, Feb 27, 2014 at 12:48:47PM -0500, Wietse Venema wrote:
> Peer Heinlein:
> > You got it. That's what we ARE doing and that's why I'm asking for. :-)
>
> Well this is a very non-standard deployment. I have to spend my
> limited cycles wisely on things that benefit the most people.
>
> > We have situations, where a mail MUST send using TLS. And I need a
> > FAST and reliable DSN back to the sender if that's not possible.
>
> If it MUST be TLS, then why can't mail wait until the destination
> is "repaired"?
Also TLS is a transport mechanism, but transport failure is not
message failure. Equating transport failure with message failure
is semantically flawed.
Are all the destinations in question served by exactly one MX host,
why? If not, the failure would have to be based on some global
observation that *every* candidate MX host failed to offer TLS, or
the certificates of *every* MX host failed to verify.
Bouncing mail because of transport failure with a single MX host
is broken-by-design. Building logic to keep state across multiple
MX hosts is too expensive, and is still flawed given constraints
like smtp_mx_session_limit.
It is far easier to enable fast delay notices, or set a very short
maximal queue lifetime if fast failure is more appropriate than
eventual success for the messages being sent.
--
Viktor.
