Nabble - DCC

Re: dcc 'make install' fails on Debian

2008-08-01T08:58:27Z

> From: Arno van Amersfoort <arnova@...>

> ...
> I haven't been able to figure out how I can build it WITHOUT the
> documentation stuff. Could you provide a hint on how to accomplish this?

See the NOMAN environment or `make` variable mentioned in the DCC
installation instructions in the INSTALL.html file you have or
http://www.dcc-servers.net/dcc/INSTALL.html#envtbl
or
http://www.rhyolite.com/dcc/INSTALL.html#envtbl

Or try `./configure --disable-sys-inst` mentioned in the same table.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: dcc 'make install' fails on Debian

2008-08-01T02:01:27Z

I'm puzzled. I tried all of this:
- remove /usr/local/man: FAILS
- create /usr/local/man: FAILS
- building on a cleanly installed debian/lenny x86 machine: FAILS
- building on a production debian/etch x86 machine: WORKS!

After looking at the /autoconf/install.sh script, I think it has something to do with this line which gives an empty value: doit="${DOITPROG-}"

I haven't been able to figure out how I can build it WITHOUT the documentation stuff. Could you provide a hint on how to accomplish this?

Thanks.

Arno

Vernon Schryver wrote:

From: Arno van Amersfoort arnova@...

I tried to do a "make install" (after compiling it) of the latest DCC on 
a machine running Debian/Lenny (x86). But it fails with:

+(627 /..cc-1.3.92)# make 
install                                                                                                                
(root@rocky)
for DIR in  dccm .; do\
            if test "$DIR" != .; then\
                (cd $DIR; make deinstall); fi; done
make[1]: Entering directory 
`/mnt/archive/software/linux/source/dcc-1.3.92/dccm'
rm -f /var/dcc/libexec/dccm
make[1]: Leaving directory 
`/mnt/archive/software/linux/source/dcc-1.3.92/dccm'
./autoconf/install-sh -c -d -o root -g bin -m 755 /usr/local/man/man8
mkdir: cannot create directory `/usr/local/man': File exists
mkdir: cannot create directory `/usr/local/man/man8': No such file or 
directory
make: *** [/usr/local/man/man8] Error 1

Does anyone know how to fix this or what's causing it?


My guess is that there is a file named /usr/local/man instead of nothing
or a directory.  If my guess is right, solutions include removing the
strange file or using ./configure options to not install the DCC man
pages or to install them somewhere other than in the default /usr/local/man
directory.


Vernon Schryver    vjs@...
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: dcc 'make install' fails on Debian

2008-07-31T06:39:57Z

> From: Arno van Amersfoort <arnova@...>

> I tried to do a "make install" (after compiling it) of the latest DCC on
> a machine running Debian/Lenny (x86). But it fails with:
>
> +(627 /..cc-1.3.92)# make
> install
> (root@rocky)
> for DIR in dccm .; do\
> if test "$DIR" != .; then\
> (cd $DIR; make deinstall); fi; done
> make[1]: Entering directory
> `/mnt/archive/software/linux/source/dcc-1.3.92/dccm'
> rm -f /var/dcc/libexec/dccm
> make[1]: Leaving directory
> `/mnt/archive/software/linux/source/dcc-1.3.92/dccm'
> ./autoconf/install-sh -c -d -o root -g bin -m 755 /usr/local/man/man8
> mkdir: cannot create directory `/usr/local/man': File exists
> mkdir: cannot create directory `/usr/local/man/man8': No such file or
> directory
> make: *** [/usr/local/man/man8] Error 1
>
> Does anyone know how to fix this or what's causing it?

My guess is that there is a file named /usr/local/man instead of nothing
or a directory. If my guess is right, solutions include removing the
strange file or using ./configure options to not install the DCC man
pages or to install them somewhere other than in the default /usr/local/man
directory.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

dcc 'make install' fails on Debian

2008-07-31T00:49:56Z

Hello all,

I tried to do a "make install" (after compiling it) of the latest DCC on a machine running Debian/Lenny (x86). But it fails with:

+(627 /..cc-1.3.92)# make install                                                                                                                (root@rocky)
for DIR in dccm .; do\
            if test "$DIR" != .; then\
                (cd $DIR; make deinstall); fi; done
make[1]: Entering directory `/mnt/archive/software/linux/source/dcc-1.3.92/dccm'
rm -f /var/dcc/libexec/dccm
make[1]: Leaving directory `/mnt/archive/software/linux/source/dcc-1.3.92/dccm'
./autoconf/install-sh -c -d -o root -g bin -m 755 /usr/local/man/man8
mkdir: cannot create directory `/usr/local/man': File exists
mkdir: cannot create directory `/usr/local/man/man8': No such file or directory
make: *** [/usr/local/man/man8] Error 1

Does anyone know how to fix this or what's causing it?

-- 
Ing. A.C.J. van Amersfoort (Arno)
Electronics & ICT Engineer
----------------------------------------------------------------
Leiden Institute of Physics (LION), Electronics Department (ELD)
Huygens Laboratory (Room 1007), Leiden University
Postal Address: P.O. Box 9504, 2300 RA Leiden
Visit Address : Niels Bohrweg 2, 2333 CA Leiden
The Netherlands
----------------------------------------------------------------
Phone    : +31-(0)71-527.1894
Fax      : +31-(0)71-527.5819
E-mail   : a.c.j.van.amersfoort@...
Homepage : http://rocky.eld.leidenuniv.nl

Re: nagios plugin

2008-07-18T16:42:06Z

> From: "Dan Mahoney, System Admin" <danm@...>
> To: Cameron Slye <cslye@...>
> cc: dcc@...

> DO you mean the local process, or remotely?
>
> I could probably adapt something for the first. The second is also
> doable but would require DCC installed on the nagios host unless I can get
> some basic information from vernon.

I think many people over the years have done the obvious. That is to
to use `cdcc stats`, `cdcc info`, or perhaps `cdcc rtt` with nagios and
other system monitoring schemes.
Depending on where you run the `cdcc` command and whether you use
something like `cdcc info` (and so the local /var/dcc/map file) or
`cdcc "host dcc1.example.com; id 76544; password secret; stats`
you would be checking what local DCC clients see or the health of the server.

The dcc-servers mailing list has a thread that mentions nagios plugins:
http://www.rhyolite.com/mailman/private/dcc-servers/2004/thread.html#154
That mailing list is open only to operators of DCC servers. See
http://www.rhyolite.com/mailman/listinfo/dcc-servers

See also
http://www.google.com/search?q=nagios+dcc+mail

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: nagios plugin

2008-07-18T15:26:37Z

On Fri, 18 Jul 2008, Cameron Slye wrote:

DO you mean the local process, or remotely?

I could probably adapt something for the first. The second is also
doable but would require DCC installed on the nagios host unless I can get
some basic information from vernon.

-Dan

> Has anyone wrote a nagios plugin to watch a dcc server?
>
>
> _______________________________________________
> DCC mailing list DCC@...
> http://www.rhyolite.com/mailman/listinfo/dcc
>

--

"Don't think of it as beer, think of it as a flavored motor oil."

-Jeremiah Kristal, on Guinness
3/29/05, 9:52 AM

--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------

_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

nagios plugin

2008-07-18T15:15:19Z

Has anyone wrote a nagios plugin to watch a dcc server?

_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: What to do about brief text messages with misspelling?

2008-07-09T13:16:05Z

> Except that I want the users to do the work, not me. They'll complain
> to our Help Desk, but they won't be able to whitelist their own IP
> addresses. Still, we may have to do this.

POP-before-SMTP would probably do the trick. If people complain, tell
them to check their mail before sending, if they think that's too painful,
they can always set up SMTP AUTH. I have about a thousand largely
clueless mail users and this strategy worked pretty well. After a year or
so it turned out that everyone was doing AUTH so I quietly dropped
POP-before-SMTP.

R's,
John
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: What to do about brief text messages with misspelling?

2008-07-08T17:14:12Z

> From: Gary Mills <mills@...>

> > I agree with John, but a compromise might be to whitelist those clients
> > instead of getting them to change their configurations to use some
> > form of SMTP authentication. Whitelisting might require more work on
> > the SMTP server side, but little or no work by the client.
>
> Except that I want the users to do the work, not me. They'll complain
> to our Help Desk, but they won't be able to whitelist their own IP
> addresses. Still, we may have to do this.

If users had individual /var/dcc/userdirs/local/* directories including
log sub-directories and whiteclnt files,
then you could use something like the proof-of-concept cgi scripts in the
DCC source to let users see what is being rejected and then whitelist by IP
address, envelope sender, and so forth.
There is a demonstration of those scripts at
https://www.rhyolite.com/DCC-demo-cgi-bin
with user name cgi-demo and password cgi-demo

> > There is another possibility. I've long wondered about changing the
> > DCC client code support for DNS blacklists to have two sets of blacklists.
> > Individual users can enable or disable DNSBL checks for their mail done

> That won't work here because we use a single shared whitelist, to
> which all users contribute. That's because most users don't want to
> do the tedious work of whitelisting messages; they just want the spam
> to stop. Yes, there is quite a range of users in terms of spam
> control. Some want fine control. Some want a `spam folder' where
> they can look for missing messages. Some want us to do all the work.

I think users who want extra services such as executive secretary mail
filtering such pay extra. Of course that idea is anathema in the
political environment at most academic organizations.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: What to do about brief text messages with misspelling?

2008-07-08T15:42:30Z

On Tue, Jul 08, 2008 at 04:33:40PM +0000, Vernon Schryver wrote:

> > From: "John Levine" <johnl@...>
> > To: "Gary Mills" <mills@...>
>
> > > I had a complaint the other day from one of our users who is receiving
> > > many stock pump spam messages.
>
> > > What else can we do about this spam? The sending computers are all
> > > listed on the PBL, which we don't currently use. Is this our only
> > > hope? I'm reluctant to use that blocklist because we have clients on
> > > networks that are listed there. Using it would force clients to use
> > > authentication to send e-mail, generating complaints from legitimate
> > > users. Yes, we may even have legitimate users in Peru and Viet Nam.
> >
> > I'd bite the bullet, use the PBL, and get your Asian clients to fix their
> > configurations. It's one time pain for long term benefit all around.
>
> I agree with John, but a compromise might be to whitelist those clients
> instead of getting them to change their configurations to use some
> form of SMTP authentication. Whitelisting might require more work on
> the SMTP server side, but little or no work by the client.

Except that I want the users to do the work, not me. They'll complain
to our Help Desk, but they won't be able to whitelist their own IP
addresses. Still, we may have to do this.

> If they can be whitelisted by IP address, perhaps their addresses
> should not be in the PBL. On the other hand, if their IP addresses
> should be in the PBL, then either they are violating the terms and
> conditions of their ISPs or they are likely sources of spam.

Our local ISPs have all blocked the SMTP port. To send e-mail through
our e-mail server, users have to connect to the client port. Sendmail
forces them to authenticate on that port. This automatically
whitelists their IP address. So, that should all be okay. That leaves
users at other locations that don't authenticate, a small minority, and
legitimate e-mail servers that are on PBL networks. I trust that the
latter are also small in number. Maybe this will work after all.

> There is another possibility. I've long wondered about changing the
> DCC client code support for DNS blacklists to have two sets of blacklists.
> Individual users can enable or disable DNSBL checks for their mail done
> by dccm, dccifd, or dccproc. If there were two sets with separate controls,
> you could put the PBL into the second set and let that user enable it
> for only that mailbox. Would adding that complication be worthwhile?

That won't work here because we use a single shared whitelist, to
which all users contribute. That's because most users don't want to
do the tedious work of whitelisting messages; they just want the spam
to stop. Yes, there is quite a range of users in terms of spam
control. Some want fine control. Some want a `spam folder' where
they can look for missing messages. Some want us to do all the work.
I'm hoping that our system at least satisfies the majority. Users
certainly are impressed when they look at the list of spam addressed
to them that was automatically rejected by DCC.

--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: [DCC] Re: What to do about brief text messages with misspelling?

2008-07-08T10:07:15Z

On Tue, Jul 08, 2008 at 04:33:40PM +0000, Vernon Schryver wrote:
> There is another possibility. I've long wondered about changing the
> DCC client code support for DNS blacklists to have two sets of blacklists.
> Individual users can enable or disable DNSBL checks for their mail done
> by dccm, dccifd, or dccproc. If there were two sets with separate controls,
> you could put the PBL into the second set and let that user enable it
> for only that mailbox. Would adding that complication be worthwhile?

Vernon, we've offered our users similar functionality for a long time
though our own milter filters and it makes a certain subset of users VERY
happy to be able to choose to apply RBLs to their mail flow that we
wouldn't use by default (or even recommend that anyone use.)

--
Kelsey Cummings - kgc@... sonic.net, inc.
System Architect 2260 Apollo Way
707.522.1000 Santa Rosa, CA 95407
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: What to do about brief text messages with misspelling?

2008-07-08T10:04:23Z

>> I'd bite the bullet, use the PBL, and get your Asian clients to fix their
>> configurations. It's one time pain for long term benefit all around.
>
> I agree with John, but a compromise might be to whitelist those clients
> instead of getting them to change their configurations to use some
> form of SMTP authentication.

There's also the hoary hack of POP-before-SMTP, a dynamic whitelist of
hosts that have recently authenticated for POP or IMAP. That used to be
very popular before SMTP AUTH, and you can probably still find code for
popular MTAs to do it.

R's,
John
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: What to do about brief text messages with misspelling?

2008-07-08T09:33:40Z

> From: "John Levine" <johnl@...>
> To: "Gary Mills" <mills@...>

> > I had a complaint the other day from one of our users who is receiving
> > many stock pump spam messages.

> > What else can we do about this spam? The sending computers are all
> > listed on the PBL, which we don't currently use. Is this our only
> > hope? I'm reluctant to use that blocklist because we have clients on
> > networks that are listed there. Using it would force clients to use
> > authentication to send e-mail, generating complaints from legitimate
> > users. Yes, we may even have legitimate users in Peru and Viet Nam.
>
> I'd bite the bullet, use the PBL, and get your Asian clients to fix their
> configurations. It's one time pain for long term benefit all around.

I agree with John, but a compromise might be to whitelist those clients
instead of getting them to change their configurations to use some
form of SMTP authentication. Whitelisting might require more work on
the SMTP server side, but little or no work by the client.

If they can be whitelisted by IP address, perhaps their addresses
should not be in the PBL. On the other hand, if their IP addresses
should be in the PBL, then either they are violating the terms and
conditions of their ISPs or they are likely sources of spam.

There is another possibility. I've long wondered about changing the
DCC client code support for DNS blacklists to have two sets of blacklists.
Individual users can enable or disable DNSBL checks for their mail done
by dccm, dccifd, or dccproc. If there were two sets with separate controls,
you could put the PBL into the second set and let that user enable it
for only that mailbox. Would adding that complication be worthwhile?

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: What to do about brief text messages with misspelling?

2008-07-07T20:17:53Z

> What else can we do about this spam? The sending computers are all
> listed on the PBL, which we don't currently use. Is this our only
> hope? I'm reluctant to use that blocklist because we have clients on
> networks that are listed there. Using it would force clients to use
> authentication to send e-mail, generating complaints from legitimate
> users. Yes, we may even have legitimate users in Peru and Viet Nam.

I'd bite the bullet, use the PBL, and get your Asian clients to fix their
configurations. It's one time pain for long term benefit all around.

R's,
John
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

What to do about brief text messages with misspelling?

2008-07-07T19:58:00Z

I had a complaint the other day from one of our users who is receiving
many stock pump spam messages. Here's a sample message body:

Thursday Jul 3
Loa"d up your tradingplatfo'rms

Entity': HarrsixEpl
Issue: H - X - P - N
Las't: 0.02
Before next week-end: 0.09

Read about. the strong story behind it
You may make a killing with this one and we're happy for you
Starting 03/07/08

These messages are in plain text. Because of the misspelling, DCC
registers a count of one for each of its three checksums. They come
from all over the place, Peru and Viet Nam in the samples he provided.
The computers seem to be compromised with the storm bot. All are
listed now on the XBL blocklist (CBL actually), which we use through
DCC, but must have not been listed at the time.

What else can we do about this spam? The sending computers are all
listed on the PBL, which we don't currently use. Is this our only
hope? I'm reluctant to use that blocklist because we have clients on
networks that are listed there. Using it would force clients to use
authentication to send e-mail, generating complaints from legitimate
users. Yes, we may even have legitimate users in Peru and Viet Nam.

--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: OS and architecture migration for DCC

2008-06-10T22:22:50Z

> From: Gary Mills

> So with two servers with both dccd and grey databases and floods
> between them, I should just start the upgraded server up with no
> databases. They will get initialized during startup and populated
> from the other server. Is that the correct procedure?

That is what I would do.

It would take a little while for the database to flood to the new
system. Until the database on the new system is full, fitering
effectiveness would be reduced. You could fiddle with the map files
to keep dccm from talking to the new system for a day or two.
Or just not worry about it, since after an hour or two the database
will caught up enough so that effectiveness won't be reduced my more
than 10%.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: OS and architecture migration for DCC

2008-06-10T20:07:50Z

On Tue, Jun 10, 2008 at 02:05:49AM +0000, Vernon Schryver wrote:

> > From: Gary Mills
>
> > I'm using the same version of DCC in both cases, but recompiled for
> > the Solaris 10 x86 server. On that server, I started with a DCC
> > directory (/usr/local/dcc) that was a copy of the one from Solaris 9
> > SPARC. I then reinstalled DCC so that the executables would all be
> > x86 ones. The daemons logged some interesting errors, presumably due
> > to the byte order, but eventually seemed to run normally. This was
> > for dccd:
> >
> > Jun 9 16:03:02 setup01 dccd[1198]: [ID 702911 mail.error] dcc_db has page size 16128 incompatible with 15654912 in dcc_db.hash
>
> Don't do that. Instead, copy the only the ASCII files.

Well, that was certainly cleaner. The databases are empty with an
isolated server, of course. It will be adequate for me to test dccm
with sendmail.

> > With single dccd and grey servers, is there any other way to do this
> > migration and still maintain the data in the databases?
>
> No, there is no way. Don't bother to waste time copying the database
> files among systems.

Okay, I see.

> While you have both old and new systems running, you will want both
> changes to be echoed on all systems. So you will want to get flooding
> going among the old and new systems. With flooding, just let the new
> system act as if it suffered a disk error that trashed the databases.

So with two servers with both dccd and grey databases and floods
between them, I should just start the upgraded server up with no
databases. They will get initialized during startup and populated
from the other server. Is that the correct procedure? Of course,
there are external floods as well. The client (dccm) would initially
communicate with the other server if I started it first and the
mapping file was correct.

--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: OS and architecture migration for DCC

2008-06-09T19:05:49Z

> From: Gary Mills

> but the databases are mostly empty. The migration is from Solaris 9
> to Solaris 10, from SPARC (big-endian) to x86 (little-endian), and
> from UFS to ZFS. Talk about a torture test!

If it hurts (and it will), then don't do that.

> I'm using the same version of DCC in both cases, but recompiled for
> the Solaris 10 x86 server. On that server, I started with a DCC
> directory (/usr/local/dcc) that was a copy of the one from Solaris 9
> SPARC. I then reinstalled DCC so that the executables would all be
> x86 ones. The daemons logged some interesting errors, presumably due
> to the byte order, but eventually seemed to run normally. This was
> for dccd:
>
> Jun 9 16:03:02 setup01 dccd[1198]: [ID 702911 mail.error] dcc_db has page size 16128 incompatible with 15654912 in dcc_db.hash

Don't do that. Instead, copy the only the ASCII files.

> Jun 9 16:12:06 setup01 dccm[1256]: [ID 702911 mail.notice] 1.3.86 listening to inet:3331 with /usr/local/dcc
>
> When I first ran `cdcc info', I got these errors logged:

Instead copy only the ASCII files including map.txt, dcc_conf, and
flod, and only some of those. For example, lines for your external
DCC flooding peers must not be in flod files on more than one system.

> With single dccd and grey servers, is there any other way to do this
> migration and still maintain the data in the databases?

No, there is no way. Don't bother to waste time copying the database
files among systems. Instead, let flooding rebuild the greylist and
main DCC databases on the new system from scratch as if the new
system had suffered a disk crash.

While you have both old and new systems running, you will want both
changes to be echoed on all systems. So you will want to get flooding
going among the old and new systems. With flooding, just let the new
system act as if it suffered a disk error that trashed the databases.
Disk or RAM problems are not exactly rare on new boxes, and so that
might happen even if you don't plan to start from that state.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

OS and architecture migration for DCC

2008-06-09T18:23:54Z

I'm planning an upgrade of our e-mail server, which is also one of our
dccd and grey servers. I'm doing this first on a test e-mail server
that has only isolated dccd and grey servers. It gets a bit of spam,
but the databases are mostly empty. The migration is from Solaris 9
to Solaris 10, from SPARC (big-endian) to x86 (little-endian), and
from UFS to ZFS. Talk about a torture test! I only expect the byte
order to be a problem.

I'm using the same version of DCC in both cases, but recompiled for
the Solaris 10 x86 server. On that server, I started with a DCC
directory (/usr/local/dcc) that was a copy of the one from Solaris 9
SPARC. I then reinstalled DCC so that the executables would all be
x86 ones. The daemons logged some interesting errors, presumably due
to the byte order, but eventually seemed to run normally. This was
for dccd:

Jun 9 16:03:02 setup01 dccd[1198]: [ID 702911 mail.error] dcc_db has page size 16128 incompatible with 15654912 in dcc_db.hash
Jun 9 16:03:02 setup01 dccd[1198]: [ID 702911 mail.error] dcc_db says it contains 1158682945536393216 bytes or more than the actual size of 8257536
Jun 9 16:03:02 setup01 dccd[1199]: [ID 702911 mail.notice] database initially broken; starting `/usr/local/dcc/libexec/dbclean -Pq4SRbad -i 9003`
Jun 9 16:03:02 setup01 dbclean[1199]: [ID 839192 mail.notice] 1.3.86 repairing /usr/local/dcc/dcc_db
Jun 9 16:03:02 setup01 dbclean[1199]: [ID 702911 mail.error] explicit repair of dcc_db
Jun 9 16:03:02 setup01 dbclean[1199]: [ID 702911 mail.error] unexpected EOF in dcc_db at 0x7e0000 instead of 0x1014780000000000
Jun 9 16:03:02 setup01 dbclean[1199]: [ID 394617 mail.notice] expired 19 records and 17 checksums, obsoleted 63 checksums in dcc_db
Jun 9 16:03:02 setup01 dbclean[1199]: [ID 582593 mail.notice] hashed 262205 records containing 393286 checksums, compressed 25 records
Jun 9 16:03:03 setup01 dbclean[1199]: [ID 838263 mail.notice] 6709240 hash entries total, 131619 or 1% used
Jun 9 16:03:03 setup01 dccd[1198]: [ID 702911 mail.notice] unrecognized hash_len=33554432 in /usr/local/dcc/dccd_clients
Jun 9 16:03:03 setup01 dccd[1198]: [ID 702911 mail.notice] 1.3.86 listening to port 6277 /usr/local/dcc window=1911MB real=33,553,660KB max RSS=1920MB DB max=2400MB

This was for grey:

Jun 9 16:08:38 setup01 dccd grey[1230]: [ID 702911 mail.error] grey_db is not a greylist database but must be
Jun 9 16:08:38 setup01 dccd grey[1232]: [ID 702911 mail.notice] database initially broken; starting `/usr/local/dcc/libexec/dbclean -Pq4SRbad -Gon -i 9003 -Gon`
Jun 9 16:08:38 setup01 dbclean grey[1232]: [ID 839192 mail.notice] 1.3.86 repairing /usr/local/dcc/grey_db
Jun 9 16:08:38 setup01 dbclean grey[1232]: [ID 702911 mail.error] explicit repair of grey_db
Jun 9 16:08:38 setup01 dbclean grey[1232]: [ID 702911 mail.error] unexpected EOF in grey_db at 0x888000 instead of 0x60217b0000000000
Jun 9 16:08:38 setup01 dbclean grey[1232]: [ID 304167 mail.notice] expired 4 records and 10 checksums in grey_db
Jun 9 16:08:38 setup01 dbclean grey[1232]: [ID 582593 mail.notice] hashed 268691 records containing 403101 checksums, compressed 0 records
Jun 9 16:08:38 setup01 dbclean grey[1232]: [ID 838263 mail.notice] 638968 hash entries total, 135365 or 21% used
Jun 9 16:08:39 setup01 dccd grey[1230]: [ID 702911 mail.notice] unrecognized hash_len=33554432 in /usr/local/dcc/grey_clients
Jun 9 16:08:39 setup01 dccd grey[1230]: [ID 702911 mail.notice] 1.3.86 listening to port 6276 /usr/local/dcc window=273MB real=33,553,660KB max RSS=1920MB DB max=2400MB

dccm was much better behaved:

Jun 9 16:12:06 setup01 dccm[1256]: [ID 702911 mail.notice] 1.3.86 listening to inet:3331 with /usr/local/dcc

When I first ran `cdcc info', I got these errors logged:

Jun 9 16:13:19 setup01 dccd[1198]: [ID 702911 mail.notice] bad client or server-ID 25165824 from 130.179.16.64,33473 for NOP
Jun 9 16:13:19 setup01 dccd grey[1230]: [ID 702911 mail.notice] bad client or server-ID 25165824 from 130.179.16.64,33473 for NOP

I fixed that by removing the `map' file and reloading it from `map.txt'.
After that, `cdcc info' ran normally.

With single dccd and grey servers, is there any other way to do this
migration and still maintain the data in the databases? Is there a
way to check their consistency, or has this already been done in the
startup? On the production e-mail server, where there are also dccd and
grey servers running on another machine, is there a better way to use
those to rebuild the database? I'm assuming that the network protocol
between DCC clients and servers is independant of byte order, so it's
only the on-disk databases that might have problems.

--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: Should dccproc always start dccifd?

2008-06-09T18:21:06Z

> From: Gary Mills

> We run dccd along with the dccm sendmail milter. We also use dccproc
> as a sendmail alias to report spam and feed it into an auto-reporter.
> I noticed today that dccproc had started dccifd, even though we don't
> use dccifd. The man page does state that this will happen, for the
> benefit of SpamAssassin. We don't use that product either.
>
> Here are the relevant sendmail log entries:
>
> May 28 17:08:58 electra dccproc[5556]: [ID 702911 mail.notice] try to start dccifd
> May 28 17:08:58 electra sm-mta[5551]: [ID 801593 mail.info] m4SM8u6o005506: to=|"/usr/local/bin/dccproc -R -t many | /usr/local/sbin/report-spam bin@...", ctladdr=<bin@...> (1/0), delay=00:00:02, xdelay=00:00:00, mailer=prog, pri=35253, dsn=2.0.0, stat=Sent
>
> I assume this is harmless, but it raises a couple of questions. Can
> this be prevented?

I hope it is too harmless to worry about.
Deleting the dccifd program or not running dccproc so will stop dccifd
from running.
However, if you are running dccproc often enough to trigger the
attempt to start dccifd, you might be better served by using dccifd.

> Is there a more efficient way to handle these
> spamtrap aliases?

Using dccif-test to send spam to dccifd might be better than using
dccproc. It would certainly avoid the floods of DCC server health
probing NOPs that waste cycles and bandwidth at the public DCC servers
and why I made dccproc start dccifd.

With sendmail+dccm there are better ways. One is using
/etc/mail/virtusertable to map spam traps to a mailbox with a
per-user whiteclnt file that declares everything spam. That mapping
can result in a dccm log file envelope Rcpt_To line like this:

env_To: <welcome@...> addr=catchall dir=userdirs/local/catchall

If /var/dcc/local/usedirs/local/catchall/whiteclnt contains a line like

option threshold all,0

then all mail to that mailbox is reported to the DCC server with
counts of "MANY" and rejected.

I've switched from that style of spam trap to a new scheme. It involves
a new option line that reports all mail to the DCC server with counts
of "MANY" but delivers the mail regardless, as dccm or dccifd were
running with -aIGNORE. I then use a line like
catchall: /dev/null
to discard the spam. (Of course that could be a mailbox, real file,
or program.) The advantage is that mail to spam traps is not rejected,
which might keep spammers from removing traps from their target lists.

I'm not yet ready to document (or name in public) that new option line,
because it might change.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Should dccproc always start dccifd?

2008-06-09T17:12:42Z

We run dccd along with the dccm sendmail milter. We also use dccproc
as a sendmail alias to report spam and feed it into an auto-reporter.
I noticed today that dccproc had started dccifd, even though we don't
use dccifd. The man page does state that this will happen, for the
benefit of SpamAssassin. We don't use that product either.

Here are the relevant sendmail log entries:

May 28 17:08:58 electra dccproc[5556]: [ID 702911 mail.notice] try to start dccifd
May 28 17:08:58 electra sm-mta[5551]: [ID 801593 mail.info] m4SM8u6o005506: to=|"/usr/local/bin/dccproc -R -t many | /usr/local/sbin/report-spam bin@...", ctladdr=<bin@...> (1/0), delay=00:00:02, xdelay=00:00:00, mailer=prog, pri=35253, dsn=2.0.0, stat=Sent

I assume this is harmless, but it raises a couple of questions. Can
this be prevented? Is there a more efficient way to handle these
spamtrap aliases?

--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

DCC version 1.3.92/2.3.92 released

2008-06-09T09:58:55Z

Version 1.3.92 of the DCC source is in
http://www.dcc-servers.net/dcc/source/dcc.tar.Z and
http://www.rhyolite.com/anti-spam/dcc/source/dcc.tar.Z

Commercial version 2.3.92 of the DCC Reputation code is in the usual place.

The CHANGES file starts with
Improve the hash function used in the DCC server database.
Replace -Bno-envelope for dccm, dccproc, and dccifd with
-Bno-client and -Bno-mail_host for Tony Del Porto. It seems that
Spamhaus' PBL should generally not be applied to SMTP envelope
Mail_From domain names to avoid rejecting mail received through an
ISP smart-host but with sender domain name hosted on a dynamically
assigned IP address. The now undocumented -Bno-envelope implies
-Bno-client and -Bno-mail_host.
Fix the @configsuffix@ mechanism in homedir/Makefile.in as suggested
by Craig Green.
Switch to -lpthread threads on FreeBSD starting with 6.2 because of
recent problems with libc_r threads.
Dccproc should not require a "option DNSBL-on" line in /var/dcc/whiteclnt
to pay attention to DNSBL hits. The -B settings on the dccproc
command line are sufficient to show that the user wants DNSBL checking.
Fix bug in compression of DCC Reputation reports.

/var/dcc/libexec/updatedcc should automagically fetch, build, and
install the commercial or free version, depending on the .updatedcc_pfile
file, unless you have installed a version of Linux with the broken
default `sort` collating sequence since last upgrading. If so, an
easy way to get the old updatedcc script working is to delete the
entire /var/dcc/build/dcc directory before running updatedcc.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

DCC version 1.3.91/2.3.91 released

2008-05-21T06:25:27Z

Version 1.3.91 of the DCC source is in
http://www.dcc-servers.net/dcc/source/dcc.tar.Z and
http://www.rhyolite.com/anti-spam/dcc/source/dcc.tar.Z

Commercial version 2.3.91 of the DCC Reputation code is in the usual place.

The CHANGES file starts with
Fix mechanism that should prevent dccd from starting dbclean for a quick
cleaning about the time the cron job runs.
Let DNSBL target addresses be CIDR blocks to improve the use of Spamhaus'
lists.
Fix DNSBL bug that caused false positives reported by Ray Gardener.
Tweak homedire/Makefile.in for the gento folks.
Fix recent compiling bug with Borland on WIN32 reported by Tommy Barberis.

/var/dcc/libexec/updatedcc should automagically fetch, build, and
install the commercial or free version, depending on the .updatedcc_pfile
file, unless you have installed a version of Linux with the broken
default `sort` collating sequence since last upgrading. If so, an
easy way to get the old updatedcc script working is to delete the
entire /var/dcc/build/dcc directory before running updatedcc.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: logger breaks rhel5 boot

2008-05-09T06:34:37Z

> From: "Mihai Vintila" <mihaiv@...>

> Logger from dcc installs itself in /usr/sbin

On the contrary, nothing in the DCC tarball is installed in /usr/sbin
with the default ./configure parameters.
There is a file named logger in the misc directory of the DCC source,
but it is installed with the Makefile parameter $(DCC_BINDIR) along
with the other DCC specific programs that need not and so should not
be in any directory in the PATH environment variable (or $path for csh,
tcsh, etc.) for any user, including the DCC `./configure --with-uid=UID`
user.

If the DCC misc/logger file is being installed in /usr/sbin, it is only
because of a surprising and evidently unwise choice for
`./configure --libexecdir=DIR` or perhaps `./configure --homedir=HOMEDIR`

Note that have long been working, presumably rebooting installations
of the DCC code on CentOS includint at least versions 4.2,, 4.3, and 5.
Besides references in this mailing list, see some of the hits for
http://www.google.com/search?q=centos+dcc+configure

> this breaks redhat/centos =
> boot since logger from dcc does not support -i parameter=20
> Affected line : /etc/sysconfig/network-scripts/network-functions: =
> logger -p local7.notice -t "NET" -i "$0 : updated /etc/resolv.conf";
>
>
> Logger script should support all parameters even if it does nothing with =
> them
> usage: logger [-is] [-f file] [-p pri] [-t tag] [-u socket] [ message =
> ... ]

While `logger -i` is common among `logger` programs on UNIX-like systems,
it is impossible for anything in the DCC tarball to be an upward
compatible replacement for all varients of any program commonly found
in UNIX varients. There is just too much variation. The DCC logger
script exists only because of just such variations in the common logger
program.

The DCC logger script is only a wrapper for the local logger program
used when the local program lacks `logger -s`. Not only would it be
too ugly to force other applications to run the DCC logger script that
would then run the real logger program, the DCC logger script does the
wrong thing for applications that do not want their messages sent to
stderr.

One might argue that the DCC logger script should be named something
like dcc-logger, but that is unnecessary. It is better to install
the DCC internal programs in their own directory where they cannot
bother other applications.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

logger breaks rhel5 boot

2008-05-09T02:12:35Z

Logger from dcc installs itself in /usr/sbin this breaks redhat/centos boot since logger from dcc does not support -i parameter
Affected line : /etc/sysconfig/network-scripts/network-functions: logger -p local7.notice -t "NET" -i "$0 : updated /etc/resolv.conf";

Logger script should support all parameters even if it does nothing with them
usage: logger [-is] [-f file] [-p pri] [-t tag] [-u socket] [ message ... ]

_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC on Centos 4.6 Accepting All mail if I understand correctly

2008-04-25T08:31:22Z

> From: "Becskei Robert"

> I've just installed DCC on my server configured it,

Judging from the log file, I suspect that you are not running the
current version of dccifd. The current version is 1.3.90. You
can determine the version you are using with `cdcc -V` or `dccifd -V`

If you are not using the current version, it would be good to install.
it. Unless you obtained the source from a third party that broke the
shell script /var/dcc/libexec/updatedcc, running that script should
fetch, configure, compile, install, and restart dccifd.

> and in /var/dcc/log I
> see the following :
>
> If I understand correctly this message is accepted for delivery instead of
> being dropped cause it's obviously spam, why ?

> X-DCC-URT-Metrics: mail.topolauniverzal.co.yu 1060; Body=many Fuz1=many
> Fuz2=many
> reported: 1 checksum server
> IP: 45c16e81 5be2cac6 65a639fb 29b6354c

> Body: f119c4f7 f53c166d e3bfea0a e2db03bb many
> Fuz1: c540dacf ff893152 90304931 3513dc3a many
> Fuz2: 558ce5e6 847ee1c9 5558444f eb6e6318 many
> substitute mail_host: e1f59373 d85df116 8b9fd3e0 54c524d3
>
> result: accept

What is the value of DCCIFD_REJECT_AT (or DCCM_REJECT_AT) in
/var/dcc/dcc_conf? The absense of a "threshold" column in the
checksum results in that log file suggest that DCCIFD_REJECT_AT is
not set. To reject mail with body checksums of "MANY", try setting
DCCIFD_REJECT_AT=MANY I use a far smaller value, but I also use
per-user whitelists.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

DCC on Centos 4.6 Accepting All mail if I understand correctly

2008-04-25T04:56:01Z

Dear list,

I've just installed DCC on my server configured it, and in /var/dcc/log I
see the following :

If I understand correctly this message is accepted for delivery instead of
being dropped cause it's obviously spam, why ?

Sincerely
Robert

cat msg.2jjrdm
VERSION: 3
DATE: 04/25/08 13:54:45 CEST
IP: adsl-dyn13.78-99-92.t-com.sk ::ffff:78.99.92.13
HELO: adsl-dyn13.78-99-92.t-com.sk
env_From: vlakshmanan@... mail_host=bobbarker.com
env_To: unknown addr=unknown dir=userdirs/unknown

Return-Path: <vlakshmanan@...>
X-Envelope-To: <magacinspy@...>
Received: from adsl-dyn13.78-99-92.t-com.sk (adsl-dyn13.78-99-92.t-com.sk
[78.99.92.13])
by mail.topolauniverzal.co.yu (Postfix) with SMTP id 76C6182BE4
for <magacinspy@...>; Fri, 25 Apr 2008 13:54:44 +0200
(CEST)
Received: (qmail 25505 invoked from network); Fri, 25 Apr 2008
04:54:19 -0700
Received: from unknown (HELO wsg) (98.208.175.202)
by adsl-dyn13.78-99-92.t-com.sk with SMTP; Fri, 25 Apr 2008
04:54:19 -0700
Message-ID: <002501c8a6cb$1817e450$caafd062@wsg>
From: "Ed Day" <vlakshmanan@...>
To: <magacinspy@...>
Subject: No need to spend hours searching chemist's around!
Date: Fri, 25 Apr 2008 04:54:19 -0700
MIME-Version: 1.0
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Enjoy easy and convenient PE enlargement! http://enoughfraction.com

Ed Day

### end of message body ########################
dccifd global

X-DCC-URT-Metrics: mail.topolauniverzal.co.yu 1060; Body=many Fuz1=many
Fuz2=many
reported: 1 checksum server
IP: 45c16e81 5be2cac6 65a639fb 29b6354c
env_From: 8191f964 2d02e61a bb8c80ba cfc0fb92
From: c451ffa7 6668142a ea092ab1 8937cd1c
substitute helo: 3fc71480 3a7bc0be 39a1b9dd 6dba9f99
Message-ID: cdb34515 afcc9399 5d110b29 6ab6ae07
Received: b26bca05 6087094e 909df9a2 490feafc
Body: f119c4f7 f53c166d e3bfea0a e2db03bb many
Fuz1: c540dacf ff893152 90304931 3513dc3a many
Fuz2: 558ce5e6 847ee1c9 5558444f eb6e6318 many
substitute mail_host: e1f59373 d85df116 8b9fd3e0 54c524d3

result: accept

_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: Fuz2 false positive

2008-04-22T07:41:05Z

> From: Jeff Mincy <mincy@...>

> SpamAssassin translates body/fuz1/fuz2 values of "many" to 999999 and
> then compares the translated body/fuz1/fuz2 values to
> dcc_body_max/dcc_fuz1_max/dcc_fuz2_max which default to 999999. So,
> by default the DCC_CHECK test hits if at least one of the
> body/fuz1/fuz2 values is "many".
>
> SpamAssassin will short-circuit if there is a X-DCC header with
> "bulk". Otherwise, SpamAssassin uses either dccproc or dccifd to get
> the dcc response. If there is a X-DCC header with "bulk" then
> the DCC_CHECK hits and the body/fuz1/fuz2 counts are ignored.
> When SpamAssassin explicitly calls dccproc or dccifd then the "bulk"
> string is ignored. SpamAssassin should presumably notice the "bulk"
> string when calling dccproc or dccifd.
>
> Anyway, you seem to object to SpamAssassin doing s/many/999999/
> The many/999999 thing doesn't cause any problems does it?

SpamAssassin's many/999999 thing dates from before dccproc had -c to
set per-checksum thresholds as well as before dccifd existed, and not
to mention before per-checksum thresholds could be into per-user whiteclnt
files.

Setting SpamAssassin's own threshold for FUZ2 as was suggested would
not have the desired effect of ignoring FUZ2 results because the real
value of "many" is larger than 999999. Some people run (or once ran)
spam traps that reported bad mail with large counts insteadd of "many".
That could result in a dccifd or dccproc header with a FUZ2 result
larger than 1000000 like "X-DCC...FUZ2=1234567..." that would not be
ignored by setting the SpamAassassin threshold to 1000000.

What should be done by someone with the keys to SpamAssassin's DCC
plugin is to
- have SpamAssassin pass its thresholds as -c args to dccproc
- use the rejection status it gets from dccifd instead of the
X-DCC header
- if SpamAssassin must use the X-DCC header from dccifd, then always
and only look for the string "bulk" in the header
- try harder to find the dccifd socket and to use dccifd instead of dccproc
and check that the SpamAssassin thresholds are in the dcc_conf file.
- make SpamAssassin always and only look for the string "bulk" in
the X-DCC header it gets from dccproc, at the tiny sites using
dccproc

Then someone who wanted to ignore the FUZ2 result but not the BODY
or FUZ1 results could set the FUZ2 threshold to "never" and get
that very unlikely result.

Instead of turning off only one of the DCC results, it would make far
more sense to adjust the score that SpamAssassin gives a DCC hit.
If you think you have FUZ2 false positives, then you surely think you
have FUZ1 and BODY false positives.

Of course, I still think the right answer is not scoring DCC hits
but per-site and per-user whitelists for solicited bulk email and
rejections of unsolicited bulk email.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: Fuz2 false positive

2008-04-22T06:37:09Z

From: Vernon Schryver <vjs@...>
Date: Sat, 19 Apr 2008 02:26:53 GMT

> From: "Paul R. Ganci" <ganci@...>

> dcc_fuz2_max NUMBER
> **
> This option sets how often a message's body/fuz1/fuz2 checksum must
> have been reported to the DCC server before SpamAssassin will
> consider the DCC check as matched.
>
> As nearly all DCC clients are auto-reporting these checksums, you
> should set this to a relatively high value, e.g. |999999| (this is
> DCC's MANY count).
>
> The default is |999999| for all these options.
>
> Since DCC's many count is 999999 then setting this to 1000000 (or
> higher) should in principle disable the fuz2 check in spamassassin since
> spamassassin should never get a count higher.

The internal numeric equivalent of the DCC checksum value "MANY" is
*not* 999999. 999999 is merely the number to which SpamAssassin
translates the string "MANY". The true internal value is almost 17
times larger than 999999. I'll not say what the value is to forestall
other ill advised translations of "many." "Many" is simply the largest
possible value of a DCC checksum count. Think of it as like a mathematical
projective infinity or like IEEE 754 floating point +infinity.

To turn off the FUZ2 checksum, try teaching SpamAssassin to look for
the string "bulk" in the X-DCC header instead of any particular number.
(SpamAssassin may already look for "bulk" in X-DCC headers; I've forgotten
and don't feel like looking at the SpamAssassin source yet again.)
...
Vernon Schryver vjs@...

Ooops - hit send too soon.

SpamAssassin translates body/fuz1/fuz2 values of "many" to 999999 and
then compares the translated body/fuz1/fuz2 values to
dcc_body_max/dcc_fuz1_max/dcc_fuz2_max which default to 999999. So,
by default the DCC_CHECK test hits if at least one of the
body/fuz1/fuz2 values is "many".

SpamAssassin will short-circuit if there is a X-DCC header with
"bulk". Otherwise, SpamAssassin uses either dccproc or dccifd to get
the dcc response. If there is a X-DCC header with "bulk" then
the DCC_CHECK hits and the body/fuz1/fuz2 counts are ignored.
When SpamAssassin explicitly calls dccproc or dccifd then the "bulk"
string is ignored. SpamAssassin should presumably notice the "bulk"
string when calling dccproc or dccifd.

Anyway, you seem to object to SpamAssassin doing s/many/999999/
The many/999999 thing doesn't cause any problems does it?

-jeff
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: Fuz2 false positive

2008-04-22T06:19:42Z

From: Vernon Schryver <vjs@...>
Date: Sat, 19 Apr 2008 02:26:53 GMT

> From: "Paul R. Ganci" <ganci@...>

> dcc_fuz2_max NUMBER
> **
> This option sets how often a message's body/fuz1/fuz2 checksum must
> have been reported to the DCC server before SpamAssassin will
> consider the DCC check as matched.
>
> As nearly all DCC clients are auto-reporting these checksums, you
> should set this to a relatively high value, e.g. |999999| (this is
> DCC's MANY count).
>
> The default is |999999| for all these options.
>
> Since DCC's many count is 999999 then setting this to 1000000 (or
> higher) should in principle disable the fuz2 check in spamassassin since
> spamassassin should never get a count higher.

The internal numeric equivalent of the DCC checksum value "MANY" is
*not* 999999. 999999 is merely the number to which SpamAssassin
translates the string "MANY". The true internal value is almost 17
times larger than 999999. I'll not say what the value is to forestall
other ill advised translations of "many." "Many" is simply the largest
possible value of a DCC checksum count. Think of it as like a mathematical
projective infinity or like IEEE 754 floating point +infinity.

To turn off the FUZ2 checksum, try teaching SpamAssassin to look for
the string "bulk" in the X-DCC header instead of any particular number.
(SpamAssassin may already look for "bulk" in X-DCC headers; I've forgotten
and don't feel like looking at the SpamAssassin source yet again.)
...
Vernon Schryver vjs@...

SpamAssassin translates body/fuz1/fuz2 values of "many" to 999999 and
then compares the translated body/fuz1/fuz2 values to
dcc_body_max/dcc_fuz1_max/dcc_fuz2_max which default to 999999. So,
by default the DCC_CHECK test hits if at least one of the
body/fuz1/fuz2 values is "many".

SpamAssassin will short-circuit if there is a X-DCC header with
"bulk". Otherwise, SpamAssassin uses either dccproc or dccifd to get
the dcc response.
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC digest, Vol 1 #1007 - 1 msg

2008-04-22T06:13:30Z

Vernon Schryver wrote:

>> From: William Taylor <williamt@...>
>>
>
>
>> I am having the same sort of problem. dcc just stops working all of a
>> sudden. Can't figure out why
>>
>> r 21 21:18:26 lds dccifd[9887]: continue not asking DCC 3 seconds after
>> failure
>>
>
> What is it that stops working, the shell script updatedcc or the
> daemon dccifd's access to the public DCC servers?
>
>
>
>> I manually upgrade to the latest version and that didn't help. I did a
>> tcpdump from my local machine and from one of the public mirrors I have
>> access to and I see traffic getting there and back. Just things aren't
>> working.
>> Any ideas?
>>
>
> There are two common causes for not getting DCC results:
>
> 1. a firewall that blocks responses sent by the servers from their
> UPD port 627 to the DCC client (e.g. dccifd).
>
> 2. triggering the DoS defenses of the public DCC servers by sending
> too many requests, most often because of the use of the 3+ year
> old version of the client code redistributed by Linux repackagers.
>
> You can check to see whether your DCC client code can hear the public
> servers with `cdcc info`. If they can't, there will be complaints about
> "not answering" for all of the dozen servers that your client is trying
> to use.
>
>
> Judging from counts on three of the servers, a client at 206.81.96.54
> is sending a few requests and NOPs typical of small tests.
>
> 206.81.97.109 is also currently (April 22, 06:30 UTC) making a few tests.
>
> A client at 206.81.96.33 has sent somewhat more than 2000 requests and
> perhaps 1000 NOPs. It is using version #8 of the DCC client-server
> protocol, which implies that it is not use ancient version. Its last
> request was at 02:08:40, and since then has probably sent only NOPs.
> My guess is that a firewall of some sort has been blocking responses
> from UDP port 6277 from at least 64.124.52.0/24 and 209.169.14.0/24 to
> dccifd at 206.81.96.33 from about 02:10 UTC.
>
>
> Vernon Schryver vjs@...
> _______________________________________________
> DCC mailing list DCC@...
> http://www.rhyolite.com/mailman/listinfo/dcc
>
>

Last night I was guessing that I was sending to my requests out from
206.81.96.33 and things were getting autoblocked.
I installed a temp server at 206.81.96.54 which seemed to make the dcc
client happy again. I also added rules this morning
for the firewall stuff on .33. 206.81.97.109 is a colo customer running
their own mailserver.
BTW I ordered the new server for the mirror yesterday so that should be
here soon.
Do I need to have an official server-id for 206.81.96.54?

Thanks,
William

_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC digest, Vol 1 #1007 - 1 msg

2008-04-21T23:39:53Z

> From: William Taylor <williamt@...>

> I am having the same sort of problem. dcc just stops working all of a
> sudden. Can't figure out why
>
> r 21 21:18:26 lds dccifd[9887]: continue not asking DCC 3 seconds after
> failure

What is it that stops working, the shell script updatedcc or the
daemon dccifd's access to the public DCC servers?

> I manually upgrade to the latest version and that didn't help. I did a
> tcpdump from my local machine and from one of the public mirrors I have
> access to and I see traffic getting there and back. Just things aren't
> working.
> Any ideas?

There are two common causes for not getting DCC results:

1. a firewall that blocks responses sent by the servers from their
UPD port 627 to the DCC client (e.g. dccifd).

2. triggering the DoS defenses of the public DCC servers by sending
too many requests, most often because of the use of the 3+ year
old version of the client code redistributed by Linux repackagers.

You can check to see whether your DCC client code can hear the public
servers with `cdcc info`. If they can't, there will be complaints about
"not answering" for all of the dozen servers that your client is trying
to use.

Judging from counts on three of the servers, a client at 206.81.96.54
is sending a few requests and NOPs typical of small tests.

206.81.97.109 is also currently (April 22, 06:30 UTC) making a few tests.

A client at 206.81.96.33 has sent somewhat more than 2000 requests and
perhaps 1000 NOPs. It is using version #8 of the DCC client-server
protocol, which implies that it is not use ancient version. Its last
request was at 02:08:40, and since then has probably sent only NOPs.
My guess is that a firewall of some sort has been blocking responses
from UDP port 6277 from at least 64.124.52.0/24 and 209.169.14.0/24 to
dccifd at 206.81.96.33 from about 02:10 UTC.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC digest, Vol 1 #1007 - 1 msg

2008-04-21T21:21:41Z

Vernon Schryver wrote:

>> From: PeakPeak Customer Service <support@...>
>>
>
>
>> I'm getting this after a few seconds:
>>
>> # /var/dcc/libexec/updatedcc
>> stopping; please wait
>> #
>>
>> Just quits.
>>
>
> I've released version 1.3.90 which I hope fixes that problem.
>
> Updatedcc failed after shutting down the localhost DCC server and
> finding no working server and when the environment variable
> DCC_UPDATEDCC_FAST is not set to "yes". The easiest work-around
> is to add the public DCC servers to the local /var/dcc/map file
> with `cdcc "add dcc1.dcc-servers.net RTT+1000 ms"` Besides working
> around the updatedcc problem, that uses the public DCC servers
> as backups for the local server.
>
>
> Vernon Schryver vjs@...
> _______________________________________________
> DCC mailing list DCC@...
> http://www.rhyolite.com/mailman/listinfo/dcc
>
>

I am having the same sort of problem. dcc just stops working all of a
sudden. Can't figure out why

r 21 21:18:26 lds dccifd[9887]: continue not asking DCC 3 seconds after
failure
Apr 21 21:18:27 lds dccifd[9887]: continue not asking DCC 2 seconds
after failure
Apr 21 21:18:27 lds dccifd[9887]: continue not asking DCC 2 seconds
after failure
Apr 21 21:18:27 lds dccifd[9887]: continue not asking DCC 2 seconds
after failure
Apr 21 21:18:29 lds dccifd[9887]: no working DCC
serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net
... at 194.228.41.73 192.135.10.19
Apr 21 21:18:29 lds dccifd[9887]: no working DCC
serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net
... at 194.228.41.73 192.135.10.19
Apr 21 21:18:29 lds dccifd[9887]: no working DCC
serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net
... at 194.228.41.73 192.135.10.19
Apr 21 21:18:29 lds dccifd[9887]: no working DCC
serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net
... at 194.228.41.73 192.135.10.19

[root@lds dcc]# cdcc stats
no working DCC serversdcc1.dcc-servers.net dcc2.dcc-servers.net
dcc3.dcc-servers.net ... at 194.228.41.73 192.135.10.19
?

I manually upgrade to the latest version and that didn't help. I did a
tcpdump from my local machine and from one of the public mirrors I have
access to and I see traffic getting there and back. Just things aren't
working.
Any ideas?

Thanks,
William

_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC digest, Vol 1 #1007 - 1 msg

2008-04-21T16:44:50Z

> From: PeakPeak Customer Service <support@...>

> I'm getting this after a few seconds:
>
> # /var/dcc/libexec/updatedcc
> stopping; please wait
> #
>
> Just quits.

I've released version 1.3.90 which I hope fixes that problem.

Updatedcc failed after shutting down the localhost DCC server and
finding no working server and when the environment variable
DCC_UPDATEDCC_FAST is not set to "yes". The easiest work-around
is to add the public DCC servers to the local /var/dcc/map file
with `cdcc "add dcc1.dcc-servers.net RTT+1000 ms"` Besides working
around the updatedcc problem, that uses the public DCC servers
as backups for the local server.

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC digest, Vol 1 #1007 - 1 msg

2008-04-21T14:15:31Z

> From: PeakPeak Customer Service <support@...>

> I'm getting this after a few seconds:
>
> # /var/dcc/libexec/updatedcc
> stopping; please wait
> #
>
> Just quits.

Are there any clues from debugging, which can be turned on with
/var/dcc/libexec/updatedcc -x

Vernon Schryver vjs@...
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc