Sam, Great idea. I've made a simple test and takes longer but it works. I will put on a production server soon.
I'll wait for the next version, that include "recipient validation" will help a lot. Thanks On 09/04/13 11:11, Sam Clippinger wrote: > Interesting ideas. To make it possible to disable authentication from > specific locations, I suppose the easiest way would be to make the > "smtp-auth-level" option valid in a configuration directory. Then you could > create directories using the IP ranges or rDNS names of those countries and > include the command "smtp-auth-level=none". Right now "smtp-auth-level" > can't be used that way, so it would take a little work but shouldn't be > impossible. I'll look into that. > > As for still enforcing filters after authentication happens... that's more > problematic. Beyond the coding required, I'm having trouble imagining what > the configuration file would look like. Specifying one filter is enabled > before authentication but not after, while another filter is enabled both > before and after will get very confusing and error-prone. My gut tells me > this kind of feature would be much more trouble than it's worth. > > This just occurred to me while I'm typing so I haven't tested it, but if you > want some filters to be always enforced whether the client authenticates or > not, what about running spamdyke twice? In your "run" or "smtp_psa" file, do > this: > spamdyke -f /etc/spamdyke.conf1 spamdyke -f /etc/spamdyke.conf2 > /var/qmail/bin/qmail-smtpd > In the second spamdyke, set "smtp-auth-level" to "none" so authentication is > ignored. That configuration should also enable the filters that are always > on -- missing rDNS and so on. For the first spamdyke, set "smtp-auth-level" > to "always" (or "always-encrypted") and enable the filters that can be > bypassed by authentication. When a connection begins, the first spamdyke > will offer and process any authentication and disable any filters it has > enabled. The second spamdyke won't see the authentication (the first one > will "consume" that input) and will always enforce all of its filters. Your > logs would get a little more confusing because any rejections from the second > spamdyke will be logged by the first one as "DENIED_OTHER", but that's a > minor problem. I think it would accomplish what you're trying to do. > > As for stopping a spammer from staying connected for hours on end, you should > be able to do that with the "connection-timeout-secs" option -- it enforces > an absolute time limit whether the connection is idle or not. Of course, it > won't stop the spammer from immediately reconnecting. > > This may come as some surprise, but I've been finishing up the next version > of spamdyke and I hope to have it ready for release soon. This version will > include recipient validation, which is what's holding up the entire release > -- testing that feature has required running 237000 test scripts, which takes > a very long time (especially when I find errors in the scripts and have to > start over). But I mention it because I've also added filters to the > authentication process to require an authenticated connection to send "from" > the same address or domain they used during authentication. That may help in > your situation. > > -- Sam Clippinger > > > > > On Apr 9, 2013, at 6:58 AM, Faris Raouf wrote: > >>> I have a doubt: >>> If a user authenticates with SMTP auth. All filters are ignored? >>> If true, Why? >>> >> All filters other than the reply delay (earlytalker filter) are, as far as >> I'm aware, disabled when smtp authentication happens. >> >> But I was going to post about this too. I also would love the *option* to >> enable filters even if there's authentication. Sam, please can you consider >> this for a future version? >> >> I know it is unusual to want filtering enabled if there's authentication >> going on. Let me explain why I want it: >> >> We get 100s of connections from botnets (almost every connection is from a >> different IP, so fail2ban etc is no good) trying smtp auth dictionary >> attacks. They also use username/password combos from hacked third party >> sites (some of which made the news) where the password were not >> encrypted/didn't have salt. >> >> In order to reduce the impact of such attacks, I want to block smtp auth >> from certain countries - countries where we have no customers and therefore >> nobody should be authenticating from them. These countries are where the >> bulk of these attacks are coming from. Firewalling is not an option as there >> are too many IPs involved. >> >> I already have an local dnsbl set up with country-specific IP ranges loaded, >> which I already use in conjunction with mod_security on port 80 (and also >> via spamdyke on port 25 ). But I want to use this on port 587 too, even when >> someone authenticates correctly. >> >> Yes, I know, there is the potential for some issues -- what if a customer >> goes on vacation to a country that I've blocked. But in general I'm willing >> to risk this. >> >> I also want to block smtp auth if the connecting IP has no rDNS. I've been >> looking at my logs, and not one single legitimate auth in the past 30 days >> has come from an IP with no rDNS. But a reasonable proportion of botnet auth >> attempts have come from IPs with no rDNS. >> >> So basically that's why I would like the option to enable the usual dnsbl, >> rdns, etc etc filtering rules even if authentication happens. >> >> Ideally I'd like a special error message when there's a successful auth from >> a "filtered" IP. This would immediately tell me that the bad guys most >> likely have someone's real username/password combo, allowing me to change >> the password on that account before any damage has occurred. >> >> In addition, please can there also be a time limit option on successful smtp >> auth connections please? Last week I had a spammer who authenticated and >> stayed connected for two and a half hours sending spam after spam (not too >> much damage was done as I saw it happen and stopped the outgoing queue -- I >> just got confused and didn't think to kill the qmail-smtpd process manually. >> But that's another story). >> >> >> >> >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users -- Jorge R. Constenla [email protected] Director General ----------------------------- RED NET GROUP SA Internet Services Provider ----------------------------- Av. Cordoba 1318 Piso 14 "B" C1055AAQ, Capital Federal Buenos Aires - Argentina ----------------------------- Teléfono: (54 11) 4119.2000 Fax : (54 11) 4119.2005 http://www.rednet.com.ar _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
