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
>>
>>


-- 
-Eric 'shubes'

_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to