Non English Spam

[Erik Norgaard]

Ted Mittelstaedt wrote:

>> Also this means that later filtering on the first Received field is
>> double work: You already accepted the mail based on that information.
>>
>> In short: Writing header filtering rules for the Received field is
>> simply waste of time and proof of inefficiency.
> 
> I agree with this but unfortunately the real world often screws this up.
> 
> For example, SpamCop is one of the most effective blacklists on the
> Internet because of it's high user participation.  Unfortunately, it
> repeatedly blocks yahoomail, craigslist, and ebay because spammers
> hate it and try to stuff it up so as to get people to stop using it.

You can't check the white list before using RBL in Sendmail? Well, you 
can with postfix, you can even control if checks should be done when the 
entire envelope is received or when the connection is established. Maybe 
postfix isn't that crappy after all :)

Of course, maintaining white lists is only practically possible for a 
limited number of hosts.

>> OP requested a way to filter away the spam in foreign character sets
>> because for some reason these were not caught by Spam Assassin or
>> procmail. I gave a solution that solves that problem, and I mentioned
>> the problem of false negatives for this list.
>>
>> Rather than get pissed, do try to offer an alternative solution to a
>> real problem.
> 
> There really is no solution.  Fundamentally, well written spam is
> not distinguishable from non-spam by a computer.  What has saved our asses
> so
> far is that there's not a spammer alive who has been able to resist the
> temptation
> to use bold, colors, blinking test, hot phrases, and other attention-getting
> devices in their spams.  Since you can program a computer to look for the
> attention getting stuff, what has happened is a little social engineering.

True - or the reverse, that novice users will send their birthday
invitation with flags and colors etc so you can't naively reject html mail.

> Frankly, I think there is no technical solution, I think there are only
> political solutions.  We've already made spam illegal in the US, and
> the CAN-SPAM act defines the "advertised" party in the spams
> also as a spammer, in addition to the actual spammer sending the
> stuff.

Actually, I do think there is a technical solution, but the problem is
that the cost of implementation is at the senders end, and the cost of
spam is at recipients end.

The political action needed is to move the cost onto the senders end - 
I'm not talking about adding a cost for sending individual mails but 
moving liability: You are responsible for what you send.

Basically, it's like for cars: You have an insurance for your car, even 
if a thief steals it your insurance covers accidents that the car may be 
involved in.

Once liability moves to the source, anyone upstream in the the mail 
delivery will make sure that they can pass on liability to someone 
further up, and if they can't, they will implement the controls to limit 
illicit mailing to reduce the risk.

>> I asked politely if there were any consensus or best practices etc. on
>> this issue. You have the regular mail on "how to get the best results"
>> there are recommendations on how to use this list, they are not enforced
>> but only serve as guidelines.
>>
>> I don't try to force people to use particular character sets, I merely
>> ask whether such recommendation exist for "the best results when using
>> the list", in which case filtering on charsets may be the least
>> imperfect solution (until you share your perfect filter, that is).
> 
> Your continuing to try to muddy the issue by inferring that personal
> filters are the same as requirements to post.

No, my idea is that if there is consensus that subscribers should post 
in say ASCII for the best results, then one could more reasonably filter 
other character sets because these are unlikely to occur. And, since 
foreign character sets are associated with language, other subscribers 
sharing language could take care of that off list - just as if someone 
writes in a foreign language.

> You snipped all my explanation of what the differences are and responded
> with a snotty request for a perfect filter, when I never said I ever had
> one.

I snipped, not to be rude, but because I felt you were getting emotional.

> As I already stated, what people do on their own mailserver is their
> business.  If they want to filter Asian charsets, then fine.  Go ahead.
> But, telling people they can't use them when posting to the list is
> crossing the line.
> 
> Certainly a "best results when using the list" document is a good thing.
> But, that is a recommendation, not a requirement.  The response that
> got me pissed was speculating that the list server should filter on Asian
> charsets,
> and we should order, not recommend, to
> people that they don't use Asian charsets.  I'm glad to see your
> backwatering from that.

I never intended to imply that the FreeBSD list server should filter
messages more than is done now. If you would go back to my first post I ask:

"What is the recommended policy here? Should subscribers be advised to
change character set when posting to the list?"

There is nothing here that implies that I want to the FreeBSD server to 
filter, nor that I want to prohibit postings in other character sets.

Rather I wanted to ask if charsets was or should be on the "best 
results" recommendation as in "you will possibly get a higher response 
rate by posting in English using US-ASCII or western European character 
sets". If so, then one can also better justify filtering on character 
sets even though some legitimate mails may be rejected.

Further taken in context, it is clear that there are recipients who do 
or wants to implement filters that filter on character sets. No one but 
you mentioned the FreeBSD server.

With all respect, I think the misinterpretation is all yours.

Cheers, Erik
-- 
Ph: +34.666334818                      web: http://www.locolomo.org
X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt
Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4228 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20061020/f950c9d0/smime.bin