Viktor Dukhovni:
> On Thu, Feb 27, 2014 at 07:33:29PM +0100, li...@rhsoft.net wrote:
>
> > > 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
> >
> > they offer a mailservice with *unconditional* encryption in germany
>
> That's nice, but message encryption is an end-to-end feature, and
> TLS is a hop-by-hop one-MX-at-a-time security mechanism. The
> impedances don't match, and you get partial reflection...
>
> The best choice for the OP is something along the lines of a 1-2
> hour delay notification setting. Bouncing on TLS policy failure
> is wrong.
Setting maximal queue life time is the best good option that I have
seen discussed in this thread. This way Postfix will not give up
immediately with the first MX host that can't talk TLS.
In consideration if this I will not consider options that make TLS
errors a had error.
Wietse
