local vs. global counts for checksums

Matus UHLAR - fantomas uhlar@fantomas.sk
Wed Mar 23 19:05:21 UTC 2011

> > From: Matus UHLAR - fantomas <uhlar@fantomas.sk>
> > To: dcc@rhyolite.com
> > because I found mail that appeared 1000 times on our servers much more
> > suspect than mail that appeared 1000 times in the whole world, while
> > only 5 times on our servers. The same can apply for slovakia etc...
> >
> > Or is there I don't understand correctly about DCC?

On 21.03.11 19:19, Vernon Schryver wrote:
> I think DCC detcts bulk mail but spam bulk mail that is also unsolicted.
> I have always said that local whitelists are need to distinguish solicted
> from unsolicited bulk mail.  However, most people disagree with me and
> use DCC as if it detected spam.  That is because maintaining whitelists
> for online order confirmations etc. is too much work for lusers.
> A message that has been reported 1000 times to DCC servers is surely
> bulk mail.

I see your point, and you can count me to those who think that maintaining
bunch of whitelists is a stuff that should be avoided whenever possible...

however I also think that there are different kinds/levels of bulkiness that
could have different scores and/or different ways to get handled.

> > > The best way to use DCC is during the original SMTP transaction,
> > > and so in the MTA.
> >
> > Reporting in the MTA, checking in the spam filter is what I want to achieve
> > :)
> Checking spam in the spam filter after the end of SMTP transaction is
> very popular but I think wrong.

Rejecting clear spam (SA score >10) while keeping the rest for later recheck
or delivering suspicious mail to spam folder is OK I think.
However since I don't plan to reject all bulk messages, I keep spamassassin
to work with the scores. 

> Unlike treating DCC as a spam filter instead of a bulk filter, this
> is due to mail system operators instead of end users.  There is no
> technical or administrative reason to delay spam filtering until after
> the SMTP transaction.  Delaying does not save CPU cycles, because they
> must be spent eventually.  You also do not need to delay filtering to
> generate logs of rejected mail messages including message bodies as
> the DCC client programs dccifd and dccm demonstrate.

the same mail for multiple users can be scanned two times: first with global
set of rules at SMTP level, second time with per-user filters (and their
whitelists). First scan will report checksums to DCC, while the later will
only use them. While this doesn't space CPU cycles (at least for mail that
is not rejected in the first phase), it gives best results...

Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Silvester Stallone: Father of the RISC concept.

More information about the DCC mailing list

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