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?
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.
--
Dossy Shiobara | [email protected] | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
