Make TLS errors hard, not soft
- 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 xy@...
(TLS is required, but was not offered by host
I'd like to have this error hard, not soft. In my eyes it's not a
tempoary failure, but a fatal error.
At least I'd like to decide that by my own. Maybe it's worth making it
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin
Tel: 030 / 405051-42
Fax: 030 / 405051-19
Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
Geschäftsführer: Peer Heinlein -- Sitz: Berlin
- On Tue, Mar 04, 2014 at 10:24:06AM +0100, Peer Heinlein wrote:
> And: It's not a surprise and not a "man made problem", but anWietse's proposed design will bounce when the last MX host tried
> interesting new use-case where we can provide additional mailadresses
> with TLS-encrypted SMTP (next hop)-transfer to/from the recipient's
> The forced use of TLS-encryption can by triggered by the user who knows,
> what he's doing. But the user need's a fast DSN if the enforced TLS is
> not possible.
(default the second to which a TCP connection is made) reports a
remote-at-fault TLS error. This is about the best approach possible
under the circumstances. This of course requires new code.