On Thu, 02 Dec 2004, Matt Kettler stated: > Actually, In my experience, DCC contains very little solicited > bulk. It also contains much less solicited bulk mail than razor > does. This is of course completely contrary to Razor's goal of not > containing solicited email, and DCC's claim of not caring.
Bear in mind that DCC's default bulk threshold is so high (in the millions if I read the code aright) that it's vanishingly unlikely that anything which isn't explicitly reported as spam will get categorized as spam by simple growth of counts. This means that (given a default DCC and SpamAssassin configuration) only spam explicitly reported as such to DCC will land up firing DCC_CHECK. So it acts much like Razor. (e.g. your mail had a DCC count of 11 when I received it, *far* below the DCC bulk threshold.) > I'd treat the DCC and Razor design goals with a huge grain of salt > compared to their real-world behaviors. Both have some FPs, but then > again, so does every rule. Most of my FPs on either Razor or DCC are > solicited bulk mail. The DCC design goal seems to be working: more popular lists have higher DCC counts. I don't think its major goal (determine actual bulkiness via DCC counts) will be successful unless DCC achieves far greater penetration than it has now, and unless people actually report *all* their email (that traversed the net) to DCC as the DCC FAQ suggests (generally by reporting everything and whitelisting local addresses). Particularly legit mailing lists. :) (I've used the DCC counts before to identify personally-addressed email and split away otherwise-unrecognisable mailing list mail into separate mail folders, without needing to hardwire info on return-paths into procmailrc at all. `If we've received bulky mail from this return-path before, treat it as a mailing list' sort of thing. You can't do *that* with Razor.) -- `The sword we forged has turned upon us Only now, at the end of all things do we see The lamp-bearer dies; only the lamp burns on.'
