t...@uncon.org wrote: > Quoting "Eric Shubert" <e...@shubes.net>: > >> 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.
I believe that SSL_shutdown is likely where spamdyke is hung most often. I can send you some detail logs if you'd like to see them. I did see just a few (over a period of a few months on a relatively light traffic server) that appeared to hang early in the smtp session though (perhaps on the starttls - I only had the "info" logs to go on). > 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). Is is feasible to use SSL_* in a non-blocking manner as Teodor wrote (first post in this thread), or is there a problem with doing things that way? >> 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. This should probably be discussed under a different thread. I'll start one up. Thanks. -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
