sendto( (,6277)): Socket is already connected

Vernon Schryver
Fri May 13 21:07:53 UTC 2005

> From: "Dan Mahoney, System Admin" <>

Where did you find a version of dccproc as old as 1.1.32?  The checksum
algoritms have changed in the more than two years since I released
1.1.32, which makes such ancient versions far less effective.  It would
be good to know who is doing no one a favor by distributing such an
ancient version.  What if the code were written the standards of the
Redmond School of Software Design and so had a zillion major major
security pataches since March, 2003?

> > I've seen mesages like that when the dcc home directory, usually /var/dcc,
> > isn't writable by the dcc user.  Old versions of the install script would
> > often chown it to root by mistake.  Chown it to dcc and see if the problem
> > goes away.
> DCC would likely run as the user running spamassassin.

Dccproc has always been built setUID by the Makefiles I distribute.


What is the point with the reference to that web page?  It seems not
entirely accurate.  For example, I've always or at least for the last
several years said the threshold for a local DCC server is not "upwards
of tens of thousands of messages a day," but 100,000 messages/day. 
I resist assigning server-IDs to smaller sites because they would use
less bandwidth by using the public servers, and because they tend to
have trouble keeping systems running 24x7.  On the other hand, DCC
clients handling more than 100K msgs/day tend to hit the DoS defenses
of the public DCC servers.

For another example, that page points to
which to have problems:

    DCC support
	To install DCC:

	cd $HOME/src
	tar xfvz dcc-dccproc.tar.Z
	cd dcc-dccproc-*
	./configure --disable-sys-inst  --disable-server --disable-dccm \
	--disable-dccifd  --homedir=$HOME/dir  --bindir=$HOME/bin
	make && make install

   wget is not universally available.  That's why scripts such
      as /var/dcc/libexec/updatedcc use ./configure to choose among
      wget, fetch, curl, and ftp.

   In my experience `pax -zrf` is more likely to be available than
      `tar xfwz` but portability urges simple `tar -f`

   dcc-dccproc.tar.Z is an obsolete name for the tarball.  I never
     liked it.  I made it only to comply with a request from MAPS 
     more than five years ago.

   When the dccproc tarball was still distinct, --disable-server was
     useless.  Today --disable-server still does nothing worthwhile.
     dccd is not started unless you start it.

   Ditto --disable-dccm

   --disable-dccifd seems wrong except for small sites that don't mind
     the cost of a fork()/exec() of dccproc for every incoming mail 

   --bindir=$HOME/bin is a matter of taste.  Many people prefer to put
     odd local stuff into /usr/local or similar local directories

   `make && make` install seems like a verbose way to say `make install`

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.