>> Matus UHLAR - fantomas writes: >>> >>> If the error was temporary, I could disable TLS negotiation for remote >>> server and ask them to fix the problem.
>On 06/Nov/11 05:47, Sam Varshavchik wrote: >> 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. perfect! On 06.11.11 12:51, Alessandro Vesely wrote: >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. such script can simply read log files, e.g. logwatch, which is what I plan to do. We even distribute configs from central storage, so it's not enough to run it on the machine where it appeared (unless I want to repeat the same error for every server sending mail to the same domain) -- Matus UHLAR - fantomas, [email protected] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fighting for peace is like fucking for virginity... ------------------------------------------------------------------------------ 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
