[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Open mailing lists

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 18 Jun 2012 17:45:22 +0300

svn_at_feb17.org wrote on Mon, Jun 18, 2012 at 07:16:01 -0700:
> On Mon, Jun 18, 2012 at 06:14:30AM -0500, Hyrum K Wright wrote:
> > It should also be pointed out that a spammer could easily subscribe
> > directly to the list and get all the address information that way,
> > completely by passing any archives.
> >
> > For completeness, the ASF's public archive policy, which we adhere to,
> > is here: http://www.apache.org/foundation/public-archives.html
> >
> > Best,
> > -Hyrum
>
> At least that's a tiny bit more work for them to sign up for every email
> list serve in the world. Harvesting openly published email addresses is
> just too easy. They would ideally never appear anywhere in the first
> place so they couldn't be mirrored. I understand your constrants but
> I still think this is appalling from an engineering point of view and
> won't participate if it means leaving a please spam me trail behind me.

Nearly all open-source projects rely on email communications, and most
are publicly archived in >1 places.

You could use auto-expiring email addresses (for example,
address-$((1+$(date +%Y%m%d)))@domain) --- they are still valid but
pretty useless for spammers.

> Sorry,
>
> Darren
>
> >
> > On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein <gstein_at_gmail.com> wrote:
> > > Darren,
> > >
> > > Over a dozen sites mirror our archives, usually by grabbing our published
> > > mbox for the list. As a result, we cannot control how they publish the email
> > > addresses contained within. It is also important for those mboxes to retain
> > > the email addresses for archival purposes, and so those third-party systems
> > > can allow proper replies (hopefully, only by humans, but as you've
> > > discovered... they are not all perfect).
> > >
> > > Sorry for any inconvenience, but please don't blame us. We do try to respect
> > > your privacy in our own web archive system.
> > >
> > > Cheers,
> > > -g
> > >
> > > On Jun 18, 2012 5:10 AM, <svn_at_feb17.org> wrote:
> > >>
> > >> Less than 2 months after using this mailing list I've started getting spam
> > >> to the custom email address I used to post here.  I think it's terrible
> > >> practice to openly publish email addresses in easily harvestable form.  I'll
> > >> be /dev/nulling this address and unsubscribing.  I hope you could reconsider
> > >> that policy,
> > >>
> > >> Darren
> > >>
> > >> On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote:
> > >> > On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote:
> > >> > > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin
> > >> > > <philip.martin_at_wandisco.com> wrote:
> > >> > > > svn_at_feb17.org writes:
> > >> > > >
> > >> > > >> A little more information on this.  I have probably rebuilt svn
> > >> > > >> about 20 times tonight from scratch, with
> > >> >
> > >> > Thanks to everyone who contributed useful clues on this.  Using the
> > >> > current code tree and rebuilding with different versions and combinations of
> > >> > libraries I narrowed the problem down to the apr version.  Either the build
> > >> > of my earlier apr 1.3.9 or the version itself was the problem.  The test
> > >> > suite was super helpful and the explanation about XFAIL vs FAIL.   I have a
> > >> > build using apr 1.4.6 that passes all the tests it should pass and more
> > >> > importantly actually works.    It might be helpful to print a reminder at
> > >> > the end of the default make step suggesting running the tests if this is a
> > >> > common problem.  There are a lot of dependencies and some of them seem to be
> > >> > a bit finicky.
> > >> >
> > >> > Thanks!
> > >> > Darren
> >
> >
> >
> > --
> >
> > uberSVN: Apache Subversion Made Easy
> > http://www.uberSVN.com/
Received on 2012-06-18 16:46:00 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.