Re: Non English Spam

Ted Mittelstaedt wrote:

Spammers cannot forge the Received header that your own mailserver
puts into the received message. The first Received line of the message
is always legitimate.

Please read my reply to Ian, who commented exactly the same. The Recieved headers are useless for filtering.

Accepting mail from a particular host should be done even before the
mail delivery starts.

Don't know what your talking about here.

The first Received header line, which as you correctly mention is (the only) reliable, is inserted by your own server based on the info from the establishing connection and HELO command.

In this case you can decide to accept or reject the mail before accepting the DATA. This is more efficient as you don't waste bandwidth receiving data you will later reject.

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.

Second: If you know postfix, you also know that header filtering is
independent of other checks, even the result of filtering on individual
header lines are independent.

I don't know Postfix. So what your saying is Postfix is so defective
that you can't use it for filtering? No wonder I never bothered to
deal with it.

Just as Sendmail, Postfix is not designed for spam filtering. Postfix provides simple filtering mechanisms, keeping it simple postfix provides an effective and reliable MTA that doesn't suffer the track record of security bugs Sendmail does.

When the native filters does not suffice you can combine with any number of "policy services": External filtering mechanisms such as postgrey, spam assassin etc. This design is clean, reliable and easy to manage.

I mentioned a solution using the mechanisms supported natively by postfix. OP had problems that spam assassin and procmail did not catch these mails.

Basically what you say here is that spammers have every right to flood
mail servers as long as they do so compliant with the RFC's?

I'm saying that you don't have the right to force other people to modify
their content on messages that AREN'T spam just because your spam
filters are too piss-poor to differentiate between an Asian charset message
that is spam, and an Asian charset message that is a legitimate message.

Call it piss-poor, but it is very effective, and simple to implement. If you have an effective alternative please do share.

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.

I don't force anyone to conform to any arbitrary standards that I decide
upon, but I have every legitimate right to reject anything that doesn't
conform to my arbitrary standards.

No argument there - but your crossing the line (or the other poster is
crossing the line) when your talking about telling list subscribers to
change charsets when they post.

I think you misread my original post. I brought up the issue exactly because filtering on charsets causes false positives whichever way you do it.

I don't have a particular desire to throw away legitimate mail, in fact I'd like to solve that problem (and I think OP want that too), but so far you have not contributed with a working alternative.

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).

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
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • MSF antispam info
    ... Spam and fraudulent e-mail messages are major issues for computer users ... Exchange Server, and Microsoft Exchange Hosted Filtering. ... and personalized spam protection while reducing false positives. ...
    (comp.mail.misc)
  • Re: Non English Spam
    ... Subject: Non English Spam ... Also this means that later filtering on the first Received field is ... repeatedly blocks yahoomail, craigslist, and ebay because spammers ... If they want to filter Asian charsets, ...
    (freebsd-questions)
  • Re: IP ranges used in North America, Hawaii, and Alaska?
    ... >> If you are trying to cut down on spam, ... > *Filtering* all that crap would cost a lot more. ... > That trick became useless when lists of dynamically-assigned ... The larger the network -- and presumably the more likely employees will ...
    (comp.os.linux.security)
  • Re: Non English Spam
    ... Subject: Non English Spam ... encoded in one of the above character sets, ... You know all too well that filtering based on "Received" header ... language specific lists - if their message is not simply ignored. ...
    (freebsd-questions)
  • Bystander shot by a spam filter.
    ... I believe spam and anti-spam measures are security issues -- ... product) are mislead about the probably of filtering the wrong mail. ... Spambouncer doesn't like Inflow. ...
    (FreeBSD-Security)