whiteclnt not working properly?

> Without the X-DCC header line from the log file, it's necessary to
> guess a little.  "d41d8cd9 8f00b204 e9800998 ecf8427e" is the DCC-MD5
> checksum of the null string, so I bet whiteclnt, whitecommon,
> or another included local whitelist file contains "many message_id <>"
> or that dccm is being run with "--t message-id,XXX".  In either case,
> I bet the only "many" in the X-DCC haeder line is for the Message-ID.

Yep, "many message_id <>" is in the whitecommon file.  There was no
X-DCC header in the log, the only thing I removed from the log was the
message body.

I'll watch the logs a bit more closely to see if that whitelist entry
makes sense for me.  I may just remove that line and see what happens.
 
>   2. change the dccm -a value to REJECT or IGNORE.  DISCARD is a
peculiar
>    value for any situation where mail matters and is not merely
>    recreational.  With DISCARD, any sort of false positive is hidden
>    unless you monitor the dccm log carefully, since the sender won't
>    know the message has been lost.  However, if you must monitor the
>    log carefully, what's the difference between reading spam in the
>    log directory or a mailbox/mailfolder?  Instead of monitoring the
>    log carefully, it would probably be better use -aIGNORE to deliver
>    everything and manual `dccproc -t many` to mark spam.

Set to REJECT for now.  I had it set this way before but changed it in
prep for spam traps.  I'll monitor this for a while and see what
happens.

>  3. wait for 1.0.44 where I hope I've fixed the bug.
> 
>  4. contact me privately for a new version of dccm/dccm.c to replace
>    the 1.0.43 version.

I can probably wait for the 44 version, but would be happy to help test
if needed.

- MBM