No, that wouldn't be a huge deal. I'll add it to my TODO list. -- Sam Clippinger
Eric Shubert wrote: > 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". ;) >>>>> >>>>> >>>>> >>>>> > > > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
