change to DCC license

Vernon Schryver vjs@calcite.rhyolite.com
Wed Sep 19 21:13:52 UTC 2007


> From: Pavel Urban <pavel.urban@o2.com>

> >  * Permission to use, copy, modify, and distribute this software without
> >  * changes for any purpose with or without fee is hereby granted, provided 
> >  * that the above copyright notice and this permission notice appear in all 
> >  * copies and any distributed versions or copies are either unchanged
> >  * or not called anything similar to "DCC" or "Distributed Checksum 
> >  * Clearinghouse".

> That could be a problem for me. What do you mean by '(un)changed'? If it 
> excludes simple packaging, I will be unable to upgrade our servers. 
> We're using RedHat Linux as a corporate standard and we don't have 
> development tools installed on production systems. I have to at least 
> create RPM if I don't want to mess up with manually copying tar archives 
> of compiled bineries. Or to make a mess in a central RPM repository by 
> adding some weird package name instead of DCC.

How is what you are doing related to "distributed versions or copies"?
Are you making any changes when your build your RPMs and do you distribute
your RPMs, in other words send them to outside organizations?  If you
are not doing both, then I do not see how the proposed license restriction
affects you.  In the unlikely case that you are doing both, then I do
wish you would stop.  In fact, I think you are not redistributing the
DCC code but only changing with things on your own computers and that
you use your own DCC servers instead of the public DCC servers.


One of the biggest problem the public DCC servers have is with ancient
repackated versions.  Dccproc in that 2.5 year old version did not do
a good job of remembering the round trip times (RTTs) to known DCC
servers and so sends a dozen probing NOPs every time it is fired up by
SpamAssassin (or otherwise) for a mail message.  The result is that not
very busy mail systems send 100,000 to millions of NOPs per day to the
public DCC servers, and then waits for the answers.  What is worse,
those blizzards of NOPs trigger the DoS defenses in the DCC server
daemon.  The defenses first delay and eventually suppress responses for
clients that lots of packets to the public servers.  Those delays and
eventual silences make the anonymous dccproc processes retransmit their
NOPs 4 times, and so multiplies their traffic by about 50 times.

The current version of dccproc not only does a better job of remembering
RTTs but starts dccifd when dccproc has been used a bunch of time times.
As a daemon, even the original dccifd was not only more efficient than
dccproc, but does an better job of remembering RTTs than the current
dccproc.

The right thing would be for those sites to do one of:
  - notice that their mail is being delayed by up to 4 seconds by
     SpamAssassin+dccproc and that dccproc never does any good, and
     so turn off their DCC clients.

     As demonstrated by the millions of NOPs sent daily for years by
     utk.edu, despite my repeated mail to them, that doesn't work.

  - manually enable the repackaged ancient version of dccifd in the
      dcc_conf file

    That won't work by itself because the repackagers ship the DCC
    code with their notion of the proper place for a DCC home
    directory (what should be ./configure --homedir=X but is `sed`
    attacks on the source) so their own choice for the dccifd socket.
    The problem here is that among the modifications they make to
    the version of SpamAssassin they repackage is *NOT* a change
    to where SpamAssassin looks for the dccifd socket.  Unless you
    know enough about SpamAssassin to modify its DCC plugin, dccifd
    does not work even if you know enough turn it on.

  - run ...dcc/libexec/updatedcc to fetch, compile, install, and restart
       the current version of dccproc and dccifd

     That won't work because the repackaged version of the DCC source is
     built with ad hoc `sed` and other kludges instead of the ./configure
     file and so updatedcc is broken.

All of those right things are likely to be broken by the installation
of a new version from the repackagers.

The repackagers say that they cannot ship the current DCC version
because of the current license and because they have not tested it.
Never mind that they don't really test anything, or they would have
noticed the interaction with the DoS defenses of the public servers.
As for the license, the most recent reason I'm on my hobby horse involved
a request for a pointer to the specific code changes behind this change
in verison 1.3.51:
   "Close hole that allowed deleting or adding hosts in /var/dcc/maps."
Never mind that as a security issue, the hole is smaller than trivial.
Consider the propriety of objecting to the current freer than
non-commercial use license, while picking and choosing new or changed
source published with that license.

Another problem the public DCC servers have is with anti-spam appliance
vendors and others who commit theft by conversion by taking and selling
the CPU cycles, bandwidth, and human system administration efforts of
the public DCC server operators.  Would you care to guess where many
of those appliance vendors get the software that they ship on their
white boxes?

Both of those problems would be largely suppressed if not really fixed
if the repackagers would ship an empty /var/dcc/maps file or a maps file
pointing to their own DCC servers.  (Never mind that they have none).
Of course, they blow off my requests to that effect.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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