[spamdyke-users] DDOS Help
I have a client that uses spamdyke but I am new to it. I've read through the documentation so I am vaguely familiar with it now. They have been under a DDOS attack for about a month now. It's not enough to bring their servers down. Basically it's a bunch of SMTP traffic attempting to send spam. Spamdyke has been doing a great job of blocking the connections usually with the DENIED_RDNS_MISSING error. The problem is this attack has been eating up a lot of their bandwidth. As a temporary measure their ISP has asked them to just drop the invalid connections instead of issuing the appropriate SMTP response codes. Is this something spamdyke can be configured to do? I did not see anything obvious in the documentation. -- J.R. Lillard System / Network Admin Web Programmer Hyphen Communications ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DDOS Help
On 09/01/2012 08:17 AM, J.R. Lillard wrote: I have a client that uses spamdyke but I am new to it. I've read through the documentation so I am vaguely familiar with it now. They have been under a DDOS attack for about a month now. It's not enough to bring their servers down. Basically it's a bunch of SMTP traffic attempting to send spam. Spamdyke has been doing a great job of blocking the connections usually with the DENIED_RDNS_MISSING error. The problem is this attack has been eating up a lot of their bandwidth. As a temporary measure their ISP has asked them to just drop the invalid connections instead of issuing the appropriate SMTP response codes. Is this something spamdyke can be configured to do? I did not see anything obvious in the documentation. -- J.R. Lillard System / Network Admin Web Programmer Hyphen Communications ___ Hey JR, I don't know the answer to this question. Sam will no doubt chime in on spamdyke's capability regarding dropping connections. My opinion is that this would not be an appropriate thing to do. Given what you've described, I would consider whether the host is running a caching nameserver or not. What are the contents of /etc/resolv.conf ? spamdyke is rather heavy on DNS, and network traffic can be reduced a bit by running a resolver on localhost (127.0.0.1). Personally, I use the pdns-recursor package on CentOS. I expect that there's probably a powerdns recursor available for your platform as well. You'll also want to check that you're not using too many dns-blacklist-entry= parameters. In this area, more isn't necessarily better. Personally, I use only zen.spamhaus.org and bl.spamcop.net. While DNS traffic isn't large from a bandwidth standpoint, I expect that it's larger than SMTP response codes. If the DDOS attacks are coming from a single group of IP addresses, having a caching nameserver on localhost will provide a substantial reduction in network/DNS traffic. HTH. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Where to run the caching DNS resolver
A novice question perhaps, but does it matter much where one runs the local caching resolver? I have a LAN with IP 10.x.x.x and simply use 10.0.0.1 as the local IP for the resolver. My understanding is that any local IP can be used so long as it can be reached by those functions needing access to it. Would I gain any advantage by using 127.0.0.1 instead? On 9/1/2012 11:00 AM, spamdyke-users-requ...@spamdyke.org wrote: Given what you've described, I would consider whether the host is running a caching nameserver or not. What are the contents of /etc/resolv.conf ? spamdyke is rather heavy on DNS, and network traffic can be reduced a bit by running a resolver on localhost (127.0.0.1). ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DDOS Help
Unfortunately spamdyke can't do this right now. If you really need it to, you could always modify the filter_rdns_missing() function in filter.c -- just insert a call to exit() within the if() statement and recompile. Any time the filter is triggered, spamdyke will immediately exit without logging anything or outputting anything to the remote client. In order for this to work correctly, you'll need to enable the reject-empty-rdns filter in the global configuration file and not use configuration directories. Note this will break some of spamdyke's other functionality. For example, if someone is delivering mail from a host without an rDNS name and is whitelisted or trying to authenticate, this change will drop them too (it'll trigger before the whitelist and authentication code runs). Also, because no logging will take place, you won't be able to tell how much activity is still going on. However, I agree with Eric that this is probably not the right approach. If the goal is to reduce the level of packet traffic, I would go all the way and block the connections at the firewall. That would reduce the traffic to just a single incoming packet (that gets dropped) instead of three packets to establish the connection, at least two to look up the rDNS (probably more) and two to close the connection. It wouldn't be hard -- you could use the spamdyke log messages to find the IPs that are being rejected for missing rDNS, then further filter the list based on the target address (presumably only one or two domains are under attack). The script can use iptables (on Linux) to add a rule to just drop any SYN packets from those IPs. If you're clever about it, the script can keep a little more information about the IPs, such as when they were blocked, so they will fall off the list after a day/week/month/etc. This sort of script would be better than modifying spamdyke because it would only catch rejections that weren't whitelisted or authenticated. You could also add exceptions to the script so certain IPs would never be blocked by it, even if they were being rejected by spamdyke. It would also let you monitor the ongoing activity to see if it's stopped. I happen to have such a script you could use as a starting point. :) I wrote this years ago when I got tired of watching zombie bots trying to bruteforce their way into FTP and POP3 connections; I call it bruteforce_blocker.sh and it runs every 30 minutes on my server. Basically, it searches the logs for rejection messages from those two services and counts them up. If there are more than X rejections from an IP, it creates a file in a special folder (/etc/rc.d/firewall_blocks) with that IP's name. Then it re-runs the script that sets up my firewall rules (rc.firewall). That script clears the existing firewall rules, adds blocks for all of the IPs in the special folder (unless they are listed in /etc/rc.d/unblockable_ips), then sets the normal access rules. It also checks the timestamp on the files and deletes any that are more than 7 days old, so IPs eventually fall off the block list. You would need to modify the first script to look for spamdyke's log messages and the second script to block SMTP access, but it shouldn't be very hard. And of course modify the normal access rules, since your setup is undoubtedly different from mine. My server runs CentOS, so if you're on a different platform you may need to make some changes to the commands (especially iptables) but the concepts should be the same. Good luck! bruteforce_blocker.sh Description: Binary data rc.firewall Description: Binary data -- Sam Clippinger On Sep 1, 2012, at 11:45 AM, Eric Shubert wrote: On 09/01/2012 08:17 AM, J.R. Lillard wrote: I have a client that uses spamdyke but I am new to it. I've read through the documentation so I am vaguely familiar with it now. They have been under a DDOS attack for about a month now. It's not enough to bring their servers down. Basically it's a bunch of SMTP traffic attempting to send spam. Spamdyke has been doing a great job of blocking the connections usually with the DENIED_RDNS_MISSING error. The problem is this attack has been eating up a lot of their bandwidth. As a temporary measure their ISP has asked them to just drop the invalid connections instead of issuing the appropriate SMTP response codes. Is this something spamdyke can be configured to do? I did not see anything obvious in the documentation. -- J.R. Lillard System / Network Admin Web Programmer Hyphen Communications ___ Hey JR, I don't know the answer to this question. Sam will no doubt chime in on spamdyke's capability regarding dropping connections. My opinion is that this would not be an appropriate thing to do. Given what you've described, I would consider whether the host is running a caching nameserver or not. What are the contents
Re: [spamdyke-users] Where to run the caching DNS resolver
If 10.0.0.1 is the IP of the local host on the LAN, it shouldn't matter at all. The OS will realize the IP address is assigned to the local NIC and won't send any packets across the wire. The only reason it might be a problem would be if your firewall is configured to block incoming DNS requests from your LAN, but in that case you would realize the mistake immediately because no DNS queries would ever succeed. :) -- Sam Clippinger On Sep 1, 2012, at 12:39 PM, BC wrote: A novice question perhaps, but does it matter much where one runs the local caching resolver? I have a LAN with IP 10.x.x.x and simply use 10.0.0.1 as the local IP for the resolver. My understanding is that any local IP can be used so long as it can be reached by those functions needing access to it. Would I gain any advantage by using 127.0.0.1 instead? On 9/1/2012 11:00 AM, spamdyke-users-requ...@spamdyke.org wrote: Given what you've described, I would consider whether the host is running a caching nameserver or not. What are the contents of /etc/resolv.conf ? spamdyke is rather heavy on DNS, and network traffic can be reduced a bit by running a resolver on localhost (127.0.0.1). ___ 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
Re: [spamdyke-users] DDOS Help
Iptables was my first thought but half a million ips seemed like too much for it. How many rules have you had with your script? J.R. Lillard System / Network Admin Web Programmer Hyphen Communications On Sep 1, 2012 4:09 PM, Sam Clippinger s...@silence.org wrote: Unfortunately spamdyke can't do this right now. If you really need it to, you could always modify the filter_rdns_missing() function in filter.c -- just insert a call to exit() within the if() statement and recompile. Any time the filter is triggered, spamdyke will immediately exit without logging anything or outputting anything to the remote client. In order for this to work correctly, you'll need to enable the reject-empty-rdns filter in the global configuration file and not use configuration directories. Note this will break some of spamdyke's other functionality. For example, if someone is delivering mail from a host without an rDNS name and is whitelisted or trying to authenticate, this change will drop them too (it'll trigger before the whitelist and authentication code runs). Also, because no logging will take place, you won't be able to tell how much activity is still going on. However, I agree with Eric that this is probably not the right approach. If the goal is to reduce the level of packet traffic, I would go all the way and block the connections at the firewall. That would reduce the traffic to just a single incoming packet (that gets dropped) instead of three packets to establish the connection, at least two to look up the rDNS (probably more) and two to close the connection. It wouldn't be hard -- you could use the spamdyke log messages to find the IPs that are being rejected for missing rDNS, then further filter the list based on the target address (presumably only one or two domains are under attack). The script can use iptables (on Linux) to add a rule to just drop any SYN packets from those IPs. If you're clever about it, the script can keep a little more information about the IPs, such as when they were blocked, so they will fall off the list after a day/week/month/etc. This sort of script would be better than modifying spamdyke because it would only catch rejections that weren't whitelisted or authenticated. You could also add exceptions to the script so certain IPs would never be blocked by it, even if they were being rejected by spamdyke. It would also let you monitor the ongoing activity to see if it's stopped. I happen to have such a script you could use as a starting point. :) I wrote this years ago when I got tired of watching zombie bots trying to bruteforce their way into FTP and POP3 connections; I call it bruteforce_blocker.sh and it runs every 30 minutes on my server. Basically, it searches the logs for rejection messages from those two services and counts them up. If there are more than X rejections from an IP, it creates a file in a special folder (/etc/rc.d/firewall_blocks) with that IP's name. Then it re-runs the script that sets up my firewall rules (rc.firewall). That script clears the existing firewall rules, adds blocks for all of the IPs in the special folder (unless they are listed in /etc/rc.d/unblockable_ips), then sets the normal access rules. It also checks the timestamp on the files and deletes any that are more than 7 days old, so IPs eventually fall off the block list. You would need to modify the first script to look for spamdyke's log messages and the second script to block SMTP access, but it shouldn't be very hard. And of course modify the normal access rules, since your setup is undoubtedly different from mine. My server runs CentOS, so if you're on a different platform you may need to make some changes to the commands (especially iptables) but the concepts should be the same. Good luck! -- Sam Clippinger On Sep 1, 2012, at 11:45 AM, Eric Shubert wrote: On 09/01/2012 08:17 AM, J.R. Lillard wrote: I have a client that uses spamdyke but I am new to it. I've read through the documentation so I am vaguely familiar with it now. They have been under a DDOS attack for about a month now. It's not enough to bring their servers down. Basically it's a bunch of SMTP traffic attempting to send spam. Spamdyke has been doing a great job of blocking the connections usually with the DENIED_RDNS_MISSING error. The problem is this attack has been eating up a lot of their bandwidth. As a temporary measure their ISP has asked them to just drop the invalid connections instead of issuing the appropriate SMTP response codes. Is this something spamdyke can be configured to do? I did not see anything obvious in the documentation. -- J.R. Lillard System / Network Admin Web Programmer Hyphen Communications ___ Hey JR, I don't know the answer to this question. Sam will no doubt chime in on spamdyke's capability regarding dropping
Re: [spamdyke-users] DDOS Help
J.R. Lillard wrote on 2012-09-02 00:30: Iptables was my first thought but half a million ips seemed like too much for it. How many rules have you had with your script? IPs are part of classes. If you i.e. got no legit users from certain class, nor your logs do not show any legit mails comming from certain class, ban whole class C and even B and further when needed. Let users know you are fighting DDOS, so they will be aware of some sacrifices. Regards, -- Daddy, what Formatting drive C: means?... Marcin http://wfmh.org.pl/carlos/ ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DDOS Help
Fail2ban El sep 1, 2012 5:41 p.m., Marcin Orlowski car...@wfmh.org.pl escribió: J.R. Lillard wrote on 2012-09-02 00:30: Iptables was my first thought but half a million ips seemed like too much for it. How many rules have you had with your script? IPs are part of classes. If you i.e. got no legit users from certain class, nor your logs do not show any legit mails comming from certain class, ban whole class C and even B and further when needed. Let users know you are fighting DDOS, so they will be aware of some sacrifices. Regards, -- Daddy, what Formatting drive C: means?... Marcin http://wfmh.org.pl/carlos/ ___ 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
Re: [spamdyke-users] DDOS Help
On Sep 1, 2012, at 11:17 AM, J.R. Lillard j...@hyphen.org wrote: I have a client that uses spamdyke but I am new to it. I've read through the documentation so I am vaguely familiar with it now. They have been under a DDOS attack for about a month now. It's not enough to bring their servers down. Basically it's a bunch of SMTP traffic attempting to send spam. Spamdyke has been doing a great job of blocking the connections usually with the DENIED_RDNS_MISSING error. The problem is this attack has been eating up a lot of their bandwidth. As a temporary measure their ISP has asked them to just drop the invalid connections instead of issuing the appropriate SMTP response codes. Is this something spamdyke can be configured to do? I did not see anything obvious in the documentation. Are the spammers attempting to deliver spam to their server, or to relay spam through it? On my server, SMTP submission requires authentication (if it didn't, I'd be running an open relay) so I see fairly regular attempts by spammers to guess usernames and passwords. While I think it would take them a very very long time indeed to get anywhere, I don't want to give them the opportunity, so I run fail2ban. fail2ban simply watches the VPOPMail logs and, after a certain number of failed attempts from a given IP, simply adds that IP to the iptables firewall, at which point the spammer's packets just get null-routed and it's all over. fail2ban can actually be configured to watch a variety of logs for a variety of conditions, so even if your problem isn't identical, it might be possible to set up fail2ban watch spamdyke's logs and ban anything that gets DENIED_RDNS_MISSING. That would certainly accomplish the drop invalid connections measure suggested by their ISP. I think you can just 'yum install fail2ban' and take it from there. You'll need to read up a bit on how to set up fail2ban's jails, but it's not that complex. If it turns out that spamdyke won't do what you want, try fail2ban. Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Where to run the caching DNS resolver
Sam's right of course. :) I think the question might have been (as I read it) regarding a configuration where the resolver is on the local network (private lan), but not on the host which is running spamdyke (not accessible as 127.0.0.1). This is not as ideal as having the resolver running on spamdyke's host, as all DNS traffic hits the wire in this case. However, cached requests don't make it out to the ISP, so it would help in that regard. If your LAN isn't hurting for bandwidth, this setup could be sufficient, but it's not ideal. I hope this makes sense. -- -Eric 'shubes' On 09/01/2012 02:10 PM, Sam Clippinger wrote: If 10.0.0.1 is the IP of the local host on the LAN, it shouldn't matter at all. The OS will realize the IP address is assigned to the local NIC and won't send any packets across the wire. The only reason it might be a problem would be if your firewall is configured to block incoming DNS requests from your LAN, but in that case you would realize the mistake immediately because no DNS queries would ever succeed. :) -- Sam Clippinger On Sep 1, 2012, at 12:39 PM, BC wrote: A novice question perhaps, but does it matter much where one runs the local caching resolver? I have a LAN with IP 10.x.x.x and simply use 10.0.0.1 as the local IP for the resolver. My understanding is that any local IP can be used so long as it can be reached by those functions needing access to it. Would I gain any advantage by using 127.0.0.1 instead? On 9/1/2012 11:00 AM, spamdyke-users-requ...@spamdyke.org wrote: Given what you've described, I would consider whether the host is running a caching nameserver or not. What are the contents of /etc/resolv.conf ? spamdyke is rather heavy on DNS, and network traffic can be reduced a bit by running a resolver on localhost (127.0.0.1). ___ 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
Re: [spamdyke-users] DDOS Help
Half a million might be too much. :) I honestly don't know what iptables can do, it's only ever stopped a couple dozen IPs at a time for me. You'd definitely have to rewrite my script to store the IP files in multiple subdirectories, since most filesystems can't handle half a million files in a single folder. -- Sam Clippinger On Sep 1, 2012, at 5:30 PM, J.R. Lillard j...@hyphen.org wrote: Iptables was my first thought but half a million ips seemed like too much for it. How many rules have you had with your script? J.R. Lillard System / Network Admin Web Programmer Hyphen Communications On Sep 1, 2012 4:09 PM, Sam Clippinger s...@silence.org wrote: Unfortunately spamdyke can't do this right now. If you really need it to, you could always modify the filter_rdns_missing() function in filter.c -- just insert a call to exit() within the if() statement and recompile. Any time the filter is triggered, spamdyke will immediately exit without logging anything or outputting anything to the remote client. In order for this to work correctly, you'll need to enable the reject-empty-rdns filter in the global configuration file and not use configuration directories. Note this will break some of spamdyke's other functionality. For example, if someone is delivering mail from a host without an rDNS name and is whitelisted or trying to authenticate, this change will drop them too (it'll trigger before the whitelist and authentication code runs). Also, because no logging will take place, you won't be able to tell how much activity is still going on. However, I agree with Eric that this is probably not the right approach. If the goal is to reduce the level of packet traffic, I would go all the way and block the connections at the firewall. That would reduce the traffic to just a single incoming packet (that gets dropped) instead of three packets to establish the connection, at least two to look up the rDNS (probably more) and two to close the connection. It wouldn't be hard -- you could use the spamdyke log messages to find the IPs that are being rejected for missing rDNS, then further filter the list based on the target address (presumably only one or two domains are under attack). The script can use iptables (on Linux) to add a rule to just drop any SYN packets from those IPs. If you're clever about it, the script can keep a little more information about the IPs, such as when they were blocked, so they will fall off the list after a day/week/month/etc. This sort of script would be better than modifying spamdyke because it would only catch rejections that weren't whitelisted or authenticated. You could also add exceptions to the script so certain IPs would never be blocked by it, even if they were being rejected by spamdyke. It would also let you monitor the ongoing activity to see if it's stopped. I happen to have such a script you could use as a starting point. :) I wrote this years ago when I got tired of watching zombie bots trying to bruteforce their way into FTP and POP3 connections; I call it bruteforce_blocker.sh and it runs every 30 minutes on my server. Basically, it searches the logs for rejection messages from those two services and counts them up. If there are more than X rejections from an IP, it creates a file in a special folder (/etc/rc.d/firewall_blocks) with that IP's name. Then it re-runs the script that sets up my firewall rules (rc.firewall). That script clears the existing firewall rules, adds blocks for all of the IPs in the special folder (unless they are listed in /etc/rc.d/unblockable_ips), then sets the normal access rules. It also checks the timestamp on the files and deletes any that are more than 7 days old, so IPs eventually fall off the block list. You would need to modify the first script to look for spamdyke's log messages and the second script to block SMTP access, but it shouldn't be very hard. And of course modify the normal access rules, since your setup is undoubtedly different from mine. My server runs CentOS, so if you're on a different platform you may need to make some changes to the commands (especially iptables) but the concepts should be the same. Good luck! -- Sam Clippinger On Sep 1, 2012, at 11:45 AM, Eric Shubert wrote: On 09/01/2012 08:17 AM, J.R. Lillard wrote: I have a client that uses spamdyke but I am new to it. I've read through the documentation so I am vaguely familiar with it now. They have been under a DDOS attack for about a month now. It's not enough to bring their servers down. Basically it's a bunch of SMTP traffic attempting to send spam. Spamdyke has been doing a great job of blocking the connections usually with the DENIED_RDNS_MISSING error. The problem is this attack has been eating up a lot of their bandwidth. As a temporary measure their ISP has asked them to just
Re: [spamdyke-users] Where to run the caching DNS resolver
I think I understand what you are saying. My local LAN is quite simple: only one *nix box and it sits between the internet source and the rest of the machines on my LAN. That one box contains two NICs - the public (WAN-side NIC) and the private (LAN-side NIC) and runs spamdyke (as well as myriad other processes including qmail). The LAN-side NIC is the 10.0.0.1 IP and that is where the resolving cache runs. The box owns the 127.0.0.1 IP, right, just as every over box on the LAN has its own 127.0.0.1 (local host)? I'm presuming that if I had a second *nix box on the LAN and was running spamdyke over there, then I'd potentially be creating a lag time in responsiveness. Am I understanding what you are saying? PS - my email server has only one customer, me. On 9/1/2012 8:38 PM, spamdyke-users-requ...@spamdyke.org wrote: I think the question might have been (as I read it) regarding a configuration where the resolver is on the local network (private lan), but not on the host which is running spamdyke (not accessible as 127.0.0.1). This is not as ideal as having the resolver running on spamdyke's host, as all DNS traffic hits the wire in this case. However, cached requests don't make it out to the ISP, so it would help in that regard. If your LAN isn't hurting for bandwidth, this setup could be sufficient, but it's not ideal. I hope this makes sense. ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DDOS Help
I recently banned all of China from smtp_auth on my server.. No complaints from legitimate customers so far -- China ranges are available on the net. fail2ban is great, use that too.. Perhaps connections-per-source limiting from xinetd is also a good idea.. Good luck.. -t On 09/02/2012 01:39 AM, Marcin Orlowski wrote: J.R. Lillard wrote on 2012-09-02 00:30: Iptables was my first thought but half a million ips seemed like too much for it. How many rules have you had with your script? IPs are part of classes. If you i.e. got no legit users from certain class, nor your logs do not show any legit mails comming from certain class, ban whole class C and even B and further when needed. Let users know you are fighting DDOS, so they will be aware of some sacrifices. Regards, ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Where to run the caching DNS resolver
On 09/01/2012 08:17 PM, BC wrote: I think I understand what you are saying. My local LAN is quite simple: only one *nix box and it sits between the internet source and the rest of the machines on my LAN. That one box contains two NICs - the public (WAN-side NIC) and the private (LAN-side NIC) and runs spamdyke (as well as myriad other processes including qmail). The LAN-side NIC is the 10.0.0.1 IP and that is where the resolving cache runs. The box owns the 127.0.0.1 IP, right, just as every over box on the LAN has its own 127.0.0.1 (local host)? Right. I'm presuming that if I had a second *nix box on the LAN and was running spamdyke over there, then I'd potentially be creating a lag time in responsiveness. True. Am I understanding what you are saying? Yep. PS - my email server has only one customer, me. That's how I started as well. :) You might want to consider putting an IPCop (or other suitable firewall) host on your perimeter. I think it's the next logical step for your situation. On 9/1/2012 8:38 PM, spamdyke-users-requ...@spamdyke.org wrote: I think the question might have been (as I read it) regarding a configuration where the resolver is on the local network (private lan), but not on the host which is running spamdyke (not accessible as 127.0.0.1). This is not as ideal as having the resolver running on spamdyke's host, as all DNS traffic hits the wire in this case. However, cached requests don't make it out to the ISP, so it would help in that regard. If your LAN isn't hurting for bandwidth, this setup could be sufficient, but it's not ideal. I hope this makes sense. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
