From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 877FB138CCF for ; Mon, 11 May 2015 10:09:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3B1D7E086E; Mon, 11 May 2015 10:09:19 +0000 (UTC) Received: from mail.syndicat.com (mail.syndicat.com [62.146.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 053BEE082B for ; Mon, 11 May 2015 10:09:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=syndicat.com; s=x; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:To:From; bh=0Zs/rh2g9SF22t8O+mBjfK+x1iDPtvmQW6gVP9NRcdc=; b=zKO9xpEw59a8SNroji4dbAJ0mTGD+N2zxt2uZ0yAlC1FTcqpKJ4Z2UKmUcsuN6ufHooBg8ioWD3BHwo3bYC4vvRDA8w9kxHt3foBJE9kQ1SsODp3W6MyzH/3trq49zmKA7nyBKBtZTxjAYAPLnRiFLiyCMvWCZPWvtSkMLSt0sw=; Received: from localhost.syndicat.com ([127.0.0.1] helo=localhost) by mail.syndicat.com with esmtp (Syndicat.com PostHamster 4.84) (envelope-from ) id 1YrkeB-0001WM-Uf for gentoo-dev@lists.gentoo.org; Mon, 11 May 2015 12:09:15 +0200 X-Virus-Scanned: amavisd-new at syndicat.com Received: from mail.syndicat.com ([127.0.0.1]) by localhost (mail.syndicat.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2unln4oeh8q for ; Mon, 11 May 2015 12:09:15 +0200 (CEST) Received: from p50875a67.dip0.t-ipconnect.de ([80.135.90.103] helo=gongo.localnet) by mail.syndicat.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Syndicat.com PostHamster 4.84) (envelope-from ) id 1YrkeB-00019s-Lm for gentoo-dev@lists.gentoo.org; Mon, 11 May 2015 12:09:15 +0200 From: Niels Dettenbach To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail Date: Mon, 11 May 2015 12:09:08 +0200 Message-ID: <1626925.WQM6IekEy6@gongo> Organization: Syndicat IT&Internet User-Agent: KMail/4.14.6 (Linux/4.0.1-niels; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Archives-Salt: 7021e727-4ad1-4268-b2e7-61308e48c629 X-Archives-Hash: f516ed24d76147361d024f6b0aaaa334 Am Montag, 11. Mai 2015, 04:26:01 schrieb Robin H. Johnson: > This was a good early policy, as Gentoo was a much more reliable host= than > email providers a decade ago. This isn't true anymore, with the meteo= ric > rise > and success of gmail. This is not true at all - but email service "reliability" was and is no= t a=20 primarily question of the hosts OS nor some kjind of basic standard=20 configuration of a mailer "package" (or ebuild). > As past long-standing practice, @Gentoo.org system-level mail handlin= g for > incoming mail was officially to tag everything, and delete nothing. This is - for a public internet Mailer / MX - a VERY bad option - at le= ast=20 mail not fulfilling basic email standards should be blocked (as usual b= y the=20 very most professional level mail services), because it could be (used)= =20 abusive by thirds. > A LOT of developers forward their mail now, to systems that > refuse/temporarily blacklist the forwarding system because there is a= lot > of spam. Gmail is particularly strict in this regard, throttling mail= to > any recipient from the forwarding source. Gmail is crap (from my opionion) - at least for really professional ema= il=20 users or at least users which need a reliable email service (includes t= he=20 possibility to recieve or send out higher frequent emails or emails fro= m more=20 "exotic" sources). We - as a email provider - recognized the development of the rate limit= ing=20 policy by Google as well and it seems that Google is adapting that limi= ts by=20 the amount of mail which is send from google users into that "domains" = (as far=20 as this is correctly locatable for them, because by specs it is not=20 really...). This works OK for source mail servers / domains which still= have=20 "typical" email users and their regular traffic (or what googles thinks= about=20 - i.e. what some kind of user deletes without reading or is (i.e. false= )=20 marking as "spam") going to different recipients at google too, but not= very=20 well for more specialized email systems (like mailing list weighted mai= l=20 systems / MTAs or systems handling some kind of notifications for a lar= ger=20 amount of users / customers - (widely) independent from what type of ma= il they=20 transport and how high the part amount of spam within is).=20 For mail ISPs there is a contact where they can "complain" or "discuss"= about=20 limits with a mail server, but i did not know any case wher any answer = was=20 coming from them (does not mean that google did not recognizes it). But if someone decied for google as his primarily email provider - he h= as to=20 live with that policies from google, which might work OK for most peopl= es and=20 their "most peoples traffic". > Unless there are any major objections, as of May 17th, Infra will sta= rt > dropping mail that scores more than 10.0 points in Spamassassin. >=20 > If that is successful, I propose to drop the score point by 1 point e= very > month until it hits a score of 5.0 (so by mid-October, it will be dro= pping > mail that scores more than 5.0). This will work (depending form some of your SA setup details and how fa= r you=20 use all of the features, channels and possible extensions / third party= =20 services - i.e. DCC, Razor, Pyzor, "all" the different update channels,= Bayes=20 - while disabling DNSBLs and doing that still before in your mailer) un= til you=20 go down 5.=20 On 6 you typically will still get a lot of spam through (enough to make= users=20 work to sort it out regularly) while on 5 you definitely will loose ham= - even=20 if you still use the "usual" DNS based spam blocking lists (would let d= o this=20 the mailer before SA usually because of performance/ressource reasons).= So typical "working" values are between 5 and 6. But even then you will get spam, as long if you won't loose any ham "fr= om time=20 to time" - installing a filter solution like SA alone is just one part = of a=20 modern and working anti spam gateway with a zero false positive target = policy=20 (but might be enough to help your moderators here =C3=9F).=20 Most important tasks are to set up the MTA/MDA far enough to block emai= l which=20 are not fulfilling the specs and/or coming from machines which doesnt i= t - the=20 very most of spam should be catched here usually, but is is a dynamic t= asks to=20 know and/or find out which parts of the standards are important and whi= ch=20 less, because there are still many used mail systems out which are not=20= configured properly, but have a significant user base. But there are very good reasons why more and more admins of smaller oth= erwise=20 focussed admins decide to route their email traffic over a gateway mail= =20 service. Setting up a "just working" email system is a simple job today= , but=20 running a reliable internet email service on a more professional level = is a=20 real job which takes time and knowledge in maintaining that service - f= ar over=20 the setup details of a SMTP daemon (i.e. a proper DNS setup with PTR, D= KIM,=20 SPF, abuse contacts and so on) which often are out of scope of a typica= l=20 admin. hth a bit. cheerioh, Niels. --=20 --- Niels Dettenbach Syndicat IT & Internet http://www.syndicat.com PGP: https://syndicat.com/pub_key.asc --- =20