From owner-freebsd-questions@FreeBSD.ORG Tue Oct 17 09:22:43 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 049BE16A40F for ; Tue, 17 Oct 2006 09:22:43 +0000 (UTC) (envelope-from norgaard@locolomo.org) Received: from strange.daemonsecurity.com (59.Red-81-33-11.staticIP.rima-tde.net [81.33.11.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7812343D62 for ; Tue, 17 Oct 2006 09:22:39 +0000 (GMT) (envelope-from norgaard@locolomo.org) Received: from [192.168.7.193] (68.Red-80-34-55.staticIP.rima-tde.net [80.34.55.68]) by strange.daemonsecurity.com (Postfix) with ESMTP id AC8F32E037; Tue, 17 Oct 2006 11:22:37 +0200 (CEST) Message-ID: <4534A0D8.2070909@locolomo.org> Date: Tue, 17 Oct 2006 11:22:32 +0200 From: Erik Norgaard User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ted Mittelstaedt References: <200610131712.46822.freebsd@alaskaparadise.com><4530DA30.7060004@locolomo.org><001c01c6eff4$f77cd590$3c01a8c0@coolf89ea26645> <453211C9.8030102@locolomo.org> <000001c6f1c1$c55e46b0$3c01a8c0@coolf89ea26645> In-Reply-To: <000001c6f1c1$c55e46b0$3c01a8c0@coolf89ea26645> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Beech Rintoul , freebsd-questions@freebsd.org Subject: Re: Non English Spam X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 09:22:43 -0000 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