Can DCC catch Korean spam? Doesn't seem to, lots getting through

Vernon Schryver
Tue Apr 16 20:36:05 UTC 2002

> From: Chris Shenton <chris@Shenton.Org>

> DCC's doing a good job of catching spam to my home system, where I get
> maybe a thousand msgs a day total or so.  But it doesn't seem to be
> catching any of the increasingly large volume of spam originating in
> Korea.

As you no doubt know, the DCC does not specialize in acting based on the
source of spam.  A sendmail access_db with a list of all Korean and Chinese
/16 and /24 address blocks but excluding Australia and other places in
211/7 etc. would be handy for that.  I don't have one and wish I did.

> The following sample message (with obviously forged addresses) came
> from Korea, as the end of this traceroute shows:
> ...

`dccproc -QC` here turns that message into this:

X-DCC--Metrics: 101; Body=0 Fuz1=many
                                       checksum                 server  wlist
                 env_From: b642b421 7b34b1e8 d3bd915f c65c4452       0       
                     From: 338fd340 c8c328ba dd650fc5 6356b95d       0       
               Message-ID: d1110230 87b92303 2e107b1c 7b9ba904       0       
                 Received: 62ddf317 cb8c2e90 6aa7dd4e 3243a110       0       
                     Body: 8288359d 9e2c8537 ba7523e0 bc02f616       0       
                     Fuz1: 7915cb17 bb56bc4c 69fb8eae cd2d3d3a    many       

That means that the message was eventually reported as "many" or extremely
bulky. Judging from
`dblist -Hv | grep -B3 '7915cb17 bb56bc4c 69fb8eae cd2d3d3a'`
the DCC server with server-ID 1017 detected that spam at 
04/16/02 10:44:58 Mountain time.
If I've read the headers and timezones correctly, your copy reached
your system at 10:08 MDT, which would have been too early.

However, even if it was received after 10:45 MDT, it might not
have been caught unless your DCC client is version 1.0.53, because
of the Base64 decoding bug corrected in 1.0.53.
If the total targets reported by pre-1.0.53 DCC clients before
10:08 MDT had been high ehough (e.g. one client reporting "many" or
perhaps 5 clients reporting "10"), your system could have rejected it.
An experiment with a 1.0.53 client that should generate the same checksums
as pre-1.0.53 clients gives totals of 0.

The 1.0.53 source is at
I've been using minor variations of the script at
to fetch, compile, and install new DCC versions at MAPS and Usenix.

To deal with Korean and Chinese spam from whitelisted sources such as
IETF mailing lists, I've given up and started using procmail to
send mail matching
    * ^Content-Type:.*charset="*ks_c_5601-1987"*
    * ^Content-Type:.*charset="*euc-kr"*
    * ^Content-Type:.*charset="*ISO-2022-KR"*
    * ^Content-Type:.*charset="*GB2312"*
to `dccproc -t many`
That would not have caught this spam because it claimed to be 
charset=iso-8859-1, although it certainly doesn't look like it to me.

However, I also reject mail with a large sendmail access_db file that
would I think would have rejected and reported this spam as "many"
because its envelope Mail_From value was the ever popular

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.