Alessandro Vesely writes:
On 06/Nov/11 05:47, Sam Varshavchik wrote: > Matus UHLAR - fantomas writes: >> >> If the error was temporary, I could disable TLS negotiation for remote >> server and ask them to fix the problem. > > After some soul-searching, I've changed my mind. I'm going to change > so that the default configuration ignores errors in response to a > STARTTLS. This won't help if the other server accepted a STARTTLS, but > the actual TLS negotiation failed, because of a cipher mismatch, or > something of this sort. The TLS session is broken at this point, > everyone's screwed, and you can't do anything there. > > There will be a setting to treat all STARTTLS errors as soft errors, > or revert to the current behavior of a hard error, if someone still > wants this.Would it make sense to invoke a user-provided script to sort this out? A script could track server certificates, update esmtproutes, notify admins, report attacks, and whatever.
Ok – but this might be placing too much faith in some people's ability to write a secure script that gets invoked by a critical system process.
pgpx6Q9CL5Nu9.pgp
Description: PGP signature
------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
