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
Description: S/MIME Cryptographic Signature