Non English Spam
norgaard at daemonsecurity.com
Fri Oct 20 13:35:30 PDT 2006
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
> far is that there's not a spammer alive who has been able to resist the
> 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
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
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
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
> 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.
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...
Size: 4228 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20061020/f950c9d0/smime.bin
More information about the freebsd-questions