[cairo] RE: You have been unsubscribed from the cairo-announce mailing list

[Bryce Harrington]

On Thu, Nov 02, 2006 at 09:52:44PM -0800, Carl Worth wrote:
> On Thu, 02 Nov 2006 21:37:15 -0800, Nathaniel Gray wrote:
> > No problem.  It's clear you were just trying to do right.  I'm mostly
> > annoyed at having to subscribe to post.  I know the spam situation
> > leaves few other options, but it's become a real obstacle.  I can't tell
> > you how many bugs I've not reported or how many problems I've left
> > unsolved because I didn't want to do the subscribe, mark-no-delivery,
> > get-folks-to-CC dance yet another time.
> 
> I understand completely. I'm also exceedingly annoyed by
> subscribe-to-post and it pained me to enable that for cairo's lists. I
> know it must discourage lots of useful messages coming through and
> that's a tragedy.
> 
> I know that a few mailing lists, (linux kernel and git for example),
> run without requiring subscription. What they do instead is install
> lots of spam filters and then those end up eating useful messages
> which get mis-diagnosed as spam. (Some recent messages to the git list
> came through with mangled URLs in them just so the sender could get
> past the mail filters. That was pretty painful too.)
> 
> > This is something that Mailman could make a lot easier, BTW.  If they
> > got on board some kind of web-of-trust type of identity management
> > system it would solve the problem for just about every project I care about.
> 
> I'd be happy enough to just allow any signed message to come through
> the list regardless of subscription status. I don't think I've ever
> seen any signed spam. I also don't think that exists as an easy option
> to click in the current mailman interface we have.

I don't know about signing, but mailman includes a whitelisting feature
("accept_these_nonmembers").  It seems like it wouldn't be hard to
build some kind of multi-project trust tool that lists highly
trusted members of one project, that other projects could whitelist.
For example, take the list members of project A who are also in project
A's AUTHORS file, and whitelist them for projects B, C, D...  Update the
whitelist a few times a year.

It'd need some security so not just anyone could get a listing of
trusted email addresses, but only accepted list administrators or
something.

Bryce