rcvd_nxt and IP checksum

Sidney Markowitz sidney@sidney.com
Mon Apr 17 06:09:45 UTC 2006

Vernon Schryver wrote:
> Recent versions of dccproc occassionally try to start dccifd when
> dccproc thinks dccproc has been used a lot.
> For perhaps a year, dccifd restarts itself after many kinds of failures

If dccifd restarts itself then spamd does not need to do anything except retry
dccifd each message. Not much is lost in the rare case that dccifd fails in a
way that does not delete the socket. If the restart of dccifd depends on
dccproc being called repeatedly, then there is a problem if spamd only calls
dccproc when the dccifd socket does not exist: When dccifd fails with the
socket not deleted, spamd would never call dccproc. But in that case the
failure mode is that no message hits the DCC rule and the spamd logs will show
errors trying to reach dccifd. That seems like an obvious failure mode without
a catastrophic result, and does not cause a heavy load on your servers. So I
think we can leave spamd as is, testing for the existence of the dccifd socket
every message and only failing over to dccproc when the socket does not exist
or is not writable and readable.

> 10 seconds or perhaps even 15 should be the default.

Ok, I'll change it. Just to make sure, I'll first discuss with the other
SpamAsassin developers what the implications might be on SpamAsassin
performance. I haven't yet been told exactly why it was decreased to 5 seconds
from the longer timeout that it apparently defaulted to in older versions of

> The savings from using dccifd in these
> rare cases would not justify the cost your time to write the SpammAssassin
> or the costs in space in the SA tarballs or the costs of dealing with
> the bugs that are in all code.

That sounds like it's a matter for my judgment as a developer, but it would be
better for your servers to allow use of dccifd. I think that I may be able to
reuse the code that we already have that checks messages with either dccifd or
dccproc, and the result would be even less code and more simplicity than what
we have now due to better modularization. If that is true, I'll go for it.
Otherwise I'll leave it as is, using just dccproc for reports.

 -- Sidney Markowitz

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.