whiteclnt not working properly?

> From: "Mark Motley" <mark@motleynet.com>

> dccm 1.0.43 recently discarded a (non-spam) message, even though
> the env-to address was in the whilteclnt file (names have been
> changed to protect the innocent).
>
> Here's my whiteclnt:
>
> include whitecommon
> ok      env-to  name@motleynet.com

> Message-ID: d41d8cd9 8f00b204 e9800998 ecf8427e

> /opt/dcc/whiteclnt-->spam

> Apparently the whiteclnt did see that this recipient was white
> listed, but still discarded the message (I'm using discard instead of
> reject).
>
> Any ideas?


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.

I further bet that examination of the Received: lines of the message
will show that qmail originated the message.  I won't put much money
on this bet, but qmail is the only common, non-spamware MTA I know of
that fails to include Message-IDs.

If my first bet wins, then the problem is the conflict in the instructions
from the local white list.  The white list is saying to both reject
(or discard) and accept (white-list) the message.  Despite that
conflict, I agree dccm should not be discarding the message.  Skipping
the source code walk-over, I think that without -aDISCARD, the message
would have accepted.

There are possible solutions:

  1. tell dccm to stop paying attention to Message-ID lines by 
     removing "-t message-ID,XXX", perhaps by changing DCCM_XTRA_CKSUMS
     in /var/dcc/dcc_conf.

     There is something to be said for this course regardless of other
     considerations, if you can't be sure your customers will use
     MTA's smart enough to comply with the SMTP standard and include
     Message-IDs.  I use -tMessage_id, but I also use a draconian
     sendmail access_db because I really need to receive mail from
     only some people.  I can live with the false positives that come
    from using -tMessage_id, although I've personally not yet had one.

  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.

   I watch my dccm log with the excuse that I need to know what the
   DCCM is doing.  It might make sense for others to use -aDISCARD
   while shaking down a DCC installation.

 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.


Vernon Schryver    vjs@rhyolite.com