Right after I said everything was ok, I went to lunch all fat dumb & happy thinking it was all fixed. While out to lunch I remembered that I left all the TLS stuff commented out, so I uncommented them
and had her send me another test, it didnt go. So its not fixed.

*Ron Olds *
*National Service Information *
145 Baker St
Marion, Ohio 43302
_ron@nsii.net_
800-235-0337 X122


On 6/9/2011 11: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
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users



_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users



_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to