lkml.org 
[lkml]   [2000]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ******* japanese garbage postings and possible HACK.
On Sun, 6 Aug 2000, Albert D. Cahalan wrote:

Please, send any followups via private email by removing
linux-kernel from the CC list. Reply either privately, or to the
procmail mailing list - of which subscription info is at the
bottom of this message, as well as on the procmail manpage.


>> This is not the first time Japanese Kanji (or whatever the hell
>> it is) have made it to the mailing list. I would have partially
>> quoted the message I am refering to, however when I TRIED to
>> quote it, PINE segfaulted saying "impossible or illegal character
>> in From line".
>
>First of all, I find this to be a strange complaint. I've never
>seen the Japanese spam that is supposed to be so common.
>Maybe it isn't going through vger itself?

Ok, I see this thread is coming back to life, so I want to put an
end to it for once and for all here.

For all intents and purposes, the problem is more or less
*SOLVED*. Therefore, I thank everyone who made procmail
suggestions, etc.. because the problem is no longer a boon.

Now, for the *FINAL* explanation.

1) I have received various postings in what I will term as
"Kanji" which is a japanese encoding used in email, etc.. From
what I understand now, there are different encodings however, but
I am collectively refering to them as "Kanji" as it is convenient
to me.

2) 99.9% of the "Kanji" postings that I have received have come
DIRECTLY THROUGH the lkml mailing list. Someone who isn't
getting them is irrelevant to me. *I* am getting them, and they
*WERE* from lkml. End of story. Someone else doesn't get them,
good for them. Maybe your filters are allready /dev/null'ing
them.

3) This is an English language mailing list. Postings in
non-English are improper. Therefore it stands to reason that
messages posted in encodings that are not English encodings are
also improper. So Japanese Kanji postings are DOUBLE improper.

4) SPAM postings are improper ANYWHERE. Every one of these
postings _THAT_I_AM_COMPLAINING_ABOUT_ (or was...) were SPAM
posted in Japanese Kanji. TRIPLE IMPROPER.

5) I was very upset because I get inundated with SPAM on a daily
basis. I am on 45 mailing lists. How I can and do manage that
volume of mail is my business so don't ask please. Dealing with
SPAM becomes A BIG ISSUE. People that are NOT on 45 mailing
lists can aim their "I don't get that much SPAM so I don't know
how you do" replies directly into /dev/null, because that is
where I'll be sending them.

6) Regardless of how 'kosher' people think it is to filter out
unwanted mail, each person is of their own free will to filter
out whatever they don't want regardless of someone else's
opinion.

7) My "****** Japanese postings" thread that I started, in anger,
was *NOT* aimed at Japanese people in any negative way, and if
any Japanese people were offended in any way, I VERY deeply
apologize. I was angry at getting the posting, which was SPAM,
unreadable, and undisplayable, which crashed my software back to
the command prompt 'apparently' (see below). Therefore, I want
to make perfectly clear it was NOT posted at a particular
group/race of people. The words chosen, were merely describing
the messages received, which were in a Japanese encoding. It
might as well have been in Egyptian heiroglyphics for all I care.
Then my message would have read "*****ing EGYPTIAN HEIROGLYPHIC
ENCODED MESSAGES!!!!!!!"

8) People responded telling me to use a different email program,
that mine sucks. While this is an amusing suggestion, obviously
responded to try and 'irk' someone anytime it is used (and it did
irk me) - it is NOT EVER a solution for ANYONE. I don't give a
rats ass if I was using the holy grail of GUI mail programs that
SPOKE JAPANESE/EGYPTIAN/MARTIAN/WHATEVER to me audibly - it is
USELESS to me, and since having foreign language support is
useless to me, upgrading my mailer so that it doesn't barf on
foreign mail is pointless. Furthermore, I was bothered by the
suggestion enough that I decided to DEBUG the problem, and found
out that it WAS NOT A BUG IN MY MAILER. The Kanji encoded
message contained control characters. One of them was CTRL-N,
which I've learned activates the console's secondary "G1"
character set. I was able to reproduce the "crashed" state in an
email message to myself by embedding such control characters.

9) The filters that were suggested to me came from various
different people, however I want to note that at least 10 people
with Japanese sounding names, in the *.jp domain, (and so I
assume they were Japanese) wrote me suggesting filters that might
handle the situation for me, and were very polite and helpful.
They seemed to realize that my posting was NOT aimed at attacking
them, but was aimed at attacking SPAM and unwanted mail postings.
So despite many people's thoughts that I was targetting a group
of people, I was happy to find out that that "group of people"
did not themselves feel I was attacking them. In other words,
they interpreted what I said correctly, and not personally.

10) The filter I'm using right now, grabs messages encoded in
iso-2022 encoding. This doesn't grab all, as there are other
encodings, but I'm going slow with the filters because I don't
want to over-filter. The filter has caught a few postings that
were otherwise legitimate postings. It appears that some
Japanese posters have in fact posted in English, however with
their mailer in iso2022 encoding. Since I'm not /dev/null'ing
the postings, I have seen them. This is unfortunate, since one
must have a way of judging the content of messages, and that is
what the content-type part of a Mime header is for. I have
thought about this problem for a while and I have concluded for
my _SELF_ that I will continue filtering iso2022 out without
reading. Even if the message is in English. It is the
responsibility of the SENDER of the message to ensure that their
mailer is configured to send mail properly encoded. If someone
sends English messages that claim to be iso2022, then they are
using their software incorrectly IMHO. As much as I wish I could
have 'the perfect mail filter' and recover all good postings, the
perfect mail filter does not exist. In looking through my
"JUNK" folder where this stuff gets filed, since the start of
enabling the filter, it has trapped 14 iso2022 messages. Only 2
of them were legitimate English postings to lkml. Due to the
volume of mail passing through lkml daily, 2 messages getting
lost during 2+ weeks due to claiming improper encoding, is a
small price to pay for trapping the true SPAM. That is my
opinion, my filter, and is unlikely to be changed by anyone,
unless they have an even better and smarter filter.



>> Since there is no way for vger to filter this japanese SPAM, does
>> anyone have a procmail rule which could do it? Or would
>
>I hope you can make exceptions for body text containing Linux stuff:
>
>linux kernel diff kmalloc printk VFS module oops linus ext2
>virtual char int core driver nfs include asm tcp proc beos befs
>scsi irda ircomm plip console video usb driver debian redhat
>fs/ init/ lib/ mm/ net/ ipc/ arch/ scripts/ Documentation/
>torvalds gnu samba apache unicode vfat + + + crash inode skbuf
^^^

Although you likely did it unintentionally, the above line
contains 3 + characters one after the other, I have put spaces in
between them to prevent duplicating the problem. This is an evil
thing to put into email. When an AT command set modem receives
these characters, it goes into command mode, and in effect
"hangs". When someone gets an email with these characters in it,
their modem will go into a "zombie" state, or hang up. Since the
message wasn't downloaded, they'll get stuck downloading it
again, and again, until the ISP removes the offending message
from their spool. Anyone with an AT command set modem that is in
fact affected by this, can reconfigure their modem to ignore the
command mode signal by putting "S2=255" into their init
string. If you find you aren't affected by it, then ignore
it. Only AT command set modems are affected, and not all AT
modems are affected. A good portion, but not all of them will
get 'stuck'. It isn't necessary for anyone to respond saying "my
modem doesn't do that" because I just stated that not all modems
do that. Someone always has to respond saying the opposite of
what you just said though, so I thought I'd clarify things for
the purists out there... <sigh>

>(the above is slanted towards topics with Japanese developers)

Well, that brings processing time up significantly I'd bet, but
if someone can put it into an efficient procmail recipe that is
optimized, I'd certainly give it a try - although an error could
possibly lose more mail than the filter was designed to catch...
I don't think nearly that many words need to be used though..


>> filtering out all postings from .jp do it? Are there any
>> japanese folk on the list with .jp addresses that make active
>> contributions? Just wondering because I want to permanently
>> filter this garbage which appears about once a week, but I don't
>> want to filter out legitimate postings from decent japanese folk.
>
>Not that I think this is the best way, but...
>
>Here is a list of people from the kernel source and elsewhere.
>Change 'X' to '@' to remove my spam protection effort.
>

Hmm. While that doesn't perfectly ensure that legitimate posters
will get through the iso-2022 filter, it certainly is a start.
I think I'd prefer to do this than the keyword idea above. It
isn't perfect, but it is better than the iso2022 filter alone.
What is needed now, is a filter which grabs all iso2022 mail, and
if it isn't posted by a legitimate Japanese mailing address (from
the list you provided) then it junks it, otherwise it accepts it
even though it would have normally been filtered. This will
minimize the chances of losing legitimate messages improperly
encoded.

At this point however, this is no longer a linux-kernel
discussion - by far. After this message, if someone wants to
continue the discussion, please send any 'flames' or other
similar via direct email and NOT to the list, or if someone wants
to discuss further procmail filtering ideas, PLEASE, lets move it
to the procmail mailing list. The procmail list is:

There exists a mailinglist for questions relating to any
program in the procmail package:
<procmail-users@procmail.org>
for submitting questions/answers.
<procmail-users-request@procmail.org>
for subscription requests.

Strangely enough, I am on the procmail list, but that is not its
address... Hmm. Its from the manpage though..


>> Any idea how to get procmail to grab these garbage postings, and
>> ONLY the garbage ones? I'm thinking a recipe looking for
>> addresses ending in .jp, and a subject containing any "$" chars
>
>The "$" rule could be used on non-japanese posts as well.
>Think about what non-hacker people use "$" to represent.

No, it wouldn't be a single $. Any message I receive with 4 or
more $$$ in its subject header, I would be willing to toss out
the window regardless of the actual content. I'd put $1000 on it
that it is either SPAM make money fast garbage, or Kanji. The
combination of filtering iso2022 and a few $$$ in the subject
would be very unlikely to kill legit mail.

Anyway, I let this thread DIE about 2 weeks ago, and someone else
tuning in late seems to have fired it back up... Lets please let
it die again. I will no longer respond to this thread and
include lkml in the CC field unless extremely warranted. I wish
I'd have posted my original to the procmail list to start
with... My fault.. Live and learn.. ;o)

TTYL

--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate

... Our continuing mission: To seek out knowledge of C, to explore
strange UNIX commands, and to boldly code where no one has man page 4.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.068 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site