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