Subject: Re: Recent spam

From: [email-masked]
Date: Tue, 18 Jan 2000 12:13:26 -0500 (EST)

Paul,

when I first brought up the subject of chinese spam on the IETF
OpenPGP mailing list ("[email-masked]"), I was informed
that:

(a) a posting limitation for subscribers only was not acceptable
    to the IETF, and
(b) spam (10-30 mails per month maximum) was a complete
    "non-issue" (according to W. Geiger III).

The recent developments (currently already more than 10 spam
postings per _day_, creating a noise vs. signal ratio of about
97% vs. 3%, and the spam volume is still increasing!) should
prove very clearly that meanwhile spam _is_ an issue on this
mailing list. If this situation does not change, the list is in
danger of becoming unusable as real postings will get overlooked
in the flood of spam.

I do accept the openness of the list, so I am not suggesting any
limitation here. My log-files prove, however, that simply
enforcing RFC 822 + the MIME RFCs would remove nearly all of the
current spam:

_All_ of the chinese spam postings have one of the following
characteristics:

(a) They contain 8-bit characters in the e-mail headers (which
    violates RFC 822), or
(b) they have a MIME content labelling of "us-ascii" (= 7bit)
    while containing 8-bit characters in the mail body (violation
    of RFC 2045), or
(c) they have a MIME content labelling of "ISO-8859-1" while
    containing ASCII characters between 128 and 159 (which don't
    exist in ISO-8859-1, thus violating RFC 2045), or
(d) they have a content labelling of "GB_2312" (which signifies
    chinese encoding) and thus are certainly not applicable for
    any IETF purposes (although they do not really violate any
    RFCs to my knowledge).

Checking the headers for illegal 8-bit characters alone would
remove about 90% of the spam postings, and Werner Koch has posted
a solution how these mails could be easily filtered.

Could you please implement at least _some_ automatic checking
(e.g. along the lines of Werner's suggestion)? This would be a
one-time effort and the filtered postings could be deleted
automatically without inspection as they violate the mail
standards, anyway.

- Wolfgang Redtenbacher

---------------------------------------------------------------------
Redtenbacher Software                Tel.:   +49 7159 17046
Roemerstr. 11/1                      Fax:    +49 7159 17047
D-71272 Renningen                    e-mail: [email-masked]
---------------------------------------------------------------------

---

From: Paul Koning <[email-masked]>
Date: Tue, 18 Jan 2000 12:38:10 -0500

>>>>> "wolfgang" == wolfgang  <[email-masked]> writes:

 wolfgang> ...
 wolfgang> The recent developments (currently already more than 10
 wolfgang> spam postings per _day_, creating a noise vs. signal ratio
 wolfgang> of about 97% vs. 3%, and the spam volume is still
 wolfgang> increasing!) should prove very clearly that meanwhile spam
 wolfgang> _is_ an issue on this mailing list.

I was going along with the "just ignore it" approach last time it came 
up.  But at this point I have to agree with Wolfgang that the
situation is getting really bad.  Enough so to be significant even
though I have a high speed Internet link; if I had a dialup link I
would have been forced to unsubscribe some time ago.

Wolfgang's suggestion makes sense.  Another approach that would help
some, though presumably it wouldn't be politically acceptable, is to
reject any mesage that has a "*.cn" hostname in its forwarding path.

	paul

---

From: Will Price <[email-masked]>
Date: Tue, 18 Jan 2000 10:00:41 -0800

Absolutely.  The spam here is totally absurd.

Again however, I submit that trying to be "smart" about rejecting spam is
not the solution.  The people who send spam will always figure out a way
around it.  The immediate solution here is to change the name of the list,
and given the urgency of the situation at this point I think we should
change the name of list to "[email-masked]" and ask for forgiveness later.

-- 

Will Price, Architect/Sr. Mgr., PGP Client Products
Total Network Security Division
Network Associates, Inc.