SA 3.1.3 + DCC 1.3.

Jeff Mincy
Thu Oct 26 17:31:40 UTC 2006

On 24 Oct 2006, wrote:

> This concerns an old thread including
>> From: Jeff Mincy 
>> Date: Thu, 22 Jun 2006 21:38:06 -0400
>>>> The empty string is kind of a bummer.   The empty string is also
>>>> returned for various problems.
>>>> Would it be possible to return a different string for whitelisted
>>>> messages?  Maybe something like:
>> I have also seen empty string results for timeouts and also
>> crashes when using dccproc (eg like the crash fixed in 1.3.25).
>> I want locally whitelisted messages to have a different result
>> than timeouts and crashes.
> I think I finally have a better answer.
> First, the so called empty strings are artifacts of SpamAssassin or
> short shell scripts.  What is happening is that the DCC client,
> dccproc, dccifd, or dccm, does not currently add an X-DCC header to
> the passing message if communication with the DCC server failed or
> was prohibited by local whitelisting.  I see three cases:
> 1. Version 1.3.43 will synthesize an X-DCC header when the DCC
> server chitchat fails but the local whiteclnt file (global or
> per-user) blacklists the message.

Yes - sounds good.

The synthesized X-DCC header would presumably look like:
  X-DCC--Metrics: - 0; Body=many Fuz1=many Fuz2=many
Or were you thinking something else?

> 2. I don't like chatty programs.  If the DCC client has nothing to
> say about a mail message because talk with the DCC server failed,
> then I think the DCC client should say nothing and so the X-DCC
> header should be absent.  That will leave SpamAssassin saying
> whatever it says in such cases.

Saying nothing for server failures will work fine.  I'd prefer a short
failure message for the cases where the DCC client knows why the dcc
server failed - eg 'timed out'.  But, either way, the dcc check in
SpamAssassin will fail.

> 3. If the local whiteclnt file whitelist a mail message, should the
> X-DCC header say so?  Except for upward compatibility worries, I
> think so.  I'm thinging of making the X-DCC header be something like
> this in that case:
> X-DCC--Metrics: - 0; ok Body=0 Fuz1=0 Fuz2=0
> Would that break things such as SpamAssassin?

The 'ok Body=0 Fuz1=0 Fuz2=0' result is fine.  It addresses my original
concern that no header is being returned for whitelisted messages.  My
only comment is that this header is perhaps on the subtle side - my
original proposal was to return a result more like:
  X-DCC--Metrics: - 0; Body=ok Fuz1=ok Fuz2=ok; whitelisted

Anyway, SpamAssassin will handle just about anything, as long as there
are Body=, Fuz1=, and Fuz2= parts somewhere in the X-DCC header.
SpamAssassin does the following perl code on the header ($response
is the X-DCC header result).
  $response =~ s/many/999999/ig;
  $response =~ s/ok\d?/0/ig;

  if ($response =~ /Body=(\d+)/) ...
  if ($response =~ /Fuz1=(\d+)/) ...
  if ($response =~ /Fuz2=(\d+)/) ...

The change is upward compatible, at least for SpamAssassin.
I don't know about other programs that may be reading the header.



More information about the DCC mailing list

Contact by mail or use the form.