rcvd_nxt and IP checksum

Vernon Schryver vjs@calcite.rhyolite.com
Sun Apr 16 14:03:03 UTC 2006


> From: Sidney Markowitz 

> >                                                              If it were
> > my code, I'd do more than stat(2) the dccifd socket, to avoid relying
> > on dccifd never having been started or having been shut down cleanly
> > enough delete its socket
>
>I'm not sure of the purpose of this, could you clarify? Spamd does not start or
>restart dccifd. So if the socket is there but not working, spamd will fail when
> it tries to use the socket but will never call dccproc. If we used a more
> expensive check, the only thing we could do besides giving up if dccifd failed
> would be to call dccproc, which would produce the result you don't want of a
> heavier load on your server. It seems that the correct thing to do would be to
> have a watchdog script started up after dccifd is, which periodically tests
> that dccifd is responding and restarts it if it is not. 

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
(none of which, of course, should ever happen).


> > 3.1.1 still has a 5 second timeout.  As some people have written in
> > this mailing list that probably ought to be at least 10 seconds.
>
> dcc_timeout is a configuration option. I couldn't tell from what I saw on the
>mailing list: Is the requirement for 10 seconds so common that it should be the
> default,

10 seconds or perhaps even 15 should be the default.


> > If body URL checking by dccproc or dccifd is enabled in /var/dcc/dcc_conf
> > and /var/dcc/whiteclnt.  In that lesspopular case, the timeout would
> > need to be 40 seconds or even longer depending on the `dccifd -B` limits
> > on DNS blacklist queries.
>
> That does seem to be something for us to document, but not a change to the
> default timeout value.

Yes, merely documentation along the lines of:

    If you use dccproc/dccifd -B and if SpamAssassin complains about
    broken pipes, increase the SpamAssassin XXXXX DCC timeout to 30
    seconds.  Also see the description of Bset:msg-secs=X and
    -Bset:URL-secs=S in the dccifd or dccproc man pages.


> [regarding the report function:]

> Just to be clear about what you mean, are you saying that you don't see a need
> to bother writing the code to do it or that dccproc is more efficient for
> SpamAssassin to use?

Functions that are used rarely are most efficiently implemented with
the simplest, most reliable code that is not outrageously slow.  For
example, a naive bubble sort is a good solution for occassionally sorting
a small number of things instead of spoending the time to choose and
write a more sophisticated solution.  Since dccifd is not always
available, SpamAssassin would have to have both dccifd and dccproc code
to handle the report function.  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.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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