From owner-freebsd-questions@FreeBSD.ORG Mon Oct 20 21:44:34 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1622E1065671 for ; Mon, 20 Oct 2008 21:44:34 +0000 (UTC) (envelope-from clarkp@mtmary.edu) Received: from fear.mtmary.edu (fear.mtmary.edu [74.62.87.82]) by mx1.freebsd.org (Postfix) with ESMTP id CB7D98FC17 for ; Mon, 20 Oct 2008 21:44:33 +0000 (UTC) (envelope-from clarkp@mtmary.edu) Received: from [127.0.0.1] (war.mtmary.edu [172.16.0.200]) by fear.mtmary.edu (Postfix) with ESMTP id DF5A044B0CE; Mon, 20 Oct 2008 16:20:57 -0500 (CDT) Message-ID: <48FCF637.8080700@mtmary.edu> Date: Mon, 20 Oct 2008 16:20:55 -0500 From: Peter Clark User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Paul Schmehl References: <20081016090102.17qwm4xcs6f4so8ok@intranet.casasponti.net> <20081016145255.GA12638@icarus.home.lan> <17838240D9A5544AAA5FF95F8D52031604D8C7BA@ad-exh01.adhost.lan> <72F12B8A0320E2A18685A679@utd65257.utdallas.edu> <20081020171136.GA8224@icarus.home.lan> <33AA029CC5901B4D0781AA9D@utd65257.utdallas.edu> In-Reply-To: <33AA029CC5901B4D0781AA9D@utd65257.utdallas.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: I've just found a new and interesting spam source - legitimatebounce messages 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: Mon, 20 Oct 2008 21:44:34 -0000 Paul Schmehl wrote: > --On Monday, October 20, 2008 10:11:36 -0700 Jeremy Chadwick > wrote: > >> On Mon, Oct 20, 2008 at 11:16:31AM -0500, Paul Schmehl wrote: >>> >>> The best solution *by far* that I have found for spam (using Postfix) is >>> mail/postfix-policyd-weight. It routinely rejects 50 to 70% of incoming >>> mail with no false positives. It took *very* little tweaking to get it >>> to this point, and it rejects the mail before postfix even deals with >>> it. >>> I use spamassassin as well, but policyd-weight does the heavy lifting. >>> >> >> We used to use numerous features in postfix to block mail during >> different phases of the SMTP handshake, requiring strings meet RFC >> standards, comply with being FQDNs, resolve, blah blah... It >> worked great... until... >> >> One day, one of my users mailed me stating they were in a lot of >> trouble: they hadn't been receiving any mails from eBay, specifically >> contact from buyers/sellers (to negotiate payment means, etc.), and >> outbid notifications. >> >> I went digging through logs, and sure enough found the cause: eBay's >> HELO strings were what pedants would call "absolutely preposterous". >> They violated 3 or 4 different checks postfix had. At first I tuned >> postfix to allow certain IP blocks through that check, only to find >> that it's nearly impossible to determine all of the IP blocks eBay >> has -- in fact, some of their mail gets siphoned through a third-party >> mailer, and it looks like that mailer uses IPs all over the place. >> Meaning: administrative nightmare. >> >> There is nothing worse than telling your users "Okay, I've fixed it", >> only to get mail from them 24 hours later stating "Umm, no you didn't, >> and this is really starting to piss me off". >> >> I went through the same ordeal with other users and their LiveJournal >> mail notifications being blocked. >> >> The point I'm trying to make is that all this overly-aggressive >> filtering might work great if you're one guy maintaining your own box >> only used by you -- and I have a feeling a lot of people who post on >> this list are exactly that. It's a **completely** different game when >> you've got other people reliant upon your mail filtering decisions. >> >> The problem with blocking mail "early on" (meaning before it's queued, >> e.g. SMTP 5xx or 4xx rejections) is that the end-user has no knowledge >> of this. They simply do not get the mail. They're left in the dark, >> wondering "Did send the mail? Are they lying to me? What's >> going on???". It's a very sensitive thing when you're a hosting >> provider. >> >> In the case of my users, they would much rather get the mail and have it >> incorrectly flagged as spam, than not get it at all. I personally >> believe this directly reflects on the state of anti-spam affairs: we've >> gotten so aggressive that *who KNOWS* what kind of legitimate mail we're >> blocking. > > That's why it's critically important that whatever tools you use be > highly configurable. In the case of policyd-weight, you can configure > it so that it passes *everything* through but marks it in such a way > that you can filter it appropriately. > > In my case, I run a small hobby website with a minimal number of email > addresses. When I first installed policyd-weight, I watched it closely > and discovered it was blocking legitimate mail from sbcglobal because > they didn't have their mail servers' dns properly configured. The > result was a score just slightly higher than the threshold for rejection > (a tenth of a point or two.) I decided to make that particular check > worth less overall, and that solved the problem. > > I have yet to receive a single complaint about mail not getting through, > and, although there's only a handful of accounts on the server, we get > mail from our website users constantly. > > I fully understand where you're coming from, Jeremy. We have the same > issues at UTD. But for many smaller sites, policyd-weight would be a > godsend Is there an opinion on the end of policyd-weight? Specifically on the alternative listed on the main page, postfwd. Peter