Actually, spamdyke will set RELAYCLIENT before qmail-smtpd is started if (1) RELAYCLIENT was not already set, (2) "local-domains-file" is given AND (3) "relay-level" is "normal" or greater. qmail-smtpd is always started as soon as the connection begins (the greeting banner comes from qmail, not spamdyke), so the decision to set or unset RELAYCLIENT happens as one of the very first steps (in process_access()). When spamdyke sets RELAYCLIENT, it relies on its own evidence (file contents, authentication, whitelists, etc) to decide whether to block relaying. If RELAYCLIENT is set before spamdyke starts, relaying is allowed unless a filter blocks the message.
I would be interested to know if giving the "access-file" option fixes this problem, even when the file does not contain the RELAYCLIENT value for the matching IP. It shouldn't change anything, but it would be good to know. Failing that, I wonder if we're looking at a different problem here, like a low memory condition. Are you using DJB's "softlimit" program? If so, try removing it or dramatically increasing the limit. You could also try testing while the "full-log-dir" option is present (and having compiled with "./configure --with-excessive-output ; make") -- the full log should print out the full list of environment variables each time they change, so you could see if RELAYCLIENT is set before qmail-smtpd is started. -- Sam Clippinger On Mar 21, 2012, at 9:53 PM, Eric Shubert wrote: > Yes, this is the same setup. Here are my configuration settings: > dns-blacklist-entry=zen.spamhaus.org > dns-blacklist-entry=bl.spamcop.net > graylist-dir=/var/spamdyke/graylist > graylist-level=always > graylist-max-secs=2678400 > graylist-min-secs=180 > greeting-delay-secs=5 > idle-timeout-secs=180 > ip-blacklist-file=/etc/spamdyke/blacklist_ip > ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords > ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords > ip-whitelist-file=/etc/spamdyke/whitelist_ip > local-domains-file=/var/qmail/control/rcpthosts > log-level=info > log-target=stderr > max-recipients=15 > rdns-blacklist-file=/etc/spamdyke/blacklist_rdns > rdns-whitelist-file=/etc/spamdyke/whitelist_rdns > recipient-blacklist-file=/etc/spamdyke/blacklist_recipients > recipient-whitelist-file=/etc/spamdyke/whitelist_recipients > reject-empty-rdns > reject-ip-in-cc-rdns > reject-unresolvable-rdns > sender-blacklist-file=/etc/spamdyke/blacklist_senders > sender-whitelist-file=/etc/spamdyke/whitelist_senders > smtp-auth-command=/home/vpopmail/bin/vchkpw /bin/true > smtp-auth-level=always > tls-certificate-file=/var/qmail/control/servercert.pem > tls-level=smtp > > As you can see, I do have local-domains-file, but I have not specified > any access-file. Is the access-file required? I presumed not, as the doc > says it may be given, and connections are allowed by default. > > When I tested authentication (using telnet), I got a Proceed message > after authentication, so I presumed authentication worked ok and I > didn't test any further (my bad). > > My qmail-smtpd is (still) patched with smtp-auth though, and it doesn't > appear to recognize that authentication has taken place. I want to have > spamdyke control authentication entirely, but it appears that spamdyke > isn't setting RELAYCLIENT when authentication has taken place. I presume > that spamdyke doesn't start qmail-smtpd until after authentication has > taken place, otherwise RELAYCLIENT could not be set, right? > > Let me know if I can give you anything else to go on. > > Thanks Sam. > > -- > -Eric 'shubes' > > On 03/21/2012 04:46 PM, Sam Clippinger wrote: >> Umm, no. If this is the same setup you described in your previous email >> (which I haven't had a chance to investigate yet, sorry), it looks like >> you're not supplying the "local-domains-file" or "access-file" options, so >> spamdyke doesn't have enough information to control relaying (i.e. it >> doesn't know which domains are local or who has permission to relay, so it >> has to trust qmail to control relaying). If those options are given, >> spamdyke will always set the RELAYCLIENT variable and control relaying >> itself. That will fix the problem: spamdyke will prevent relaying from >> non-authenticated senders and qmail-smtpd will accept non-local recipients >> passed by spamdyke. >> >> -- Sam Clippinger >> >> >> >> >> On Mar 21, 2012, at 5:49 PM, Eric Shubert wrote: >> >>> On 03/20/2012 03:00 PM, Eric Shubert wrote: >>>> I did a little testing, and this appears to be just a bug in the >>>> config-test. With these settings, cram-md5 is not advertised, and >>>> authentication does work. >>> >>> After a little more testing, I discovered that qmail-smtpd (w/chkuser) >>> is rejecting non-local emails, because it doesn't realize that the >>> sender has authenticated. >>> >>> If I set the RELAYCLIENT variable in the tcp.smtp file (which would >>> normally create an open relay), will spamdyke still honor the >>> relay-level=normal >>> (default) setting, and reject unauthenticated attempts to relay? >>> >>> I ask this because the documentation about spamdyke's access-file says this: >>> Remote servers are allowed to relay if the environment variable >>> RELAYCLIENT is set to any value. Most qmail guides recommend an entry >>> like this one: >>> 11.22.33.44:allow,RELAYCLIENT="" >>> >>> and it's not clear to me if spamdyke would see this variable set by >>> tcp.smtp and allow access based on this. >>> >>> As always, thanks Sam. >>> >>> -- >>> -Eric 'shubes' >>> >>> _______________________________________________ >>> spamdyke-users mailing list >>> spamdyke-users@spamdyke.org >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > _______________________________________________ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
