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 Rosannadanna would say, "Never mind". ;) >>>> >>>> >>>> -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
