From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Mjfkb-000668-2m for garchives@archives.gentoo.org; Fri, 04 Sep 2009 20:51:17 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B89DCE062B; Fri, 4 Sep 2009 20:51:15 +0000 (UTC) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by pigeon.gentoo.org (Postfix) with ESMTP id 61412E062B for ; Fri, 4 Sep 2009 20:51:15 +0000 (UTC) Received: by fxm7 with SMTP id 7so889905fxm.34 for ; Fri, 04 Sep 2009 13:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=/bpkA4lUbJd5b7eKMj6pM6WykHRULVk8bn2ozQ9L0dM=; b=Y1jP5eLNCVP3d/pasY/voVLsdCPCsOl7NwTDN9Ifnb0d/HOJT7gSLp/zZvxJKPE+YG FIeuQQukKQe9I02SO5s068xn5+aK5BlZ2neQeINGKgVWjBrroZGgfVIgnOdHTp7NIz0F KwdvAINcRZDV2V9hwkXmSJSamKJ0dUQ1dWFXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; b=B44298NLocvDGGtlf2KxkWI/rJ25PS4q2eQjPGsnbaNUY1wP5fKY0owcoy1fp7g/CJ MCvWJqlNmmMXsaQClqQkUAdOW2LlFOCOK95mq0VCjNZQlKOV4Prg1cNfDqx8CRzs84r+ tFFfCGT2+nGAlTJ2xoLN9Ezdh8fR4uftRok8o= Received: by 10.86.18.34 with SMTP id 34mr5409081fgr.2.1252097473997; Fri, 04 Sep 2009 13:51:13 -0700 (PDT) Received: from nazgul.localnet (196-210-140-68-rrdg-esr-2.dynamic.isadsl.co.za [196.210.140.68]) by mx.google.com with ESMTPS id 3sm2496298fge.7.2009.09.04.13.51.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Sep 2009 13:51:13 -0700 (PDT) From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] {OT} reverse DNS problem? Date: Fri, 4 Sep 2009 22:49:40 +0200 User-Agent: KMail/1.12.1 (Linux/2.6.30-gentoo-r4; KDE/4.3.1; x86_64; ; ) References: <49bf44f10909031345r571d2157pf07e3adf66568c53@mail.gmail.com> <200909032314.58494.alan.mckinnon@gmail.com> <88FDB814-951C-4648-A1A3-9F8F40C86469@stellar.eclipse.co.uk> In-Reply-To: <88FDB814-951C-4648-A1A3-9F8F40C86469@stellar.eclipse.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909042249.40687.alan.mckinnon@gmail.com> X-Archives-Salt: b65eda41-dfa5-48ad-ac6f-41a98fd99825 X-Archives-Hash: ab967fd889bdd1a637871f0133f43d6d On Friday 04 September 2009 17:23:15 Stroller wrote: > You may be in a slightly exceptional position in that the bandwidth > cost - of syncing to Spamhaus and the additional DNS lookups - may be > prohibitive. UCLA are not. > > Whatever the proportion of legitimate mail this policy rejects, this > policy DOES reject legitimate mail, and that's pretty lame because > there are other ways to achieve the goal (reduction of spam) without > that side-effect. > > If you read postfix-users then you'll find many mail administrators in > a similar position to your own (dealing with millions of messages > daily) on that list, and that simply blocking home DSL connections is > not very popular amongst them. It's not considered a cool policy > because it's inefficient. I am not an expert on this subject - I'm > pretty sure there are other methods which will identify legitimate > hosts versus spammers which should be implemented before this one, but > I do not know the details. Every other solution out there has this one little problem that people seem to ignore. Per RFC, if you accept the connection and the mail, you will deliver it. That's what it says. It also says this since days long before spam problems, but still. We all conveniently ignore this if we are talking about what *we* consider spam, and by "we" I mean "everyone who cares to take an interest except the actual recipient". Yes, that's what it reduces down to. The recipient cannot by definition be part of the anti-spam process as the mail is discarded before he/she can see it. Yet we accepted the mail implying that we will deliver it... Best policy is to stipulate in the ISP's terms of service that you will not accept inbound mail connections from range you feel you cannot trust and users must use their ISPs mail relay instead. Instantly, 85% of the problem goes away, and I have numbers to prove it. Plus, it's very hard to police individual users out there, but if they use the ISP's relay instead I have a single point of contact. They will then police their own users (otherwise I cut their mail link), just like I police my own outbound users. And why is a user on a DSL range running a mail server anyway? The vast overwhelming majority of them are Windows zombies! And finally, my mail servers are mine and I make decisions about them, not someone else. -- alan dot mckinnon at gmail dot com