Remember that the "softlimit" program only limits the maximum amount of memory a process can use; it doesn't dictate how much it *will* use. It was written as a last resort for stopping processes that were out of control and leaking memory. It's big flaw is that you never get a simple "out of memory" error -- all you see are inexplicable bugs like the one Ron has been battling because (in this case) OpenSSL can't allocate a buffer or whatever. Given the number of problems it seems to create, I'd vote for simply removing it.
-- Sam Clippinger On 6/9/11 10:28 AM, Eric Shubert wrote: > Ron, > > Can you do a little testing and see what's adequate? I expect that 128M > is a bit overkill. We'll need to get the QMT defaults bumped up a bit > depending on your results. > > Thanks. > > On 06/09/2011 07:42 AM, ron wrote: > >> Ok, That seems to have done the trick. I received an email from the client. >> I bumped it up to 128M. >> >> Thanks >> Ron >> >> On 6/9/2011 10:12 AM, Sam Clippinger wrote: >> >>> 20M seems kinda low for "softlimit". Try increasing the number to see >>> if that makes a difference -- for example, add another zero (200M) and >>> retest. On my own server, "softlimit" is set to 80M. >>> >>> Don't forget to restart the service after making the change. :) >>> >>> -- Sam Clippinger >>> >>> On 6/9/11 7:13 AM, ron wrote: >>> >>>> OS is Centos 5.6 >>>> Linux kernel is 2.6.18-238.9.1.el5 >>>> Server is a DL380 G4 >>>> Centos runs under VMWare ESXi 4.0 >>>> >>>> Here is the "run" file. >>>> >>>> #!/bin/sh >>>> QMAILDUID=`id -u vpopmail` >>>> NOFILESGID=`id -g vpopmail` >>>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` >>>> SPAMDYKE="/usr/local/bin/spamdyke" >>>> SPAMDYKE_CONF="/etc/spamdyke/spamdyke.conf" >>>> SMTPD="/var/qmail/bin/qmail-smtpd" >>>> TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb" >>>> HOSTNAME=`hostname` >>>> VCHKPW="/home/vpopmail/bin/vchkpw" >>>> REQUIRE_AUTH=0 >>>> >>>> exec /usr/bin/softlimit -m 20000000 \ >>>> /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c >>>> "$MAXSMTPD" \ >>>> -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp \ >>>> $SPAMDYKE --config-file $SPAMDYKE_CONF \ >>>> $SMTPD $VCHKPW /bin/true 2>&1 >>>> >>>> On 6/8/2011 4:50 PM, Sam Clippinger wrote: >>>> >>>> >>>>> OK, I'll try to run back through this thread and respond to the various >>>>> questions in one email... >>>>> >>>>> To turn off TLS in spamdyke, you can do one of several things. You can >>>>> prohibit both spamdyke and qmail from using TLS by using this option: >>>>> tls-level=none >>>>> Or you can simply remove/comment out the tls-certificate-file option to >>>>> allow spamdyke to pass encrypted traffic through to qmail. That will >>>>> bypass some of spamdyke's filters but would allow you to continue to >>>>> receive encrypted email. >>>>> >>>>> spamdyke does not implement TLS or SSL on its own, it just calls the >>>>> installed OpenSSL library for encryption/decryption as needed. The >>>>> version you have installed looks fine to me (my own server has 0.9.7f >>>>> installed) and since TLS works with qmail, it should work with >>>>> spamdyke. From the headers you sent, it looks like the remote server is >>>>> running Windows Server 2003, probably with Exchange 2003. I correspond >>>>> regularly with clients on that same setup (as you did before installing >>>>> spamdyke), so I doubt the remote server is at fault. >>>>> >>>>> By default, spamdyke specifies the cipher list as "DEFAULT" (unless you >>>>> override that with the "tls-cipher-list" option). The meaning of >>>>> "DEFAULT" depends on your version of OpenSSL and the way it was >>>>> compiled. Typically, it includes all of the usable ciphers that aren't >>>>> known to be too weak or too computationally expensive. See this page >>>>> for more details: >>>>> http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS >>>>> >>>>> Overall, I don't see anything wrong with your configuration file. I'm >>>>> curious to know what OS, version and architecture you're using. My #1 >>>>> suspicion is that spamdyke is running out of memory. Can you check your >>>>> "run" file where the spamdyke command line is located and look for the >>>>> "softlimit" command? Try doubling/tripling that number and see if this >>>>> problem persists (don't forget to restart tcpserver after you change the >>>>> "run" file). >>>>> http://www.spamdyke.org/documentation/FAQ.html#TROUBLE9 >>>>> >>>>> -- Sam Clippinger >>>>> >>>>> On 6/8/11 3:03 PM, Eric Shubert wrote: >>>>> >>>>> >>>>>> The first cipher listed is the same one that qmail used with a >>>>>> successful transmission. >>>>>> >>>>>> Looks to me from all of this that there is a bug in spamdyke with >>>>>> regards to that particular remote server software and TLS. >>>>>> >>>>>> I think this is the point where Sam can best continue helping to debug >>>>>> this situation. >>>>>> >>>>>> Sam? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> spamdyke-users mailing list >>>>> [email protected] >>>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> spamdyke-users mailing list >>>> [email protected] >>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >>>> >>>> >>> _______________________________________________ >>> spamdyke-users mailing list >>> [email protected] >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >>> >>> >>> > > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
