doing dccproc -t many

Vernon Schryver
Sun Apr 7 21:54:08 UTC 2002

> From: "Tony L. Svanstrom" <>

> ...
>  The average user will use DCC to get rid of e-mails he doesn't want to see,
> and some well-meaning people will report "verified" e-mails as being sent to
> 1000's of people even thought it might have been sent to maybe 3 or 4 (by
> mistake or by not looking closely at the e-mail before reporting it). All
> that's leaving us with a number that can't be trusted beyond being a true/
> false-switch regarding if anyone but you got the same e-mail (actually an
> e-mail that is the same or almost the same, due to the fuzzines)... meaning
> that your whitelist has to include everyone that possibly could send you an
> e-mail, because you can't trust e-mails sent to a cpl of people to have a low
> score.

No, that's not quite right.  You need to do one of two things.  One
possibility is to whitelist those who send mail both to you and to
your loon correspondents who report everything they see as super-bulky.
The other thing is to cut the loons out of your circle of correspondents.
If your correspondents are so loony that they are likely to report
the semi-private mail of your friends as super-bulky, then I think
you need to find a different set of correspondents.

>  BUT... if you were to stop allowing messages to be reported with a high count
>then you could trust messages with high scores to not be e-mails sent to only a
> few people (unless one of those few is a bad guy getting the e-mail in time to
> report it many times before you get it, of course).

What if someone wires the DCC into their MTA or MUA with a bug that
reports every message 5732 time?  What if your loony correspondent does
`repeat 573 dccproc -t many` with a message sent to only you and the loon?

The reason for `dccproc -t many` is that there is no way to prevent
`repeat 17000000 dccproc -t 1`.  You may as well make cheap the first
easier than second, because the second costs your DCC server a lot
more CPU cycles, disk space, and bandwidth.

If you have a tiny number of checksum reporters all well known to you,
then you could trust high scores to indicate spam.  In real life, that
is impossible.  For example, how can we know whether you are a good
guy, a spammer who has taken his medication and so sounds sane today,
or a "hacker"?  How do we know that tomorrow you won't use `repeat
1700000...`?  We can't know for any price that we can afford.  Versign
proved that it is impossible to merely discover whether you own the
domain name for $350.  Checking your character for free
is clearly hopeless.

> So, from my point of view that would remove a lot of the human errors while at
>the same time not let any more mass-sent e-mails pass through (because true UBE
> would get a high number anyways).

I'm not a graduate of the Microsoft School of Programming, and so
I don't like the idea of preventing only some problems and calling
it good enough if the remaining problems are likely.

>  Of course, IRL you might run DCC on a server with 50'000 accounts, and the
> same UBE could be sent to all of them, so you can't really try to keep people
> from reporting higher counts than one; but instead of saying that it's a good
> thing that people boost the counts on unwanted e-mails one could say that the
> nature of DCC is such that doing so will not help the system but will make it
> report the wrong results.

If you run an ISP with 50,000 accounts, then a private DCC server
that listens only to your own MTA could make sense.   50,000 accounts
is not very many, and so I'd guess the DCC would only be 50% as
effective as it would otherwise be.  Worse, unless you report only
the mail sent to your private, completely secret spam traps, your
users would still need whitelists.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.