On Mon, May 11, 2015 at 03:39:13PM +0300, Andrew Savchenko wrote: > Unconditional adjustment of free software infrastructure for very > questionable rules of proprietary product is a very bad idea. It's an ecosystem. If we do nothing, we continue to penalize all developers who forward their mail to Google, as well as ANY users who would get mail from us sent to their Google accounts (forums notifications, bugzilla mail).
> > This is particularly acute, because more than 40% of the outgoing mail goes > > to > > Google (the 25% of destinations below is heavily represented because the > > very > > active devs send their mail to google). > > > > This unfortunate combination means that ~40% of mail sits in a backlog for a > > long time, and the active devs that use Gmail don't get their mail in a > > timely > > fashion. > Make this dropping optional: if devs are using gmail and really need > that filtering, they can opt-in. Left it opt-out for other devs. We ALREADY have the .permissive file, and have for many many years. Documented here: https://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_E-Mail#How_can_I_exempt_myself_from_Sender_Address_Verification.3F But, one of the problems with it is mail aliases. It cannot be set for any of the aliases, because the exploding of recipients is only done after receiving the mail. > Mail filtering is a minefield: too much spam is bad, loosing > even single important e-mail due to over restrictive filter is even > worse. > > I've had enough with over restrictive mail servers, e.g. blocking > entire countries and ip ranges. I don't want to see Gentoo going > that way too. > > > Unless there are any major objections, as of May 17th, Infra will start > > dropping mail that scores more than 10.0 points in Spamassassin. > > > > If that is successful, I propose to drop the score point by 1 point every > > month > > until it hits a score of 5.0 (so by mid-October, it will be dropping mail > > that > > scores more than 5.0). > Why so much focus on spamassassin? Why not to use (perhaps in > addition) more elegant technologies as the double grey listing? How about asking what Infra is using before that? amavis spamassassin greylisting sender address verification SPF (* with a permissive policy) DNSSEC Pyzor Razor2 DCC TextCat DKIM verifiation OCR** (was mostly a failure) SA channels in use are: updates.spamassassin.org sought.rules.yerp.org malware.org (* presently disabled, sa-compile takes 1hr+ on newer spamassassin) SARE was previously in use, but hasn't been maintained for years. You can see more of the details in bug #539420 as well. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
