When spamdyke decides to filter a remote connection, it does not
disconnect until there is no chance the message could be allowed. For
example, even if a remote connection has no rDNS entry, it may still
authenticate. In that situation, a premature disconnection will block
legitimate mail, so spamdyke must wait until the SMTP conversation has
moved past the point where authentication takes place. Similarly, if
you are using a sender (or recipient) whitelist, spamdyke must wait
until after the sender (or recipient) has been identified so the
whitelist can be consulted.
Within spamdyke, each filter/option postpones the disconnection until it
has had a chance to run. The end result is that spamdyke will not
disconnect until all the enabled options have been exhausted.
DNS is definitely an issue. It's the #1 thing that causes spamdyke to
run slowly. Installing a caching name server on each of your mail
servers is the best way to make spamdyke run faster. You can also
reduce the number of DNS RBLs and RHSBLs, since each one of those
generates multiple queries.
The DNS code in spamdyke is intended to resolve names as fast as
possible. It constructs and sends DNS packets itself so the timeouts
can be more tightly controlled (using the libc DNS functions can result
in delays of 90 seconds or more per query). In current versions, the
DNS behavior is not configurable. In the upcoming version, I've already
modified the code to allow most of the DNS system to be controlled from
the configuration file (including deactivating it completely). This
includes number of retries, time between retries, name servers to use
and number of simultaneous queries to perform.
If you're seeing 6 DNS retries in your logs, your name servers are
swamped. A retry indicates no response was received at all, most likely
because the query packets were dropped.
-- Sam Clippinger
Ulrich Eckardt wrote:
Just for statistical reasons, if it might interest.
:/var/log# cat /var/log/mail.log.0 | grep DENIED | wc
1225875 19624962 233116876
:/var/log# cat /var/log/mail.log.0 | grep ALLOWED | wc
11055 176880 1993518
That gives us a 99%+ spam ratio on that machine.
Spamdyke is a great software, these numbers really show it.
But since we had some problems, I digged a bit more into it to find out
why/what, etc..
The main reason is that the smtp port on the server is sometimes just
not responding.
This might be due to a hardware issue on a switch. We will change that
and report back, if that solved the problem.
Anyway I found some things that could be worsening the problem or just
be things that could run smoother (or maybe I just don´t unerstand them
and think in a wrong direction :))
Okay: First we have Timeouts ... which is, what our clients report, when
they can´t reach the smtp port:
:/var/log# cat /var/log/mail.log.0 | grep TIMEOUT | wc
14245 256332 2705232
This is more timeouts than ALLOWED.
Feb 10 09:39:23 mail4 spamdyke[25798]: DENIED_RDNS_MISSING from: xxx
mailto:[EMAIL PROTECTED] to: xxx origin_ip: 85.108.22.13 origin_rdns:
(unknown) auth: (unknown)
Feb 10 09:40:24 mail4 spamdyke[25798]: TIMEOUT from: xxx to: xxx
origin_ip: 85.108.22.13 origin_rdns: (unknown) auth: (unknown) reason:
DENIED_RDNS_MISSING
This is just one example line, the others look the same. When spamdyke
decided that the connection will be denied ... does it make any sense to
wait for a relpy and so reach the spamdyke default timeout of 60
seconds. Isn´t that binding a slot for nothing useful? Or is it an RFC
thing and you have to do it for proper handling it?
Here some more of the DNS handling.
Between each attempt are 10 seconds wait time ... Okay, but shouldn´t 4
times be enough?
This give a minute until the connection is finally closed.
:/var/log# cat /var/log/mail.log.0 | grep 'attempt 2' | wc
762537 10675518 96348031
:/var/log# cat /var/log/mail.log.0 | grep 'attempt 3' | wc
15234 213276 2025077
:/var/log# cat /var/log/mail.log.0 | grep 'attempt 4' | wc
13287 186018 1770517
:/var/log# cat /var/log/mail.log.0 | grep 'attempt 5' | wc
11268 157752 1503633
:/var/log# cat /var/log/mail.log.0 | grep 'attempt 6' | wc
5768064 70596
:/var/log# cat /var/log/mail.log.0 | grep 'attempt 7' | wc
0 0 0
And last, this is one average mailserver out of 5, which is doing 2.75
mio queries a day.
Makes 13.75 queries for all 5, which is an 150 per second on average.
This probably means that it will be up to 1500 per second in peak times.
Is there a limit on dns queries per second on the dns servers itself or
is a limit on the rootservers only allowing a certain amount of queries
per server per second?
Does anybody know about any limit on the dns this or the other way.
xxx:~# cat /var/log/mail.log.0 | grep querying | wc
2751492 38520890 339239494
