doing dccproc -t many

Vernon Schryver
Sun Apr 7 23:30:21 UTC 2002

> From: "Tony L. Svanstrom" <>

> > 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.
>  Having the option, and saying that it's a good thing, does a hell of a lot
> more than avoiding a potentially non-cheap way of doing the same thing.

It's in the ancient tradition of documenting a characteristic as a feature.

>                                                                    When it
> comes to not being able to prevent people from doing a repeat I'm not sure I
> follow you, are you saying that it's impossible to check that not the same
> checksums are sent from the same server over and over again without any delay?

Spam often looks the same as the bad thing.  For example, 2 or 3 weeks
ago my system received 1008 copies of the same message as fast as the
spammer could send them.  Each STMP transaction was to a single address
in the list at
Any DCC server for an ISP sees the same or worse many times every day
as spammers each send to a few percent of a 1,000,000 active mailboxes.

On the other hand, a bad guy can spread out nefarious reports among
linked DCC servers and in time so that no single server sees a high
rate.  There are rate limiting mechanisms in the DCC server to defend
against obvious `repeat 10000 dccproc` attacks, but the bad guy need
only have a bunch of servers in the client map and include a delay in
the repeat loop to get around them for polluting the database.

> > 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.
>So you're saying that it's stupid of me to talk about what I see as a solution
> to problem A simply because if you can't remove problem B at the same time
> you'd rather leave problem A in the system too???

No, I'm saying there is only one problem and that because only a small
part of problem A can be solved, it would be following Microsoft Standard
Operating Procedure to say that problem A has been solved with a fractional
solution.  Since problem A cannot really be solved, I prefer to find a
way to live with it and see it as a desirable feature.  The Microsoft
procedure is to "fix" an egregious error such as executing programs that
arrive in mail by talking about the wonderfulness ActiveX while pretending
that authentication is authorization and ignoring the Verisign faux pas
with the certificate.  This issue is fundamentally about
security.  Security holes are either effectively plugged or not.  Forcing
bad guys to replace `dccproc -t many` with `repeat 1000 dccproc -t 1` or
`repeat 1000 sh -c 'dccproc -t 1; sleep 1'` would only whitewash the
issue.  As Microsoft has been proving continuously for the last 15
years (since DOS viruses), that doesn't work for real problems.

If the entire issue cannot be seen as a feature, then it is a fatal
flaw that requires giving up on whole idea.  It is "user friendly"
to execute whatever mail arrives, but without a fix for the security
problems, it is a stupid bug.  I hope the same does not apply to
the DCC, as well as Vipul's razor and every other cooperative
anti-spam scheme, all of which have variations of the characteristic.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.