VonEssen, John
Wed Oct 8 14:25:33 UTC 2003


I am not sure which is more disconcerting. The fact that they didn't
know about firewall implications (obviously DCC communicates through
some port, not just thin air), OR, the fact that they didn't even test
to see if the SA Rules where being processed properly. After a few 1000
messages, and not seeing any DCC_CHECK Rules, a light bulb should have
gone on! 

It looks like they sell a hardware application/appliance which probably
acts as a sendmail frontend with SA+MD. Mail can then relayed to users
on a backend mail system like Exchange. So every time they sell this box
to a new customer, the customer plugs it in with no firewall changes,
and voila, more abuse traffic is created.


-----Original Message-----
From: Vernon Schryver [] 
Sent: Tuesday, October 07, 2003 7:19 PM
Subject: //

The ~11 public DCC servers are watched for various problems.  One
involves broken firewalls that allow outgoing DCC requests but discard
responses.  The DCC client code tries to contact each of the public
servers a few times when it doesn't know of a working server.  Before
about version 1.1.45, dccproc didn't remember previous problems give
up without trying but would look for a working server every time.  As
a result traffic from such a broken anonymous DCC clients is multiplied
by about 50 times

Never mind how people can set up and ignore a spam filter that not
only doesn't work but generates a lot of useless traffic.  My hobby
horse this time concerns the outfits that are selling "email security"
boxes consisting of Linux or FreeBSD, SpamAssassin, a DCC client, and
often other free tools such as mimeDefang.  They configure the boxes
to try to use the public DCC servers, in effect taking and selling
the bandwidth, CPU cycles, and disk space of the people who provide
the public DCC servers, and then because of the firewall errors, do
not even provide working DCC filtering.

There is nothing wrong with reselling free source, since that's what
a free license allows.  Free source costs its source only once, when
it is written.  Reselling free services differs.  A service costs
every time it is used.  It is wrong to make money on other people's
free services.

Over the course of several weeks in August and September, I sent
increasingly shrill messages to contacts for an IP address that was
making more than 900,000 daily bogus requests of the public DCC servers.
Eventually I was contacted by someone at the organization responsible
for the IP address.  That person told me it was a trimMail box.  On
Sept. 15, Brian Gillette, President of Comco, Inc wrote to say in part:

] 1. When we designed trimMail Inbox, we built-in DCC querying,
] is that cool!" We (naively) did not consider that in the process, we
] be selling users your cycles and bandwidth. How stupid is that???
Indeed, we
] have a huge problem with selling your freely offered cycles. It stops

] ...
] If this strikes you as a good solution, I will have my guys build a
] server here for our customers. ...

I answered with a copy of my screed about what's needed for a DCC server
connected to the global network of ~200 DCC servers, and assumed the
problem was on its way to being solved.  However, I never heard another
word from Comco.  Since the original IP address stopped using the
public DCC servers entirely, I assumed that Comco had decided to stop
using the DCC or had chosen the much less effective mode of not
connecting their DCC server to the global network.

Dave Lugo has been looking at the daily lists of abusive or at least
sick clients of the public DCC servers.  He found that the top abuser
on Oct. 7 was another organization using a trimMail Inbox.
I guess Mr. Gillette's understanding of "NOW" differs from mine. is interesting.  It suggests that Comco
is also reselling DNS blacklists instead of aggregating them with
their own caching/recursing DNS server.  Such practices are one reason
MAPS said it started charging for access to the RBL.

Comco seems to say in #32 that only port 25 needs to be opened in
firewalls.  That seems odd.  An organization that was receiving mail
before installing a trimMail Inbox would already have port 25 open.
Firewall holes for port 53 are probably also needed by a trimMail
Inbox.  A DCC client requires firewall holes for UDP packets going to
as well as returning from distant port port 6277.

Vernon Schryver

P.S. I assume trimMail Inbox, dymeta, and Comco Inc are service marks
DCC mailing list

More information about the DCC mailing list

Contact by mail or use the form.