SA 3.1.3 + DCC 1.3.

Vernon Schryver vjs@calcite.rhyolite.com
Thu Oct 26 23:21:26 UTC 2006


> From: Jeff Mincy 

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

closer to 

   X-DCC--Metrics: clientnm 0; Body=many

for "clientnm"=the host name of the DCC client


> 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+)/) ...

My reading of that has SpamAssassin treating "Body=ok" the same as
"Body=0", which is oviously very wrong.  Low, even zero DCC counts are
unrelated to any sort of whitelisting.  Since I added -c to dccproc,
I've thought the SpamAssassin insistance on parsing DCC numbers wrong.
The right way is to the DCC code compare DCC numbers to DCC thresholds
and have SpamAssassin look for "bulk" in the X-DCC header.  However,
this is the wrong place to talk about how to improve SpamAssassin.


It seems to me that SpamAssassin would ignore a header like

    X-DCC--Metrics: client.example.com; whitelist   

Would that format address most of your and Gary Mills' concerns?

Having the SpamAssasin X-SPAM header for DCC results be missing or
truncated seems safest.  It is better than treating whitelisting
the same as low DCC counts.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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