On 11/20/2010 12:22 PM, Dossy Shiobara wrote: > OK, I think I figured out the issue! > > Similarly, I did a ton of Googling with very little success in finding a > solution. Hopefully this will be in the archive and help someone down > the line ... > > My setup is a hand-rolled Qmail + Spamdyke setup. I run everything > under Daemontools. My Spamdyke config lives in /etc/qmail -- here is > where it gets interesting. > > I had regular SMTP and SMTPS managed separately under Daemontools. The > SMTP one pointed Spamdyke at /etc/qmail/spamdyke, and the SMTPS one used > /etc/qmail/spamdyke-ssl. The two configs were identical *except* the > SMTPS one had the following three lines at the top: > > tls-level=smtps > tls-certificate-file=/etc/ssl/certs/dovecot.pem > tls-privatekey-file=/etc/ssl/private/dovecot.pem > > This worked great, except making config changes meant having to make > them *twice* ... annoying, and potentially error prone. I decided to > try and unify things into one config file, so I moved the tls-*-file > config directives into /etc/qmail/spamdyke, and added > "--tls-level=smtps" to the Daemontools "run" file. > > The default for "tls-level" is "smtp" ... which, when I misread (or > misremembered) the documentation, I confused it for what is actually the > "none" setting. I didn't realize that "smtp" would be SMTP+STARTTLS ... > turns out if you specify tls-certificate-file and tls-privatekey-file > and tls-level=smtp, you get STARTTLS ... oops. This is why after moving > those two config settings into my /etc/qmail/spamdyke (which my SMTP > config would now share), I ran into problems. Why? > > Here's the relevant snippet of what my SMTP "run" file used to be -- > > exec envuidgid qmaild \ > tcpserver -v -R -c "$MAXSMTPD" -u "$QMAILDUID" -g "$NOFILESGID" \ > -x /etc/tcprules/smtprules.cdb 0 25 \ > /usr/bin/fixcrio /usr/bin/recordio \ > /var/qmail/bin/spamdyke -f /var/qmail/control/spamdyke -- \ > /var/qmail/bin/qmail-smtpd `hostname` \ > /usr/bin/checkpassword /bin/true 2>&1 > > At first glance, I totally didn't spot the problem. Of course, it was > because I had *assumed* that the default tls-level of "smtp" meant what > "none" actually provides (NB: it'd be nice if the default for tls-level > was actually "none" and not "smtp" ... but, that's just my $0.02) -- so, > why would I be seeing SSL errors, right? Then it dawned on me that if > I'm seeing SSL errors, then it MUST be trying to do SSL somehow, despite > what I (incorrectly) thought tls-level=smtp was supposed to do. > > That's when it dawned on me: the fixcrio/recordio is going to much with > the bytestream, which it's supposed to do and works well for qmail-smtpd > ... but I had them *upstream* from Spamdyke! OOPS. > > I moved those two commands on the one line to *after* spamdyke, and > everything appears to be working just fine. Alternatively, I guess I > could have left things the way they were and set tls-level=none, so that > I could use recordio to capture SMTP sessions *before* spamdyke hands > control over like I had previously. > > Perhaps I should put keep recordio before spamdyke, and fixcrio to after > it. In theory, that would provide me the logging I want but not muck > with the potential SSL session. > > Thoughts?
Why do you need recordio when spamdyke has such a nice detailed logging facility? Doesn't spamdyke take care of what fixcrio does, making fixcrio unnecessary? > On 11/20/10 2:01 PM, Sam Clippinger wrote: >> After doing some Googling, two thoughts occur to me. First, is it >> possible you have a firewall or some kind of filtering appliance that is >> blocking the SSL traffic? Second, are you using "ulimit" (or something >> similar) to restrict spamdyke's memory usage? If that limit is set too >> low, it can cause strange problems like this. > -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
