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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to