rcvd_nxt and IP checksum

Sidney Markowitz sidney@sidney.com
Sun Apr 16 04:13:10 UTC 2006

Vernon Schryver wrote:
> The 3.1.1 SpamAssassin source differs from what I recalled.  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. That is something that
you could provide with dccifd, perhaps adding a ping to the protocol options
that causes a lightweight query and response to/from the server to verify that
there is a connection.

> 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, or is 5 seconds ok for most people and we should perhaps document it
better and/or add something to the "broken pipe" log message to hint to try
increasing dcc_timeout? Also, we use the same configuration option for both
dccifd and dccproc timeout. Should they have different defaults and therefore
perhaps different options? That last question may be more a matter of
documentation than anything... Presumably a site should use only dccifd or only
dccproc and have everything set up for the one they do use.

> 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.

[regarding the report function:]
> Yes, but that is or should be sufficiently rare that I would continue
> using the simpler dccproc tactic.

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? I already have the code to do it with dccifd, as it is
almost the same as checking with dccifd. If it runs more efficiently and with
less load on your server, I have no problem with adding it in. If dccproc is
more efficient for SpamAssassin and reporting is rare enough not to bother your
servers, then I would keep it as just dccproc.

 -- sidney

More information about the DCC mailing list

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