local vs. global counts for checksums

Vernon Schryver vjs@calcite.rhyolite.com
Mon Mar 21 19:19:51 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?

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.

> > 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.  It is wrong because false positives
(messages that are wrongly detected as spam) either disappear into
blackholes or are "bounced" in non-delivery reports (NDRs).
True positives (correctly detected spam) that is "bounced" often results
in "backscatter" to innocent third parties whose mailboxes have been
forged as the sender of of the spam.  Too much backscatter and you will
be blacklisted by enough of the Internet.
So bouncing spam is even worse than discarding it.

On the other hand, if you detect spam during the SMTP transaction reject
it with SMTP 5yz error codes, then the legitimate senders of false
positives are informed by their own MTA and know to try something else.
As a bonus, some lawful unsolicted bulk email advertisers honor persistent
SMTP rejections of their junk with an automatic "remove."

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.

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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