continue not asking DCC

Contact vjs@rhyolite.com by mail or use the form. · Fri Dec 26 13:49:33 UTC 2003

Hello,

Sorry for returning to this but I'm continuing getting a lot of this:
Dec 26 08:09:07 milter dccm[41486]: continue not asking DCC 17 seconds
after failure
Dec 26 08:09:08 milter dccm[41486]: continue not asking DCC 16 seconds
after failure
Dec 26 08:09:09 milter dccm[41486]: continue not asking DCC 15 seconds
after failure

/var/dcc/map contains 3 DCC servers localhost (127.0.0.1) + 2 servers on
local Ethernet network  (100baseTX <full-duplex>). So I'm sure that we don't
have network problems here ;)
It looks that some time the current DCC server with the lowest RTT stops
responding and dccm starts "continue not asking..." complaints.
Is it possible in  this case, dccm to start asking the next available DCC
server (maybe based on the RTT) or it can be just a simple round robin.

Thanks,

Val

On Thu, 24 Jul 2003, Vernon Schryver wrote:

> > From: "Bolmerg-Berliner Ludger - Munich-MR" <lbolmerg@munichre.com>
>
> > This is a multi-part message in MIME format.
> >
> > ------_=_NextPart_001_01C351C8.4D877D8B
> > Content-Type: text/plain;
> > 	charset="iso-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> >
> > Hi
> >
> > from time to time I am seeing up to 20 or more messages within about 30 =
> > sec in my log file=20
> >
> > Jul 24 10:34:53 netserv2 dccm[72147]: continue not asking DCC 8 seconds =
> > after failure
> >
> > Does this mean dccm stopped asking the dcc servers completely?  Why =
> > would this happen?
>
> When no DCC servers answer at all, the DCC clients stop asking for a
> while.  If the problem persists, the clients backoff for exponentially
> longer periods.  In my view, passing legitimate mail is more important
> than blocking spam.  If you have a busy SMTP server, you don't want
> your spam filters to delay every incoming message for the worst case
> DCC timeout when there is evidence that even if you do delay no DCC
> server will answer.
>
> To deal with the lack of DCC server answers,
>   - check that your /var/dcc/map file contains good values
>   - check for local network problems
>
> `cdcc info` will show the current RTTs and recent responsiveness of
> the known DCC servers.  While things are broken, the usual tools
> for diagnosing network problems can be used.
>
> The current version of the DCC clients in
> http://www.dcc-servers.net/dcc/source/dcc-dccd.tar.Z
> contains improvements for dealing with network problems.
>
>
> > ...
> > ------_=_NextPart_001_01C351C8.4D877D8B
> > Content-Type: text/html;
> > 	charset="iso-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > <HTML>
> > <HEAD>
> > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> > charset=3Diso-8859-1">
> > <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> > 6.0.6396.0">
> > <TITLE>continue not asking DCC</TITLE>
> > </HEAD>
> > <BODY>
> > <!-- Converted from text/rtf format -->
> > ...
>
> It is not good to send Microsft HTML to this mailing list.  For one
> reason, see how hard it is to read in the archives, as in
> http://www.rhyolite.com/pipermail/dcc/2003/001378.html
> For another reason, HTML email is an unnecesary evil when the message
> uses no formatting.  HTML email is a major cause of worms and privacy
> vioaltions, thanks Microsoft's notions of "user friendliness" and
> "active content."
>
>
> Vernon Schryver    vjs@rhyolite.com
> _______________________________________________
> DCC mailing list      DCC@rhyolite.com
> http://www.rhyolite.com/mailman/listinfo/dcc
>
>

==
Valentin S. Chopov, CC[ND]P
Sys/Net Admin
SEI Data Inc.
E-Mail: valentin@valcho.net
==