I agree spamdyke should handle the TLS so all of its filters can be used
(including graylisting).
However, spamdyke can't filter outbound mail. Anything that's generated
on your server (e.g. webmail users) will bypass spamdyke entirely.
Anything that's sent through your server (e.g. your users' MUAs using
your server as their SMTP host) will/should be whitelisted or
authenticated. Granted, you _can_ setup spamdyke to filter mail
generated by your users' MUAs but you won't like it -- you'll get a lot
of angry phone calls.
-- Sam Clippinger
Dan McAllister wrote:
Sam, et. al.
I would say that to get the best results out of SPAMDYKE, you DEFINITELY
want *IT* to handle the TLS. My reasoning is 2-fold:
1) I have an average of 15% of incoming SPAM that is attaching with TLS
(I thought this was odd, but apparently not)
2) I require TLS for my outbound mail (from my clients).... and THEY TOO
can be sources of SPAM. I'd like SPAMDYKE to equally fight inbound AND
outbound SPAM!
Just my thoughts. They were free to you, so take them at their face value.
Daniel McAllister, President
IT4SOHO, LLC
"Take my advice... I won't be using it today!"
Sam Clippinger wrote:
Actually, enabling TLS in spamdyke is the best solution. When
spamdyke handles the TLS, the remote server can't tell the difference
-- if it was using TLS before, it should continue to do so. However,
because spamdyke decrypts the traffic, it can enable all of its
filters (including graylisting, recipient blacklisting, etc). If
spamdyke simply passes TLS traffic through without decrypting it, most
of its filters cannot operate.
-- Sam Clippinger
Davide Bozzelli wrote:
Sam Clippinger ha scritto:
OK, I should be able to duplicate that setup to see if I can
reproduce your error. It may be a little while before I have the
time, however.
In the meantime, can you try enabling TLS support in spamdyke to see
if this error persists? Inside spamdyke, TLS passthrough is handled
differently than TLS decoding. If this is a spamdyke bug, you may
be able to work around it. Enabling TLS support will also allow all
of spamdyke's filters to function, including graylisting.
To enable TLS, you'll need to compile spamdyke with TLS support and
use the "tls-certificate-file" directive in the configuration file.
Your TLS certificate is probably located at:
/var/qmail/control/servercert.pem
-- Sam Clippinger
I can confirm this bug, i've have the exact problems with a qmail
patched with jms combined patch that sends mail to a qmailtoaster
with spamdyke enabled without tls.
By enabling tls in spamdyke the problem went down, but it's not the
correct way of work, cause the source mta don't do any tls handshake.
Have fun,
Davide
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
