public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Christopher Faylor <me@cgf.cx>
To: overseers@sourceware.org
Subject: Re: [My e-mail address in gcc-bugs mailing list archive]
Date: Thu, 03 Mar 2005 10:22:00 -0000	[thread overview]
Message-ID: <20050228180504.GJ29453@trixie.casa.cgf.cx> (raw)
In-Reply-To: <20050228095759.A31793@molenda.com>

On Mon, Feb 28, 2005 at 09:57:59AM -0800, Jason Molenda wrote:
>Hi all, sorry for not following the discussion too closely...
>
>Yeah, I know mhonarc can be configured to do all sorts of munging on
>the contents of messages.  I haven't looked at it recently (I've been
>meaning to update the version on sourceware for a year or two now...
>sigh), but we're not treading new ground here.
>
>On Mon, Feb 28, 2005 at 12:44:06PM -0500, Christopher Faylor wrote:
>
>>Actually, if we munged everything consistently, we could provide an
>>interface which gave you raw email addresses again, if you knew the
>>secret handshake.
>>
>>Perhaps Jason Molenda would like to comment on this interesting new
>>idea that I have just invented now, off the top of my head, without any
>>prior knowledge of anything which could potentially have been done
>>before...
>
>Hehe, yeah, as Chris implies, the "get raw text" cgi-mechanism that all
>the mailing list archives use does its munging on the fly; the files on
>disk are stored unmunged.  Right now it only munges addresses in
>headers; it would have to be modified by hand to munge addresses in the
>body of messages.
>
>But Chris, I'm not sure what you're impling here?  An option to the cgi
>script that would NOT munge the headers?  Surely that would be
>exploitable by spammers, wouldn't it?  Sounds like security through
>obscurity to me.  Not a good plan, that.  nomunge=1.

I wasn't exactly sure what I was implying either.  I guess it was
something like a "nomunge=1" option, the theory being that spammers
wouldn't be following the gcc mailing list where this setting could be
announced.

It is security-through-obscurity but it's similar to the current spam
blocking system.  A spammer just has to subscribe themselves to the
global-allow list if they want to spam mailing lists but I haven't seen
any clear indication of anyone doing that yet.  Having to special case
something like this seems to be contrary "send millions of emails to get
one response" economy that spammers use.  If they have to do research
to figure out how to spam or scrape this one mailing list, it doesn't
seem like that will be a very common thing.

Even if it was common, it won't be any worse than what we have now and
it should be slightly better.

(of course, I'm sure that all of this has been rabidly discussed on some
spam-related mailing list or newsgroup somewhere)

cgf

  reply	other threads:[~2005-02-28 18:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-01 14:02 Chris Faylor
2005-03-01 14:34 ` Ian Lance Taylor
2005-03-01 14:41   ` Christopher Faylor
2005-03-02 20:07     ` Ian Lance Taylor
2005-03-03  3:11       ` Christopher Faylor
2005-03-03  3:53         ` Jason Molenda
2005-03-03 10:22           ` Christopher Faylor [this message]
2005-03-03 20:34             ` Jason Molenda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050228180504.GJ29453@trixie.casa.cgf.cx \
    --to=me@cgf.cx \
    --cc=overseers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).