Sam,
Thanks for the explanation. I'll set an explicit idle timeout to avoid the
current problem (as suggested by another response on the list as well). I
look forward to 4.0.5. Other than this one problem (which of course had to
happen while I was gone), spamdyke has been great.
Kris
On Mon, Oct 06, 2008 at 09:26:41AM -0500, Sam Clippinger wrote:
> 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
--
Never underestimate a Mage with:
- the Intelligence to cast Magic Missile,
- the Constitution to survive the first hit, and
- the Dexterity to run fast enough to avoid being hit a second time.
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
