Nabble - DCC

DCC version 1.3.116/2.3.116 released

2009-11-03T21:23:01Z

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

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

The CHANGES file in
http://www.dcc-servers.net/dcc/dcc-tree/CHANGES and
http://www.rhyolite.com/dcc/dcc-tree/CHANGES and
starts with
Fix broken `dccifd -Q` reported by Mark Thomas.
Fix dccifd and dccproc parsing of Return-Path:<> reported
by Wolfgang Breyha.
Significantly improve compression on server-to-server flooding.

/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: DKIM signatures with DCC

2009-10-29T12:27:34Z

On Tue, Oct 27, 2009 at 10:21:03PM +0000, Vernon Schryver wrote:

> > From: Gary Mills <mills@...>
> > To: Vernon Schryver <vjs@...>
> > Cc: dcc@..., ophidian@...
>
> > > Reputations are not fungible or even transitive. Real reputations are
> > > individual, and that implies that each user must decide which senders
> > > (and so DKIM or other headers) are sending solicited or tolerated bulk
> > > email.
> >
> > If the sender works for a bank, for example, they are subject to the
> > bank's policies on e-mail. Employees of an organization are less
> > likely to send spam than are customers of an organization, for example.
> > Companies can fire employees, but they don't want to alienate their
> > paying customers.
>
> I fear the definition of "spam" there is not any and all unsolicited
> bulk email, but the self-serving nonsense of lawful opt-out email
> advertisers as fraud and other illegal junk but excluding lawful
> unsolicited bulk email advertising.

Yes, banks have marketing departments too. However, they also listen
when their customers complain. This can't be a big problem.

> My personal experience with
> very large banks and credit card companies is that they use exactly
> the same ESPs to send junk email I explicitly don't want as to send
> "security alerts" and similar that I probably should want.

Yes, I've seen that too. The ease of contracting out your e-mail
announcements makes it attractive. One used here even wanted our
signing key so they could make their mail look as if it came from us.

> There's
> nothing forged about junk advertising email that you've explicitly
> declined from your bank or stock broker. That makes using DKIM or
> anything else to prevent forgery ineffective.

That is actually a big step forward. Once an organization signs their
e-mail, they become accountable for it simply because it can't be
forged. If they don't respond to complaints, they can be delisted or
downgraded in a reputation database.

> Concerning the general value of DKIM:
> - Spam from Google that has DKIM signatures, like the wanted email as
> well as the spam from my big bank and credit card company.

This is true. However, the origin of the e-mail is no longer in
question. `abuse@...' does respond to complaints. So far,
we haven't whitelisted Google by DKIM signature, although we could.

> - Should I spend the time and effort to make this mailing list DKIM
> signed, or would my time be better spent putting DNSSEC signatures
> on rhyolite.com and dcc-servers.net using the ISC DLV registry?
> (I've spent the few minutes needed to sign the zones, but haven't
> mustered the ambition to sign up at https://dlv.isc.org/ )

I assume these are unrelated actions. If you signed the mailing list,
it would make it easier for me to whitelist it.

> - Are any of the ~830 mailing lists at umanitoba.ca found with an
> obvious search DKIM signed? What about other mail from
> cc.umanitoba.ca? Or would your time be better spent getting
> DNSSEC going on umanitoba.ca?

So far, we are not signing outgoing-email. It's easy for me to enable
it, though. Some uses of e-mail may break when I do that, but
eventually I'll have to. This points out a problem, of course.
Senders have to sign e-mail in order for recipients to check it.

[..]
> A DNS blacklist (DNSBL) is as much a reputation system as any other.
> The IP addresses in most DNSBLs are as practically unforgable as DKIM
> signatures. The problems with DNSBLs are that they list bad guys instead
> of good guys and IP addresses are a little (but not a lot) more subject
> to change than domain names.

In a sense that it true. I'd prefer something independant of a DNSBL
so I can use both together.

--
-Gary Mills- -Unix Group- -Computer and Network Services-
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DKIM signatures with DCC

2009-10-27T16:03:13Z

On Tue, Oct 27, 2009 at 10:21:03PM +0000, Vernon Schryver wrote:
>
> } On Mon, Oct 26, 2009 at 08:44:23PM -0700, Earl Killian wrote:
> } > What about using DNSWL on the IP address? They have none, low, med,
> } > high trustworthiness levels.
>
> Would people consider it worthwhile for the DCC client programs,
> dccm, dccifd, and dccproc, to honor DNS whitelists? I'm not a fan
> of http://www.dnswl.org/ or the general idea, but that doesn't mean
> the code shouldn't support it if it would be used.

I would definitely use it. Whitelisting is probably the most maintenance-intensive part of using dccm and anything that somehow would mitigate the need of manual whitelisting by users would be welcome. And besides all that, there isn't much support in software for DNS whitelists at this time, adding support can only contribute to better and maybe more whitelists.

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

Re: DKIM signatures with DCC

2009-10-27T15:21:03Z

> From: Gary Mills <mills@...>
> To: Vernon Schryver <vjs@...>
> Cc: dcc@..., ophidian@...

> > Reputations are not fungible or even transitive. Real reputations are
> > individual, and that implies that each user must decide which senders
> > (and so DKIM or other headers) are sending solicited or tolerated bulk
> > email.
>
> If the sender works for a bank, for example, they are subject to the
> bank's policies on e-mail. Employees of an organization are less
> likely to send spam than are customers of an organization, for example.
> Companies can fire employees, but they don't want to alienate their
> paying customers.

I fear the definition of "spam" there is not any and all unsolicited
bulk email, but the self-serving nonsense of lawful opt-out email
advertisers as fraud and other illegal junk but excluding lawful
unsolicited bulk email advertising. My personal experience with
very large banks and credit card companies is that they use exactly
the same ESPs to send junk email I explicitly don't want as to send
"security alerts" and similar that I probably should want. There's
nothing forged about junk advertising email that you've explicitly
declined from your bank or stock broker. That makes using DKIM or
anything else to prevent forgery ineffective.

Concerning the general value of DKIM:
- Spam from Google that has DKIM signatures, like the wanted email as
well as the spam from my big bank and credit card company.
- Should I spend the time and effort to make this mailing list DKIM
signed, or would my time be better spent putting DNSSEC signatures
on rhyolite.com and dcc-servers.net using the ISC DLV registry?
(I've spent the few minutes needed to sign the zones, but haven't
mustered the ambition to sign up at https://dlv.isc.org/ )
- Are any of the ~830 mailing lists at umanitoba.ca found with an
obvious search DKIM signed? What about other mail from
cc.umanitoba.ca? Or would your time be better spent getting
DNSSEC going on umanitoba.ca?

> Yes, it seems that e-mail senders are willing to pay to improve the
> `deliverability' of their e-mail. Here's an example, taken from
> a recent e-mail marketing message:
>
> http://www.isipp.com/iadb.php

The reports on "Secrets to Email that Gets Opened & Read" and "How
Engagement Metrics Influence Deliverability" on http://habeas.com/
are more ironically relevant to reputations and DKIM. Didn't Habeas'
second or third business plan involve selling some sort of whitelist
service to spam targets?

} From: Gary Mills <mills@...>
} To: Earl Killian <earl@...>

} On Mon, Oct 26, 2009 at 08:44:23PM -0700, Earl Killian wrote:
} > What about using DNSWL on the IP address? They have none, low, med,
} > high trustworthiness levels.

Would people consider it worthwhile for the DCC client programs,
dccm, dccifd, and dccproc, to honor DNS whitelists? I'm not a fan
of http://www.dnswl.org/ or the general idea, but that doesn't mean
the code shouldn't support it if it would be used.

} We do subscribe to Spamhaus' DNS-based blocklist. They are
} invaluable, and integrate nicely with DCC. Most of our rejections
} are based on their ZEN database now. However, nothing compares
} with cryptographic signatures like DKIM. These prevent forgeries.
} That's why we would like to make increased use of DKIM.

A DNS blacklist (DNSBL) is as much a reputation system as any other.
The IP addresses in most DNSBLs are as practically unforgable as DKIM
signatures. The problems with DNSBLs are that they list bad guys instead
of good guys and IP addresses are a little (but not a lot) more subject
to change than domain names.

> From: "John R. Levine" <johnl@...>

> > At my organization, people complain about receiving spam. They want
> > me to stop it. I wonder if they are also willing to pay.
>
> Of course not. The essence of Internet Economics is to foist your costs
> off on someone else. That's why we have spam in the first place.

including the individual personal costs of time and effort to
maintain private white- and blacklists.

You could build a local DNSBL that covers all of the Internet except
University of Manitoba IP addresses. Then you could let people who
complain about spam turn it on in their individual DCC whiteclnt
files and add whitelist entries to those same whiteclnt files with
something like the proof of concept cgi scripts.

> People are building them, but I doubt you'll find many being given away
> for free.

as demonstrated by Spamhau' prices for their reputation databases
including ZEN. Or DCC Reputations.

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

Re: DKIM signatures with DCC

2009-10-27T15:17:52Z

On Tue, Oct 27, 2009 at 05:12:04PM -0400, John R. Levine wrote:
>
> >In any case, I see now that waiting for somebody to compile a reputation
> >database is futile.
>
> People are building them, but I doubt you'll find many being given away
> for free.

We are willing to pay for one, and to contribute to one.

--
-Gary Mills- -Unix Group- -Computer and Network Services-
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DKIM signatures with DCC

2009-10-27T15:09:48Z

DNSWL is a "white list", not a blacklist. I thought that was what you
were looking for. I use both ZEN and DNSWL. Anything in DNSWL with a
trustworthiness of "high" gets to skip greylisting for example.

I also use a couple of RHSBLs (they say whether the sender name (not
IP)) is blacklisted. You would reject even DKIM validated sites if
they were in the RHSBL.

I actually use SPF rather than DKIM, and I see lots of rejections from
that. I have not investigated how to use DKIM. I guess I will look for
a HOWTO.

-Earl

On Oct 27, 2009, at 1:36 PM, Gary Mills wrote:

> On Mon, Oct 26, 2009 at 08:44:23PM -0700, Earl Killian wrote:
>> What about using DNSWL on the IP address? They have none, low, med,
>> high trustworthiness levels.
>
> We do subscribe to Spamhaus' DNS-based blocklist. They are
> invaluable, and integrate nicely with DCC. Most of our rejections
> are based on their ZEN database now. However, nothing compares
> with cryptographic signatures like DKIM. These prevent forgeries.
> That's why we would like to make increased use of DKIM.
>
> --
> -Gary Mills- -Unix Group- -Computer and Network
> Services-

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

Re: DKIM signatures with DCC

2009-10-27T14:12:04Z

> At my organization, people complain about receiving spam. They want
> me to stop it. I wonder if they are also willing to pay.

Of course not. The essence of Internet Economics is to foist your costs
off on someone else. That's why we have spam in the first place.

> In any case, I see now that waiting for somebody to compile a reputation
> database is futile.

People are building them, but I doubt you'll find many being given away
for free.

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

Re: DKIM signatures with DCC

2009-10-27T13:50:50Z

On Tue, Oct 27, 2009 at 03:30:12AM +0000, Vernon Schryver wrote:

> > From: "Chris Aseltine" <ophidian@...>
>
> > "Gary Mills" <mills@...> writes:
> >
> > > I've been using DCC to whitelist messages by DKIM signature for some
> > > time now, and have been quite pleased with the results. I keep the
>
> > > Unfortunately, the presence of a valid DKIM signature does not
> > > indicate that the message is not spam. It only indicates that the
> > > sending domain employs DKIM signatures. E-mail marketing companies,
> > > each with thousands of domain names, are signing their messages in
>
> > > So far, I've only accumulated twelve domain names that I trust not to
> > > send spam. This number has to be greatly expanded to make DKIM
> > > signatures truely useful. How can we do this? The usual answer seems
> > > to be a reputation database of domain names, but I've still not found
> > > such a thing. I'm certainly willing to pay for it. This is the
> > > missing piece in the puzzle.
>
> My answer is a useless rant about the lack of profit in selling genuine
> honestly-really-never-sends-spam reputations.

It's also practical ecomomics, and I appreciate that.

> If email reputations could work without manual whitelisting, then
> consumer and business credit ratings would be used for detecting
> good risks instead of avoiding bad risks. In the real world, people
> and businesses with excellent credit don't advertise it or even hide it
> (e.g. by locking their credit bureau reports). It's the others who
> jump through hoops like maintaining several active credit cards all
> below limit or blabbing all kinds of company confidential information
> to any phone caller that claims to be from D&B.

Yes, this is perverse.

> Reputations are not fungible or even transitive. Real reputations are
> individual, and that implies that each user must decide which senders
> (and so DKIM or other headers) are sending solicited or tolerated bulk
> email.

If the sender works for a bank, for example, they are subject to the
bank's policies on e-mail. Employees of an organization are less
likely to send spam than are customers of an organization, for example.
Companies can fire employees, but they don't want to alienate their
paying customers.

> Users who can't be bothered to make their own decisions should
> be encouraged to use Microsoft or Google, which my tests imply blacklist
> all mail except from senders who've done the equivalent of hiring help to
> improve their FICO credit scores.

Yes, it seems that e-mail senders are willing to pay to improve the
`deliverability' of their e-mail. Here's an example, taken from
a recent e-mail marketing message:

http://www.isipp.com/iadb.php

At my organization, people complain about receiving spam. They want
me to stop it. I wonder if they are also willing to pay. In any
case, I see now that waiting for somebody to compile a reputation
database is futile. It looks as if we'll have to do this ourselves.
I'll see what sort of structure I need to make that possible. DKIM
will still be the key to this treasure.

--
-Gary Mills- -Unix Group- -Computer and Network Services-
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DKIM signatures with DCC

2009-10-27T13:36:06Z

On Mon, Oct 26, 2009 at 08:44:23PM -0700, Earl Killian wrote:
> What about using DNSWL on the IP address? They have none, low, med,
> high trustworthiness levels.

We do subscribe to Spamhaus' DNS-based blocklist. They are
invaluable, and integrate nicely with DCC. Most of our rejections
are based on their ZEN database now. However, nothing compares
with cryptographic signatures like DKIM. These prevent forgeries.
That's why we would like to make increased use of DKIM.

--
-Gary Mills- -Unix Group- -Computer and Network Services-
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DKIM signatures with DCC

2009-10-26T20:30:12Z

> From: "Chris Aseltine" <ophidian@...>

> Vernon are you going to answer?
>
> "Gary Mills" <mills@...> writes:
>
> > I've been using DCC to whitelist messages by DKIM signature for some
> > time now, and have been quite pleased with the results. I keep the

> > Unfortunately, the presence of a valid DKIM signature does not
> > indicate that the message is not spam. It only indicates that the
> > sending domain employs DKIM signatures. E-mail marketing companies,
> > each with thousands of domain names, are signing their messages in

> > So far, I've only accumulated twelve domain names that I trust not to
> > send spam. This number has to be greatly expanded to make DKIM
> > signatures truely useful. How can we do this? The usual answer seems
> > to be a reputation database of domain names, but I've still not found
> > such a thing. I'm certainly willing to pay for it. This is the
> > missing piece in the puzzle.

My answer is a useless rant about the lack of profit in selling genuine
honestly-really-never-sends-spam reputations.

If email reputations could work without manual whitelisting, then
consumer and business credit ratings would be used for detecting
good risks instead of avoiding bad risks. In the real world, people
and businesses with excellent credit don't advertise it or even hide it
(e.g. by locking their credit bureau reports). It's the others who
jump through hoops like maintaining several active credit cards all
below limit or blabbing all kinds of company confidential information
to any phone caller that claims to be from D&B.

Reputations are not fungible or even transitive. Real reputations are
individual, and that implies that each user must decide which senders
(and so DKIM or other headers) are sending solicited or tolerated bulk
email. Users who can't be bothered to make their own decisions should
be encouraged to use Microsoft or Google, which my tests imply blacklist
all mail except from senders who've done the equivalent of hiring help to
improve their FICO credit scores.

Even Microsoft and Google require users to help. You can see that by
subscribing a Hotmail or Google mailbox to this mailing list and noticing
that it will go to your spam folder until you whitelist it. (You'd
have to confirm the subscription by sending the key from somewhere other
than those two continuing sources of unsolicited bulk email or getting
me to whitelist the mailbox.)

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

Re: DKIM signatures with DCC

2009-10-26T18:44:09Z

Vernon are you going to answer?

"Gary Mills" <mills@...> writes:

> I've been using DCC to whitelist messages by DKIM signature for some
> time now, and have been quite pleased with the results. I keep the
> sendmail headers in a separate file that's included into the
> `whiteclnt' file. They look like this:
>
> ok substitute Authentication-Results electra.cc.umanitoba.ca;
> dkim=pass (1024-bit key) header.i=@... ok
> substitute Authentication-Results electra.cc.umanitoba.ca; dkim=pass
> (1024-bit key) header.i=@...
>
> DKIM signature validation is extremely useful for spam control because
> it prevents forgeries. Any signed and validated message from
> USER@... is guaranteed to come from that
> organization. Forged messages from the same address will not pass
> validation, even if they are DKIM-signed. This is a great advance.
> It eliminates all the spam that comes from herds of compromised home
> computers. This is especially important for phishing attempts.
>
> Unfortunately, the presence of a valid DKIM signature does not
> indicate that the message is not spam. It only indicates that the
> sending domain employs DKIM signatures. E-mail marketing companies,
> each with thousands of domain names, are signing their messages in
> hopes that they will appear more legitimate. This means that there's
> no way to tell from the domain name itself if an organization does not
> send spam, like a bank or a university, or if they are one of those
> marketeers.
>
> So far, I've only accumulated twelve domain names that I trust not to
> send spam. This number has to be greatly expanded to make DKIM
> signatures truely useful. How can we do this? The usual answer seems
> to be a reputation database of domain names, but I've still not found
> such a thing. I'm certainly willing to pay for it. This is the
> missing piece in the puzzle.

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

DKIM signatures with DCC

2009-10-26T12:17:35Z

I've been using DCC to whitelist messages by DKIM signature for some
time now, and have been quite pleased with the results. I keep the
sendmail headers in a separate file that's included into the
`whiteclnt' file. They look like this:

ok substitute Authentication-Results electra.cc.umanitoba.ca; dkim=pass (1024-bit key) header.i=@...
ok substitute Authentication-Results electra.cc.umanitoba.ca; dkim=pass (1024-bit key) header.i=@...

DKIM signature validation is extremely useful for spam control because
it prevents forgeries. Any signed and validated message from
USER@... is guaranteed to come from that
organization. Forged messages from the same address will not pass
validation, even if they are DKIM-signed. This is a great advance.
It eliminates all the spam that comes from herds of compromised home
computers. This is especially important for phishing attempts.

Unfortunately, the presence of a valid DKIM signature does not
indicate that the message is not spam. It only indicates that the
sending domain employs DKIM signatures. E-mail marketing companies,
each with thousands of domain names, are signing their messages in
hopes that they will appear more legitimate. This means that there's
no way to tell from the domain name itself if an organization does not
send spam, like a bank or a university, or if they are one of those
marketeers.

So far, I've only accumulated twelve domain names that I trust not to
send spam. This number has to be greatly expanded to make DKIM
signatures truely useful. How can we do this? The usual answer seems
to be a reputation database of domain names, but I've still not found
such a thing. I'm certainly willing to pay for it. This is the
missing piece in the puzzle.

--
-Gary Mills- -Unix Group- -Computer and Network Services-
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: short log with dcc

2009-10-17T08:32:16Z

Vernon Schryver пишет:
> Because you are not sharing the checksums of the spam sent by your
> users, you are violating the license on the free DCC source. Please
> stop using the DCC software.
>
>
The system is in "proof of concept" stage now. And your behavior does
not look friendly. Instead of asking to share checksums you are asking
to stop using DCC. Probably, this mail list is not the place where
people are trying to help each other. Sorry if I caused inconvenience.

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

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

Re: short log with dcc

2009-10-17T07:12:03Z

> From: Bokhan Artem <APTEM@...>

> At the moment dcc is used for outgoing traffic only with local dcc server=
> =2E
> Incoming traffic averages per day are: 10M of recipients, 4.5 M=20
> connections, 400K messages are passed to mailboxes.
> I do not use global DCC servers because commercial filter does=20
> checksum-based filtering job and does it well.
> But we have special type of spam oriented only for our users, it is the=20
> reason I started the topic.

The license on the free version of the DCC software clearly requires
that you share the DCC checksums you compute with the rest of the
world with these words:

* This agreement is not applicable to any entity which sells anti-spam
* solutions to others or provides an anti-spam solution as part of a
* security solution sold to other entities, or to a private network
* which employs the DCC or uses data provided by operation of the DCC
* but does not provide corresponding data to other users.

Because you are not sharing the checksums of the spam sent by your
users, you are violating the license on the free DCC source. Please
stop using the DCC software.

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

Re: short log with dcc

2009-10-17T02:46:51Z

Vernon Schryver пишет:
> I don't think you have a local DCC server, and you have not attracted
> attention by using the public DCC servers to more than 100K msgs/day.
> Therefore it seems likely that your mail systems are handling
> fewer than 200K messages per day.
>
At the moment dcc is used for outgoing traffic only with local dcc server.
Incoming traffic averages per day are: 10M of recipients, 4.5 M
connections, 400K messages are passed to mailboxes.
I do not use global DCC servers because commercial filter does
checksum-based filtering job and does it well.
But we have special type of spam oriented only for our users, it is the
reason I started the topic.

>> Writing files to disk is expensive (all stuff is in memory now, no any
>> disk i/o),
>> writing files into memory and frequent postprocessing them with script
>> is an alternative,
>> but it does not look elegant and needs more memory.
>>
>
> If you don't have spare resources to write a 4K Byte log file, then you
> surely do not have the larger resources needed to fork(), exec(), parse,
> and run a script.

Script does batch job, so everything is not so bad as you said.
> Just creating the u area and the stack for the new
> process for the script probably involves more than 4KBytes of I/O (of
> course generally not to the disk).
>
> It is likely that there is no difference between writing a new log file
> of 100 bytes and writing a new log file of 4 KBytes, whether you
> use a memory file system or classic disk.
>
Writes are buffered, so I believe short log is about 4k/100=40 times faster.
> How are you using postfix+dccm? That last time I checked, I found
> that the postfix milter interface incompatible with the sendmail milter
> interface as far as dccm is concerned.
>
With current versions of postfix I tried a lot of different milters,
they all work as they should.
The only difference is you should always use extended smtp codes for
replies.
> Why not use postfix with dccifd as a before-queue filter? That's
> the recommended DCC configuration with postfix.
>
>
Milter is before-queue too. With milter it is easier to track
connections as all log records for particular connection always has the
same ID (inode name). Also it is easier to manage system because all
other filters are milters too.

> I predict that if you do change dccm, then in 6 months or a year from
now you or your successor will discard those changes and probably stop
using DCC.

That is not my case, sorry :)

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

Re: short log with dcc

2009-10-16T14:07:40Z

> From: Bokhan Artem <APTEM@...>

> > Building dccm with `./configure --with-max-log-size=1` would
> > limit log files to 1 KByte of message body.
> >
> The reason is the waste of resources, servers are quite busy with email
> traffic.

I don't think you have a local DCC server, and you have not attracted
attention by using the public DCC servers to more than 100K msgs/day.
Therefore it seems likely that your mail systems are handling
fewer than 200K messages per day.

20 years ago 200K msgs/day was a big deal. (I'll spare you war stories
of days when computers and networks were 1000 times and more slower.)
Today 200K msgs/day is not trivial, but not worth mentioning. I now run
spam traps that feed 30K spam/day through sendmail+dccm in about 1% of
a cheap computer.
If your mail system is quite busy with less than 200K msgs/day, it might
pay to look at your other spam filters that use lots of CPU cycles
such as DNSBLs, ClamAV, and SpamAssassin.

> Writing files to disk is expensive (all stuff is in memory now, no any
> disk i/o),
> writing files into memory and frequent postprocessing them with script
> is an alternative,
> but it does not look elegant and needs more memory.

If you don't have spare resources to write a 4K Byte log file, then you
surely do not have the larger resources needed to fork(), exec(), parse,
and run a script. Just creating the u area and the stack for the new
process for the script probably involves more than 4KBytes of I/O (of
course generally not to the disk).

It is likely that there is no difference between writing a new log file
of 100 bytes and writing a new log file of 4 KBytes, whether you
use a memory file system or classic disk.
Both will use at most data block and the same amount of inode and
indirect I/O in a classic filesystem. In a journaling filesystem, you
are also unlikely to be able to measure a difference between 100 bytes
and 4 KBytes.

Yes, I've encountered byte copy issues, bus occupancy, cache thrashing,
and other issues. However, they don't apply to the relatively small
amounts of data handled even by a busy mail system.

> > If you use dccm+sendmail,
> >
> I use postfix+dccm, I do not know yet when postfix writes message-id,
> before or after milter.

How are you using postfix+dccm? That last time I checked, I found
that the postfix milter interface incompatible with the sendmail milter
interface as far as dccm is concerned.

Why not use postfix with dccifd as a before-queue filter? That's
the recommended DCC configuration with postfix.

> Any advice about code hook place?

The best thing about open source is that you can read the source and
make needed changes. That is also the worst thing about open source.
People with much experience try to make as few changes as if the source
were secret. One reason is that local changes break the warrenty; admit
that you've changed the code and you'll find that any and all problems
you encounter are blamed on your changes. Another reason is that
integrating local changes into the next version, the version after that,
and the version after that, and so on is no fun at all after you've
done it a few times.

Over the decades, I've accumulated a big box of tools to make it easier
to port my improvements to successive versions other people's programs.
However, my most powerful and most often used tool today is resisting
the urge to make changes.
I predict that if you do change dccm, then in 6 months or a year from
now you or your successor will discard those changes and probably stop
using DCC. But of course, no one few who not been on the open source
merrygoround for decades sees it that way.

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

Re: short log with dcc

2009-10-16T12:06:21Z

> What is the purpose of not logging the entire message body?
> Are you trying to minimize disk space used for log files or are there privacy issues?
> Building dccm with `./configure --with-max-log-size=1` would
> limit log files to 1 KByte of message body.
>
The reason is the waste of resources, servers are quite busy with email
traffic.
Writing files to disk is expensive (all stuff is in memory now, no any
disk i/o),
writing files into memory and frequent postprocessing them with script
is an alternative,
but it does not look elegant and needs more memory.
> For a "this is spam" button, I would use something like the "this is
> not spam; stop greylist" button in proof-of-concept cgi scripts in the
> DCC source. That mechanism feeds checksum lines from log files to the
> dccsight program.
>
I will look, thanks.
> Note that message-IDs are not a reliable key for incoming mail
> messages. Not only does plenty of spam lack message-ID headers,
> but so does mail from systems using qmail.
I understand that. Did not know about qmail.
> If you use dccm+sendmail,
>
I use postfix+dccm, I do not know yet when postfix writes message-id,
before or after milter.
I do not see any other appropriate keys. Probably, I could create one
with milter before dccm. Probably, the dcc checksum could be the key itself.
>
> Vernon Schryver vjs@...
>
Any advice about code hook place?

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

Re: short log with dcc

2009-10-16T09:13:43Z

> From: Artem Bokhan <aptem@...>

> I want to find out, if there a way (may be dirty one) to log to file or
> syslog "email_address message-id checksum_type checksum" fields of
> messages, passed through dccm+dccd, without logging the whole body?
>
> With help of feedback from users ("this is spam" button) I want to use
> this log to find and mark messages (which are already sent to user
> mailboxes) with spam flag.
>
> If there is no standard way, could anybody point me the best place (may
> be variables names) I could inject my own code into? Any other help is
> also appreciated!

What is the purpose of not logging the entire message body? Are you
trying to minimize disk space used for log files or are there privacy
issues? Building dccm with `./configure --with-max-log-size=1` would
limit log files to 1 KByte of message body.

For a "this is spam" button, I would use something like the "this is
not spam; stop greylist" button in proof-of-concept cgi scripts in the
DCC source. That mechanism feeds checksum lines from log files to the
dccsight program.

Note that message-IDs are not a reliable key for incoming mail
messages. Not only does plenty of spam lack message-ID headers,
but so does mail from systems using qmail. If you use dccm+sendmail,
your users will see message-ID headers in all mail, but only
because sendmail will have added them. Because sendmail adds the
message-ID headers after dccm sees the message, they will not be in
dccm log files.

Note also that sendmail IDs in syslog are mostly distinct from SMTP
message-IDs.

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

short log with dcc

2009-10-16T08:04:25Z

Hello.

I want to find out, if there a way (may be dirty one) to log to file or
syslog "email_address message-id checksum_type checksum" fields of
messages, passed through dccm+dccd, without logging the whole body?

With help of feedback from users ("this is spam" button) I want to use
this log to find and mark messages (which are already sent to user
mailboxes) with spam flag.

If there is no standard way, could anybody point me the best place (may
be variables names) I could inject my own code into? Any other help is
also appreciated!
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: 51GB /var/dcc/log/

2009-09-17T08:18:01Z

On Thu, Sep 17, 2009 at 09:29:57AM -0500, Bob Pierce wrote:
> My /var/dcc/log/ directory has about 51GB of files that look like this:
> 8.0K -rw------- 1 root bin 6.6K May 26 05:10 msg.3wbrjV
> 36K -rw------- 1 root bin 33K May 26 05:57 msg.3wbrJV
> 12K -rw------- 1 root bin 11K May 27 10:03 msg.3wbRjv
> 12K -rw------- 1 root bin 9.2K May 27 10:03 msg.3wbRjV
>
> Is it ok to get rid of these files?

It's safe to delete msg.* (not tmp.*) but if you have made the logging available for your users somehow, they won't be able to see the logged messages you have deleted.

It may be worth looking at DCCM_LOG_AT (or DCCIFD_LOG_AT if you're using dccifd) in dcc_conf, you can increase the logging treshold so that less messages will be logged. It's also possible to decrease the size of logged messages but that's an at compile-time parameter you need to supply. (--with-max-log-size=KB).

Also there's an option called DBCLEAN_LOGDAYS which will clean the log directories for you, if you have scheduled cron-dccd ofcourse. You can also log messages in subdirectories (per day/hour/minute) which may just make cleaning up afterwards easier (and faster).

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

Re: 51GB /var/dcc/log/

2009-09-17T08:11:53Z

> From: Bob Pierce

> My /var/dcc/log/ directory has about 51GB of files that look like this:
> 8.0K -rw------- 1 root bin 6.6K May 26 05:10 msg.3wbrjV
> 36K -rw------- 1 root bin 33K May 26 05:57 msg.3wbrJV
> 12K -rw------- 1 root bin 11K May 27 10:03 msg.3wbRjv
> 12K -rw------- 1 root bin 9.2K May 27 10:03 msg.3wbRjV
>
> ..All msg.[something]
>
> Is it ok to get rid of these files?

The cron job /var/dcc/libexec/cron-dccd is a good thing for DCC clients
(systems using dccproc, dccifd, or dccm), because among other things
it cleans the main DCC client log directory and the per-user log
directories. It uses DBCLEAN_LOGDAYS in /var/dcc/dcc_conf.

That cron job required by any DCC server. It also runs dbclean to
expire old data in the server databases (both the main DCC server
database and the greylist database if greylisting is used by the DCC
clients). The cron job also does some sanity checking and restarts
the server if it is not running but dcc_conf says it should be.

The cron job is mentioned in the DCC installation instructions in
the DCC source or http://www.dcc-servers.net/dcc/INSTALL.html

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

51GB /var/dcc/log/

2009-09-17T07:29:57Z

My /var/dcc/log/ directory has about 51GB of files that look like this:
8.0K -rw------- 1 root bin 6.6K May 26 05:10 msg.3wbrjV
36K -rw------- 1 root bin 33K May 26 05:57 msg.3wbrJV
12K -rw------- 1 root bin 11K May 27 10:03 msg.3wbRjv
12K -rw------- 1 root bin 9.2K May 27 10:03 msg.3wbRjV

..All msg.[something]

Is it ok to get rid of these files?

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

Re: Ignore locally sent email - how?

2009-09-15T13:33:00Z

> From: Steve <links111@...>

> I would like for dcc to not consider, transmit, etc. locally sent
> email. By locally, I mean from cron, or other program on the Linux
> host itself. The mail system is postfix, and, we are using dcc via
> Spamassassin and procmail at delivery time.
>
> So, when mail comes from say a cron job, the ONLY received header is

> So, There is no FROM generated by Postfix.

while there might not be an SMTP From: header, I bet there is
an SMTP envelope Mail_From value.

> So, I am not sure how to
> whitelist these emails so when delivery occurs to local mail users,
> they do not get analyzed by dcc.

1. If you are using dccm with sendmail or dccproc with Postfix,
you probably know it and don't need to worry about the following:

1a. Ensure that you are using dccm or dccifd instead of dccproc
This is not strictly necessary, but it avoids some fidding
with SpamAssassin. If you are using SpamAssassin, ensure
that the DCC home directory is either the default /var/dcc
that SpamAssissin uses or that SpamAssassin is configured
to look for your preference.

Turn on dccifd by setting DCCIFD_ENABLE=on in /var/dcc/dcc_conf

Ensure that /var/dcc/libexec/rcDCC has symbolic links in /etc/init.d
rc.d, and so forth, or if you are using recent FreeBSD, ensure
that start/stop scripts in the current DCC port/packet are installed

2. turn on debug logging to by ensuring that /var/dcc/log exists and
there is a "option log-all" line in /var/dcc/whiteclnt (or that
relevant per-user whiteclnt files contain "option log-all" and the
matching per-log directories exist).

3. examine log files of mail messages for headers and other checksums to
whitelist by adding relevant lines to the main /var/dcc/whiteclnt
file or a per-user whiteclnt file

This is often easiest with web pages something like the proof-of-concept
mentioned on the main DCC web pages at
http://www.dcc-servers.net/dcc/#cgi-demo and
http://www.rhyolite.com/dcc/#cgi-demo
Those cgi scripts can be used on the main whiteclnt file and the
main log directory.

The short answer is probably to switch SpamAssassin to using dccifd
and to add these lines to /var/dcc/whiteclnt:
ok ip 127.0.0.1
ok ip ::1

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

Ignore locally sent email - how?

2009-09-15T12:48:42Z

I would like for dcc to not consider, transmit, etc. locally sent
email. By locally, I mean from cron, or other program on the Linux
host itself. The mail system is postfix, and, we are using dcc via
Spamassassin and procmail at delivery time.

So, when mail comes from say a cron job, the ONLY received header is
this:

Received: by host113.changedname.com (Postfix, from userid 0) id
4A8E114B8104; Tue, 15 Sep 2009 03:53:19 -0500 (CDT)

So, There is no FROM generated by Postfix. So, I am not sure how to
whitelist these emails so when delivery occurs to local mail users,
they do not get analyzed by dcc.
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC version 1.3.114/2.3.114 released

2009-08-26T06:57:59Z

> I've released version 1.3.115/2.3.115 with what I hope is a fix.

It's been running less than an hour, but since the .114 crash happened
about every two minutes, that seems to have fixed it. Thanks!

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

Re: DCC version 1.3.114/2.3.114 released

2009-08-25T19:49:16Z

> From: "John R. Levine" <johnl@...>

> > Version 1.3.114 of the DCC source is in

> I built it on freebsd 7.2 and it crashes:
>
> #0 0x08054554 in iflod_read ()
> #1 0x0804d741 in main ()

I see no crashes in the DCC server, dccd, on a 32-bit FreeBSD 7.2
system I built today for the purpose.
However, that program counter was enough of a clue to find a bug
that ought to cause crashes.

I've released version 1.3.115/2.3.115 with what I hope is a fix.

> I realize this isn't much of a backtrace, I've backed off to 1.1.103 and
> will try to build with symbols and get a better traceback.

An easy way to build with symbols and line numbers is to use
updatedcc, as in:

/var/dcc/updatedcc -e DBGFLAGS=-g

Updatedcc can also be used to back off to a previous version, as in:

/var/dcc/updatedcc -V 1.3.113

However, with the fix in 1.3.115, I hope neither of those are needed now.

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

Re: DCC version 1.3.114/2.3.114 released

2009-08-25T15:37:06Z

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

I built it on freebsd 7.2 and it crashes:

#0 0x08054554 in iflod_read ()
#1 0x0804d741 in main ()

I realize this isn't much of a backtrace, I've backed off to 1.1.103 and
will try to build with symbols and get a better traceback.

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

Re: DCC version 1.3.114/2.3.114 released

2009-08-25T12:43:45Z

On Tue, Aug 25, 2009 at 06:29:23PM +0000, Vernon Schryver wrote:
> Version 1.3.114 of the DCC source is in
> http://www.dcc-servers.net/dcc/source/dcc.tar.Z and
> http://www.rhyolite.com/dcc/source/dcc.tar.Z
>
> Commercial version 2.3.114 of the DCC Reputation code is in the usual place.
>
> I hope to release another version in a week or two with changes to
> DCC-server-to-server flooding. The fix to the high RTT problem
> should not wait.

Thanks, looks good:

s0:
dcc1.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 114.15+1000 ms RTT
100% of 2 requests ok 352.90+1000 ms RTT
100% of 2 requests ok 348.94+1000 ms RTT
dcc2.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 199.13+1000 ms RTT
100% of 3 requests ok 108.51+1000 ms RTT
dcc3.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 137.78+1000 ms RTT
100% of 2 requests ok 349.49+1000 ms RTT
dcc4.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 226.31+1000 ms RTT
100% of 2 requests ok 138.86+1000 ms RTT
dcc5.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 229.90+1000 ms RTT
100% of 2 requests ok 204.94+1000 ms RTT
s1:
dcc1.dcc-servers.net,- RTT+1000 ms anon
100% of 3 requests ok 125.25+1000 ms RTT
100% of 2 requests ok 270.66+1000 ms RTT
67% of 3 requests ok 561.97+1000 ms RTT
dcc2.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 207.53+1000 ms RTT
100% of 2 requests ok 122.80+1000 ms RTT
dcc3.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 122.32+1000 ms RTT
100% of 2 requests ok 270.44+1000 ms RTT
dcc4.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 226.74+1000 ms RTT
100% of 2 requests ok 122.72+1000 ms RTT
dcc5.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 243.51+1000 ms RTT
100% of 2 requests ok 209.71+1000 ms RTT
s2:
dcc1.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 113.94+1000 ms RTT
100% of 2 requests ok 244.56+1000 ms RTT
100% of 2 requests ok 242.54+1000 ms RTT
dcc2.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 202.17+1000 ms RTT
100% of 3 requests ok 107.95+1000 ms RTT
dcc3.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 137.76+1000 ms RTT
100% of 2 requests ok 243.04+1000 ms RTT
dcc4.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 247.96+1000 ms RTT
100% of 2 requests ok 142.42+1000 ms RTT
dcc5.dcc-servers.net,- RTT+1000 ms anon
100% of 2 requests ok 233.28+1000 ms RTT
100% of 2 requests ok 204.59+1000 ms RTT

Petar Bogdanovic

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

DCC version 1.3.114/2.3.114 released

2009-08-25T11:29:23Z

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

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

I hope to release another version in a week or two with changes to
DCC-server-to-server flooding. The fix to the high RTT problem
should not wait.

The CHANGES file in
http://www.dcc-servers.net/dcc/dcc-tree/CHANGES and
http://www.rhyolite.com/dcc/dcc-tree/CHANGES and
starts with
Make `/var/dcc/libexec/dcc-nagios -s server` monitor the number of
working floods.
Fix the high RTT bug reported by Petar Bogdanovic and Mike Cappella.
Speed up dbclean.

/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: courier/dcc - perlfilter?

2009-08-22T10:44:17Z

> > From: Matus UHLAR - fantomas <uhlar@...>
>
> > We have courier mail servers and I'd like to plug dcc reporting to them.
> > Does anyone have dcc filter for courier, configurable to report only?
> >
> > Or, is there an easy interface to dccifd available?
> > We use perlfilter with sim0ple script and I could manage to use that one.

On 20.08.09 17:58, Vernon Schryver wrote:
> The ASCII MTA-dccifd protocol is very simple and documented in
> the dccifd man page. See
> http://www.dcc-servers.net/dcc/dcc-tree/dccifd.html#Protocol
>
> The DCC source includes a sample Perl interface to the dccifd daemon using
> that protocol. See
> http://www.dcc-servers.net/dcc/dcc-tree/dccifd/dccif.pl
>
> Another example is in the SpamAssassin DCC plugin.

I know about all of these but they all require some hacking and coding to
implement in the filter I use. I was curious if there's some DCC.pm library
that would provide some simple function(s) to use the functionality. Maybe I
(or someone else) could turn some code into perl plugin, which could be later
user by SA DCC plugin and others...

> The hits for the obvious Google search might including something useful.
> http://www.google.com/search?q=dccifd+perl

I haven't found anything that would make my work easier so I'm asking if
someone here knows...
--
Matus UHLAR - fantomas, uhlar@... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Nothing is fool-proof to a talented fool.
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: courier/dcc - perlfilter?

2009-08-20T10:58:36Z

> From: Matus UHLAR - fantomas <uhlar@...>

> We have courier mail servers and I'd like to plug dcc reporting to them.
> Does anyone have dcc filter for courier, configurable to report only?
>
> Or, is there an easy interface to dccifd available?
> We use perlfilter with sim0ple script and I could manage to use that one.

The ASCII MTA-dccifd protocol is very simple and documented in
the dccifd man page. See
http://www.dcc-servers.net/dcc/dcc-tree/dccifd.html#Protocol

The DCC source includes a sample Perl interface to the dccifd daemon using
that protocol. See
http://www.dcc-servers.net/dcc/dcc-tree/dccifd/dccif.pl

Another example is in the SpamAssassin DCC plugin.

The hits for the obvious Google search might including something useful.
http://www.google.com/search?q=dccifd+perl

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

courier/dcc - perlfilter?

2009-08-20T10:19:11Z

Hello,

We have courier mail servers and I'd like to plug dcc reporting to them.
Does anyone have dcc filter for courier, configurable to report only?

Or, is there an easy interface to dccifd available?
We use perlfilter with sim0ple script and I could manage to use that one.

--
Matus UHLAR - fantomas, uhlar@... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I feel like I'm diagonally parked in a parallel universe.
_______________________________________________
DCC mailing list DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: high RTTs since upgrade from 1.3.109 to 1.3.113

2009-08-18T06:59:18Z

Yes, recent versions of the DCC client library have a bug that increases
the computed RTT to some servers. I have not released a fixed version,
because the fastest server remains fastest and I've been chasing what
might or might not be a bug in the DCC server.

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

Re: high RTTs since upgrade from 1.3.109 to 1.3.113

2009-08-17T18:11:14Z

On 8/17/09 3:49 AM, Petar Bogdanovic wrote:
> Hi,
>
> is it just me?
>

here's mine:

$ cdcc -V
1.3.113

$ cdcc info

# 08/17/09 18:09:21 PDT /var/dcc/map
# Re-resolve names after 19:34:03 Check RTTs after 18:20:20
# 8000.00 ms threshold, 8000.00 ms average 12 total, 11 working servers
IPv6 off version=3

dcc1.dcc-servers.net,- RTT+1000 ms anon
# 64.124.52.232,- z.dcc-servers ID 1049
# 100% of 32 requests ok 3269.79+1000 ms RTT 100 ms queue wait
# 152.20.253.5,- dcc.uncw.edu ID 1201
# 62% of 32 requests ok 3287.20+1000 ms RTT 100 ms queue wait
# 194.228.41.13,- CTc-dcc2 ID 1031
# protocol version 8
# 95% of 22 requests ok 3312.81+1000 ms RTT 100 ms queue wait

dcc2.dcc-servers.net,- RTT+1000 ms anon
# 71.246.8.99,- Misty ID 1170
# 100% of 32 requests ok 3289.68+1000 ms RTT 100 ms queue wait
# 217.20.119.18,-
sgs_public_dcc_server ID 1199
# 94% of 32 requests ok 3360.50+1000 ms RTT 300 ms queue wait

dcc3.dcc-servers.net,- RTT+1000 ms anon
# 209.169.14.27,- x.dcc-servers ID 104
# 100% of 32 requests ok 3276.61+1000 ms RTT 100 ms queue wait
# *209.169.14.30,- x.dcc-servers ID 104
# 100% of 32 requests ok 1197.94+1000 ms RTT 100 ms queue wait

dcc4.dcc-servers.net,- RTT+1000 ms anon
# 194.228.41.73,- CTc-dcc1 ID 1030
# protocol version 8
# 95% of 22 requests ok 3312.91+1000 ms RTT 100 ms queue wait
# 207.195.195.223,- SIHOPE-DCC-3 ID 1085
# 100% of 32 requests ok 3288.11+1000 ms RTT 100 ms queue wait

dcc5.dcc-servers.net,- RTT+1000 ms anon
# 80.91.36.101,- dcc1.aftenposten.no
ID 1215
# 100% of 32 requests ok 3317.00+1000 ms RTT 100 ms queue wait
# 195.20.8.232,- EATSERVER ID 1166
# 88% of 32 requests ok 3310.75+1000 ms RTT 100 ms queue wait

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

high RTTs since upgrade from 1.3.109 to 1.3.113

2009-08-17T03:49:38Z

Hi,

is it just me?

s0:
dcc1.dcc-servers.net,- RTT+1000 ms anon
# *137.208.8.26,- wuwien ID 1290
# 100% of 9 requests ok 2785.34+1000 ms RTT 100 ms queue wait
# 209.169.14.26,- x.dcc-servers ID 104
# 100% of 32 requests ok 3442.52+1000 ms RTT 100 ms queue wait
# 209.169.14.29,- x.dcc-servers ID 104
# 100% of 32 requests ok 3381.46+1000 ms RTT 100 ms queue wait

dcc2.dcc-servers.net,- RTT+1000 ms anon
# 71.246.8.99,- Misty ID 1170
# 100% of 32 requests ok 3436.82+1000 ms RTT 100 ms queue wait
# 195.20.8.232,- EATSERVER ID 1166
# 100% of 32 requests ok 3418.15+1000 ms RTT 100 ms queue wait

dcc3.dcc-servers.net,- RTT+1000 ms anon
# 194.228.41.73,- CTc-dcc1 ID 1030
# protocol version 8
# 100% of 32 requests ok 3425.19+1000 ms RTT 100 ms queue wait
# 209.169.14.27,- x.dcc-servers ID 104
# 100% of 32 requests ok 3442.32+1000 ms RTT 100 ms queue wait

dcc4.dcc-servers.net,- RTT+1000 ms anon
# 152.20.253.5,- dcc.uncw.edu ID 1201
# 100% of 32 requests ok 3442.25+1000 ms RTT 100 ms queue wait
# 194.228.41.13,- CTc-dcc2 ID 1031
# protocol version 8
# 100% of 32 requests ok 3424.86+1000 ms RTT 100 ms queue wait

dcc5.dcc-servers.net,- RTT+1000 ms anon
# 67.66.138.141,- ID 1356
# 88% of 32 requests ok 3457.28+1000 ms RTT 100 ms queue wait
# 216.240.97.12,- dmv.com ID 1181
# 100% of 32 requests ok 3437.55+1000 ms RTT 100 ms queue wait

s1:
dcc1.dcc-servers.net,- RTT+1000 ms anon
# *137.208.8.26,- wuwien ID 1290
# 97% of 32 requests ok 928.82+1000 ms RTT 100 ms queue wait
# 209.169.14.26,- x.dcc-servers ID 104
# 88% of 32 requests ok 3586.91+1000 ms RTT 100 ms queue wait
# 209.169.14.29,- x.dcc-servers ID 104
# 75% of 32 requests ok 3586.80+1000 ms RTT 100 ms queue wait

dcc2.dcc-servers.net,- RTT+1000 ms anon
# 71.246.8.99,- Misty ID 1170
# 100% of 32 requests ok 3582.66+1000 ms RTT 100 ms queue wait
# 195.20.8.232,- EATSERVER ID 1166
# 100% of 32 requests ok 3553.86+1000 ms RTT 100 ms queue wait

dcc3.dcc-servers.net,- RTT+1000 ms anon
# 194.228.41.73,- CTc-dcc1 ID 1030
# protocol version 8
# 100% of 32 requests ok 3568.34+1000 ms RTT 100 ms queue wait
# 209.169.14.27,- x.dcc-servers ID 104
# 88% of 32 requests ok 3586.91+1000 ms RTT 100 ms queue wait

dcc4.dcc-servers.net,- RTT+1000 ms anon
# 152.20.253.5,- dcc.uncw.edu ID 1201
# 100% of 32 requests ok 3586.59+1000 ms RTT 100 ms queue wait
# 194.228.41.13,- CTc-dcc2 ID 1031
# protocol version 8
# 100% of 32 requests ok 3568.42+1000 ms RTT 100 ms queue wait

dcc5.dcc-servers.net,- RTT+1000 ms anon
# 67.66.138.141,- ID 1356
# 88% of 32 requests ok 3591.21+1000 ms RTT 100 ms queue wait
# 216.240.97.12,- dmv.com ID 1181
# 97% of 32 requests ok 3582.40+1000 ms RTT 100 ms queue wait

s2:
dcc1.dcc-servers.net,- RTT+1000 ms anon
# *137.208.8.26,- wuwien ID 1290
# 100% of 28 requests ok 1350.95+1000 ms RTT 100 ms queue wait
# 209.169.14.26,- x.dcc-servers ID 104
# 100% of 32 requests ok 3544.09+1000 ms RTT 100 ms queue wait
# 209.169.14.29,- x.dcc-servers ID 104
# 100% of 32 requests ok 3506.10+1000 ms RTT 100 ms queue wait

dcc2.dcc-servers.net,- RTT+1000 ms anon
# 71.246.8.99,- Misty ID 1170
# 88% of 32 requests ok 3542.04+1000 ms RTT 100 ms queue wait
# 195.20.8.232,- EATSERVER ID 1166
# 100% of 32 requests ok 3522.43+1000 ms RTT 100 ms queue wait

dcc3.dcc-servers.net,- RTT+1000 ms anon
# 194.228.41.73,- CTc-dcc1 ID 1030
# protocol version 8
# 100% of 32 requests ok 3528.34+1000 ms RTT 100 ms queue wait
# 209.169.14.27,- x.dcc-servers ID 104
# 100% of 32 requests ok 3543.85+1000 ms RTT 100 ms queue wait

dcc4.dcc-servers.net,- RTT+1000 ms anon
# 152.20.253.5,- dcc.uncw.edu ID 1201
# 100% of 32 requests ok 3543.88+1000 ms RTT 100 ms queue wait
# 194.228.41.13,- CTc-dcc2 ID 1031
# protocol version 8
# 100% of 32 requests ok 3528.54+1000 ms RTT 100 ms queue wait

dcc5.dcc-servers.net,- RTT+1000 ms anon
# 67.66.138.141,- ID 1356
# 88% of 32 requests ok 3549.22+1000 ms RTT 100 ms queue wait
# 216.240.97.12,- dmv.com ID 1181
# 100% of 32 requests ok 3539.37+1000 ms RTT 100 ms queue wait

Thanks,

Petar Bogdanovic

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