That's pretty much what I figured. I've kept a little closer eye on it this
morning (just visual monitoring), and it seems to be rejecting nearly
everything properly. Maybe a couple instances where the session ends with
status 0 and no message from spamdyke.
Would it be possible to add a 'sender disconnect' or some such message, so
that there will always be a message from spamdyke for every smtp session
that's initiated? Not a big deal, but it'd be nice to be able to account for
every connection (if someone were to write a log summary report of some kind).
Sam Clippinger wrote:
spamdyke won't log anything if a remote client disconnects without
identifying a sender or recipient. Prior to version 4.0, it wouldn't
log anything if a message was delivered with TLS but that's been fixed.
I can't think of any other situation where a delivery (or rejection)
would not create a log entry.
-- Sam Clippinger
Eric Shubert wrote:
Sam Clippinger wrote:
Good to hear it's working... I guess there just weren't any good
messages being delivered while you were testing filter-level?
That's what I'm thinking.
I'm still seeing something a little peculiar though. I would expect every
smtp session to generate a spamdyke message of one form or another, either a
rejection or an allow. This particular server's pretty, so it's sometimes
hard to tell. Is this the case, or are there situations where a session
might not have a spamdyke message?
FWIW, this server is simply a relay for specific domains, and has/does no
authentication other than checking rcpthosts and morercpthosts, then
forwards the mail based on the .qmail-default record for each domain. Kinda
goofy, I know.
By the way, setting the filter-level option in the global config file
is not really what I had in mind when I created that flag. Since it
overrides all other flags, including blacklists, it was really intended
for use in configuration directories. Specifically, some of my users
have become tired of repeatedly asking me to whitelist their
correspondents. Several have asked me to just turn off spam filtering
for their accounts. With configuration directories, I can create a file
for their address that includes the command filter-level=allow-all
(they typically begin to see the wisdom of filtering after a few days).
Without that command, their file would have to explicitly disable all
enabled filters and would be a pain to create/maintain.
By the same token, I wanted to provide an easy way for administrators to
require authentication for senders/recipients within specific domains.
That is now very easy to accomplish using a configuration directory and
filter-level=require-auth.
Nice.
FWIW, I just found it to be an easy way to turn spamdyke off temporarily, as
opposed to changing run files back and forth. :)
-- Sam Clippinger
Eric Shubert wrote:
Eric Shubert wrote:
Eric Shubert wrote:
I've probably hosed up something in my new .conf file.
What I'm seeing is that with filter-level=normal, I'm seeing some
rejections
(not as many as I'd expect), and NO allow messages. I can confirm that
nothing is being allowed from looking at the send queue.
With filter-level=allow-all, it's indeed allowing everything. Not exactly
what I had in mind though. :(
Here's my spamdyke.conf file:
filter-level=allow-all
max-recipients=50
reject-empty-rdns
reject-ip-in-cc-rdns
reject-missing-sender-mx
reject-unresolvable-rdns
log-level=info
log-target=stderr
idle-timeout-secs=300
ip-blacklist-file=/etc/spamdyke/blacklist_ip
rdns-blacklist-file=/etc/spamdyke/blacklist_rdns
recipient-blacklist-file=/etc/spamdyke/blacklist_recipients
sender-blacklist-file=/etc/spamdyke/blacklist_senders
ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
ip-whitelist-file=/etc/spamdyke/whitelist_ip
rdns-whitelist-file=/etc/spamdyke/whitelist_rdns
recipient-whitelist-file=/etc/spamdyke/whitelist_recipients
sender-whitelist-file=/etc/spamdyke/whitelist_senders
ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
dns-blacklist-entry=zen.spamhaus.org
dns-blacklist-entry=bl.spamcop.net
graylist-level=always-create-dir
graylist-dir=/var/spamdyke/graylist
graylist-max-secs=1814400
graylist-min-secs=180
local-domains-file=/var/qmail/control/rcpthosts
local-domains-file=/var/qmail/control/morercpthosts
Note, in the cases where the parameter references a file, the file exists
and is empty.
Thoughts / suggestions?
Ok, so I removed all of the blacklist and whilelist file references, and
graylisting, and I'm seeing an allow or 2 coming through. That's good!
I'll try adding parameters back in and see if I can pinpoint the culprit.
Ok, so there doesn't appear to be a problem any more. After some careful
testing, everything appears to be working as it should.
As Rosanna
