From owner-freebsd-questions@FreeBSD.ORG Thu Jun 2 19:28:00 2005 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 890E316A41C for ; Thu, 2 Jun 2005 19:28:00 +0000 (GMT) (envelope-from bsilver@chrononomicon.com) Received: from trans-warp.net (hyperion.trans-warp.net [216.37.208.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A33D43D48 for ; Thu, 2 Jun 2005 19:27:59 +0000 (GMT) (envelope-from bsilver@chrononomicon.com) Received: from [127.0.0.1] (unverified [65.193.73.208]) by trans-warp.net (SurgeMail 2.2g3) with ESMTP id 10631994 for multiple; Thu, 02 Jun 2005 15:28:03 -0400 In-Reply-To: <08B46D9B-5FC0-4924-B287-2634268DF1A3@shire.net> References: <0a6397740f09ea4ac7cce0b1bead3bde@chrononomicon.com> <20050601143415.D69453@wolf.pjkh.com> <200506020949.54925.kirk@strauser.com> <08B46D9B-5FC0-4924-B287-2634268DF1A3@shire.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4ee98be1fb4890e46b1d7b3263d0e98d@chrononomicon.com> Content-Transfer-Encoding: 7bit From: Bart Silverstrim Date: Thu, 2 Jun 2005 15:27:49 -0400 To: "Chad Leigh -- Shire.Net LLC" X-Mailer: Apple Mail (2.622) X-Server: High Performance Mail Server - http://surgemail.com X-Authenticated-User: bsilver@chrononomicon.com Cc: freebsd-questions@freebsd.org Subject: Re: postgrey question 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: Thu, 02 Jun 2005 19:28:00 -0000 On Jun 2, 2005, at 1:14 PM, Chad Leigh -- Shire.Net LLC wrote: > > On Jun 2, 2005, at 8:49 AM, Kirk Strauser wrote: > >> On Thursday 02 June 2005 06:54, Bart Silverstrim wrote: >> >> >>> If people keep accepting broken implementation as the status quo, >>> we're >>> going to keep getting people who leave broken implementations in >>> place. >>> >> >> I have to agree with you on that one. Greylisting is no more >> non-standard >> than saying "I'm kind of having problems right now; please try again >> later". If a machine breaks on greylisting, then any number of other >> unintentional problems with also break it. On the positive side, so >> many >> servers are adopting greylisting that I suspect servers that can't >> handle >> it will get fixed rather quickly. > > > That is not the issue though. Lots of servers, especially public mail > providers, have tried greylisting and rejected it because their user > base complains that mail is delayed and they want to know that their > mail that their client, support people, etc just sent to them will get > there quickly, not 15 minutes, or 30 minutes, or whatever, later. The > biggest problems with greylisting are not the broken servers who do > not retry -- you can work around them -- it is that the incoming mail > is delayed and users don't like it. Now if you have a mail server > just for yourself or a special userbase this may not apply to you. > And this is why combining greylisting with spamassassin or other > antispam software is appealing -- you only grey list those mails you > have a good suspicion are actually spam. You do not greylist all > mails and so your userbase is happy since their expected email is not > delayed. According the postgrey's website, it supports automatic whitelisting, so in theory only a few emails from commonly-transacted email servers would be delayed. After that their favorite emails will come in quickly as if they were whitelisted. In fairness, there are other factors that could delay an email with the same effect as greylisting. Our users don't want to take the time to learn anything about managing their email properly, to do filtering at the MUA level, etc. We still have users who would run executable attachments from spoofed senders in their email and wonder why their computer is suddenly acting funny. A great many users abdicate responsibilities in order to not have to think...they want their ISP or sysadmins or techies to do the thinking for them. This is a question of tradeoffs. The problem with spam and abuse and malware has gotten to the point where I (and I suspect many others) no longer have the time or energy to keep chasing ways to make things better, and educating users can only be just so effective when they don't want to learn. It's been a long day, I guess. From what I can tell I'll probably be implementing postgrey, whether on the current server or on a rebuilt server, in the very near future. BOFH or not, I'm tired of the spam/malware hammering us and the jerk spammers that do slip past, and if the users need to wait a few emails before a site becomes whitelisted, so be it. If someone's email server is so broken that it can't handle a request to retry in a short future time, bleh. I don't want their email and my users can complain to them until they fix their server. I try to fix problems with my servers when they're brought to my attention. Other people should try to do so as well, and if you make it inconvenient for your users to do business with them and encourage the users to complain to them about the problem or switch to another service, you'll end up doing a service to other Internet users in the long run.