Teodor Milkov wrote: > Hello, > > It seems the way spamdyke implements TLS is prone to infinite hangs due > to SSL_* functions blocking on IO operations. > > There are already some reported cases although no enough debug > information was provided: > > http://www.mail-archive.com/spamdyke-users@spamdyke.org/msg00797.html > http://www.mail-archive.com/spamdyke-users@spamdyke.org/msg01313.html > > The simplest test case is connecting to spamdyke with telnet, then issue > starttls and just wait here forever. At this time SSL_accept waits for > input and there's no timeout mechanism to guard against this. There are > more places in spamdyke where SSL_read, SSL_shutdown etc. are not well > guarded. > > AFAIK there are two ways to handle this situation: > > 1. set inbound_fd/outbound_fd to non-blocking mode with fctnl(2) and > then use SSL_* in a non-blocking manner[1] > > 2. use alarm() and signal handler to guard against such cases > > 1 is probably better way to do it while 2 is quicker (and dirtier?). > > > What do you think? > > > [1] http://www.openssl.org/support/faq.html#PROG10 > > ------------------------------------------------------------------------
I think I wish I would have paid closer attention to this when it was posted. :( I believe this is undoubtedly a bug. Kudos to Teodor for having nailed it so thoroughly. He identified the problem accurately, and provided suggested solutions (I agree that #1 is a cleaner solution, fwiw). Nice work Teodor. To be clear about this, the symptom/result of this bug is defunct qmail-spamd processes. Their parents are spamdyke processes that are waiting for "TLS ended and closed" events that never occur. This is typically after a TIMEOUT error message that is issued after any one of the spamdyke DENIED_* rejections. Killing the parent spamdyke processes clears things up effectively. http://www.spamdyke.org/documentation/README.html#TLS says "While it's true spammers aren't using TLS and therefore any client that does use it is unlikely to be a spammer, there's no reason to assume that will be true forever." Looks like the day has come when this is no longer true. It appears that some spammers have begun using TLS in an effort to bypass spam filters (which does indeed defeat some spamdyke filters if TLS is implemented in qmail and not spamdyke). This increased use of TLS by spammers has made this bug more prevalent recently, especially on servers which host a large number (50+) of domains and accounts (hundreds). Hey Sam, do you suppose it's time to get this fixed? I maintain a server that's getting several of these per hour now, and will be happy to test when you have the code ready. Thanks to everyone who has wrestled with this elusive bug. Special thanks to Teodor. And Sam of course. ;) -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
