The problem is that remote servers (spambots) are not disconnecting
after getting a rejection message. When spamdyke sends a rejection code
and there's no chance the connection could be allowed (e.g. no
whitelists remain to be matched), it disconnects qmail and allows the
qmail process to exit. spamdyke then continues imitating an SMTP server
for the remainder of the connection. However, because spamdyke 4.0 has
no idle timeout by default, it's up to the remote server to disconnect.
I changed this in spamdyke 4.0.5-beta2. Now, when qmail is disconnected
and no idle timeout is set, spamdyke will reset the idle timeout to 20
minutes. This matches qmail's idle timeout, so the resulting behavior
should match qmail's before spamdyke was installed.
Version 4.0.5 is very close. Over the weekend, I believe I found the
cause of David's segmentation faults (woohoo!). All that remains is a
bit more testing on my systems and some final testing on David's server
to make sure the bug is gone.
-- Sam Clippinger
David Stiller wrote:
> Hi Kris,
>
> admins normally shouldn't "clean up" logs - you'd be lost, if someone
> attacks your machine, or you'd have to
> analyze something like this :-). Tell your co-admins to keep logs for a
> minimum of a week, with logrotate or
> something similar.
>
> Concerning the "hanging" Spamdyke process i bet it'll be fixed in the
> next release. Sam and me are debugging
> a segmentation fault and he also he already fixed a problem with
> deprecated (probably never closing) processes.
>
> Have a look in your /var/log/messages, if you can find a segmentation
> fault at 20:27 from yesterday, if yes,
> you probably hit the same bug as i did on SuSE.
>
> Kind regards,
> David
>
> Kris Van Hees schrieb:
>
>> I had a problem where my mail server stopped being able to service
>> connections
>> because I had as many hanging spamdyke processes as was allowed in my
>> tcpserver
>> config (-c option). Unfortunately, the processes were cleaned up by another
>> admin before I could look at them.
>>
>> And then, I just ran into the same situation again, where a spamdyke process
>> is hanging, and has been hanging for 2.5 hours so far. Here is output from
>> log-level debug in spamdyke (XXXXX substituted for domain name):
>>
>> Oct 5 20:27:16 saffron spamdyke[3978]:
>> DEBUG(filter_rdns_missing()@filter.c:841): checking for missing rDNS; rdns:
>> (unknown)
>> Oct 5 20:27:16 saffron spamdyke[3978]: FILTER_RDNS_MISSING ip: 77.30.98.26
>> Oct 5 20:27:16 saffron spamdyke[3978]:
>> DEBUG(filter_ip_whitelist()@filter.c:1120): searching IP whitelist file(s);
>> ip: 77.30.98.26
>> Oct 5 20:27:17 saffron spamdyke[3978]:
>> DEBUG(filter_recipient_relay()@filter.c:2176): checking relaying;
>> relay-level: 3 recipient: [EMAIL PROTECTED] ip: 77.30.98.26 rdns: (unknown)
>> local_recipient: true relaying_allowed: false
>> Oct 5 20:27:17 saffron spamdyke[3978]: DENIED_RDNS_MISSING from: [EMAIL
>> PROTECTED] to: [EMAIL PROTECTED] origin_ip: 77.30.98.26 origin_rdns:
>> (unknown) auth: (unknown)
>>
>> I would have expected the connection to be dropped at this point, and
>> spamdyke
>> to exit. Looking at lsof -i output for this process, I get:
>>
>> spamdyke 3978 qmaild 0u IPv4 732880026 TCP
>> saffron.alchar.org:smtp->77.30.98.26:56004 (ESTABLISHED)
>> spamdyke 3978 qmaild 1u IPv4 732880026 TCP
>> saffron.alchar.org:smtp->77.30.98.26:56004 (ESTABLISHED)
>> spamdyke 3978 qmaild 3u IPv4 732880028 UDP *:41956
>>
>> So, the connection is still alive. Netstat -an confirms this:
>>
>> tcp 0 0 192.168.0.1:25 77.30.98.26:56004
>> ESTABLISHED
>>
>> Looking at strace output, spamdyke is stuck in a select loop, waiting for
>> something:
>>
>> Process 3978 attached - interrupt to quit
>> select(1, [0], NULL, NULL, {1, 580000}) = 0 (Timeout)
>> time(NULL) = 1223261329
>> select(1, [0], NULL, NULL, {2, 0}) = 0 (Timeout)
>> time(NULL) = 1223261331
>> select(1, [0], NULL, NULL, {2, 0}) = 0 (Timeout)
>> time(NULL) = 1223261333
>> select(1, [0], NULL, NULL, {2, 0} <unfinished ...>
>> Process 3978 detached
>>
>> Looking at the process using gdb didn't show anything interesting, because
>> the
>> backtrace is trash (possibly in part due to me stripping the spamdyke
>> executable). It simply lists the top frame as:
>>
>> #0 0xb7ec39f8 in select () from /lib/tls/libc.so.6
>>
>> and the rest if garbage. Smells like possible memory corruption.
>>
>> Anyone seen something like this? This is with spamdyke 4.0.4.
>>
>> Kris
>>
>>
>>
>
> _______________________________________________
> 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
