Messages in this thread | | | Date | Mon, 7 Aug 2000 12:44:54 -0400 (EDT) | From | "Mike A. Harris" <> | Subject | Re: ******* 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/
| |