Quoting "Eric Shubert" <[email protected]>: > > Does this patch activate a timeout effects all (subsequent) read > commands? If not, it won't solve the problem. spamdyke usually hangs > long after the STARTTLS when it does, and the STARTTLS is successful.
The patch needs a bit more work. I also need to look at changing how the SSL_shutdown works, as there is a hang-up there too. As far as reads go, spamdyke does currently protect those, however, I'm not convinced that there being data available necessarily means that SLL_read won't block (i.e. does 1-byte of encrypted data always equate to 1-byte of non-encrypted data). > > So even with this patch, using TLS with no idle-timeout-secs setting > leaves a server vulnerable. Is there some way of requiring an > idle-timeout-secs value when TLS is used? Perhaps giving it a relatively > high (300) default? If nothing else, --config-test should at least give > a warning when TLS is in use and there's no idle-timeout-secs setting. > Personally, I'd like to see the idle-timeout-secs setting activated by > default. It's not just TLS though - not using idle-timeout-secs means your server is vulnerable to a DoS. I agree, the default settings should enable it. Thanks, -trog _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
