rcvd_nxt and IP checksum

Vernon Schryver vjs@calcite.rhyolite.com
Fri Apr 14 23:16:40 UTC 2006

From: Sidney Markowitz 

> I've confirmed that SpamAssassin already checks for dccifd with every message,
> so there is no need for me to add any 30 minute timeout. I was confused a bit
>by some caching of options that it does, which turned out not to be relevant to
> this case.

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.  So I'd have to cache the result of the more
expensive check, and that would require some kind of cache invalidation
mechanism, hopefully without adding a gettimeofday() per mail message.
But then I count system calls per request.  The next version of dccifd
will reduce the number of stat()'s per request by 1 in common situations.

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

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.

> There is one place where SpamAssassin is only using dccproc instead of dccifd.
> When a user uses the "report spam" function, SpamAssassin calls dccproc with
> the "-t many" option. Is calling dccifd using "options spam" in the protocol
> equivalent?

Yes, but that is or should be sufficiently rare that I would continue
using the simpler dccproc tactic.

thanks for looking at SpamAssassin,

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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