I mention it for two reasons. One, since mail lists manage e-mail addresses (and archives of e-mail addresses), it is yet antother indication of just why we have to be careful about presenting and disclosing that stuff.

Without in any way discouraging those efforts, isn't it somewhat futile? It seems that the area for improvement is on the receiving end filtering technology. Or am I missing something?

Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

On Sun, Feb 17, 2002 at 07:40:54PM -0800, Chuq Von Rospach wrote:

On 2/17/02 7:39 PM, "Larry McVoy" <lm@bitmover.com> wrote:

...

Without in any way discouraging those efforts, isn't it somewhat futile? It seems that the area for improvement is on the receiving end filtering technology. Or am I missing something?

That you can't get 100% success is no excuse for not trying -- or making it easy.

First, I tried to be clear that I wasn't saying "don't try". In case that's not clear "please do try to keep spam down". OK? I'm on your side, I'm not trying to argue with you at all.

Second, the point is that even if mailman is 100% perfect, it's not at all clear that that would result in even 1% less spam hitting home. If that's even remotely close, then it seems like efforts could be better spent on screening technology.

Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

On Sun, 17 Feb 2002, Chuq Von Rospach wrote:

On 2/17/02 7:48 PM, "Larry McVoy" <lm@bitmover.com> wrote:

...

Second, the point is that even if mailman is 100% perfect, it's not at all clear that that would result in even 1% less spam hitting home. If that's even remotely close, then it seems like efforts could be better spent on screening technology.

You can't assume your admins are going to want/have screening technology, unless you build it into mailman. And I don't think Mailman can simply say "hey, that's some other program's problem". We need to find ways to not become an easy source for the harvester machines. I DO know from my sites that addresses published ONLY as mailman admins get harvested and hit by spam. [SNIP] But at the same time -- I don't blame him. And Mailman has a responsibility to do something about that, the way we (as admins) have a responsibility ot our users not to make them easy fodder for the harvesters by publishing archives in an easy to harvest format...

I would just like to put in one thought... I like the whole small is beautiful philosophy. Maybe as you add more features, we can add some of these things as distict modules? I still feel the pipe is one of the best things *NIX has going for it. I worry about feature creap for a number of reasons. Just a thought.

-Keith

On Monday 18 February 2002 17:02, Chuq Von Rospach wrote:

On 2/17/02 7:48 PM, "Larry McVoy" <lm@bitmover.com> wrote:

...

Second, the point is that even if mailman is 100% perfect, it's not at all clear that that would result in even 1% less spam hitting home. If that's even remotely close, then it seems like efforts could be better spent on screening technology.

To me, it's more an issue of "we can't be part of the problem", not "we're the solution". I have a couple of admins who want their addresses removed from all public pages -- which I've refused to do, because I think the need for access by a user in trouble trumps the admin's privacy. I think at least one of those admins has solved it by setting up an admin-specific account, and redirecting it to /dev/null, which, if I ever definitely catch him doing so, will get him in trouble...

If they can set up admin specific accounts that redirect to /dev/null, then they can set up procmail to drop HTML mail, and say they're doing so anywhere they're advertising the admin email address. That would filter 90% of the spam they're likely to recieve for a start.

Something that mailman can help with, though - assistance in filtering based on whether the sender is joined to a list that the admin account is tied to. Just a simple boolean is/isn't on the list should be enough; leave the policy to the delivery agent/user.

John

On Monday 18 February 2002 17:56, Chuq Von Rospach wrote:

On 2/17/02 8:39 PM, "John Morton" <jwm@plain.co.nz> wrote:

...

If they can set up admin specific accounts that redirect to /dev/null, then they can set up procmail to drop HTML mail, and say they're doing so anywhere they're advertising the admin email address. That would filter 90% of the spam they're likely to recieve for a start.

And a bunch of legitimate mail, since more and more users are using HTML, and more and more systems are set up to send it by default. Not a solution, unless you primarily admin to geeks.

It's better than > /dev/null :-). Let's face it - if you're going to publish an admin address to help the lowest common denominator of netizen, then you can't munge it, so it will get spam. Mailman doesn't provide filtering for email accounts, nor should it. So the best you can do is advise admins of good filtering software, and best practice ways of using it. Droping html mail happens to be one practice that works pretty well for a given type of list membership.

...

Something that mailman can help with, though - assistance in filtering based on whether the sender is joined to a list that the admin account is tied to. Just a simple boolean is/isn't on the list should be enough; leave the policy to the delivery agent/user.

And how odes that does the "I'm trying to subscribe and can't make it work!"

It doesn't. But you can put all the requests from list members into another folder, or give them a higher priority. It all helps. If you need to prioritize subscription problems then you could use a feedback form, and maybe Mailman should provide one.

"My stupid IS department changed my address again and I need help!" problems?

I never understood why mailman wasn't changed to allow users to change there own addresses years ago. Being able to add valid receiving addresses would help, too. That is also something mailman can help with.

John

Chuq Von Rospach wrote:

Interesting article on slashdot:

<http://slashdot.org/article.pl?sid=02/02/17/2031249>

Basically, DSLreports did a test, and found that e-mail addresses posted on a web site could start seeing spam in as little as 8 hours.

I mention it for two reasons. One, since mail lists manage e-mail addresses (and archives of e-mail addresses), it is yet antother indication of just why we have to be careful about presenting and disclosing that stuff. And second, since one of the addresses presented and disclosed is that of the admin, we really need to come up with ways that allow newbies to contact an admin without easily disclosing addresses to spammers. And, unfortunately, the security problems with formmail.pl have shown THAT isn't really the answer...

Maybe not unpatched formmail, but a form for contacting a list admin can be much more secure than that; it only needs to know the list name to be able to send mail to the admin. Hard to use that for spamming.

Obscuring mail archives (possibly making them worthless as soon as the "un-obscurer" no longer functions) is IMHO not the way to go

/magnus

Chuq

-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.

Very funny, Scotty. Now beam my clothes down here, will you?

---

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers

On Sun, Feb 17, 2002 at 08:02:11PM -0800, Chuq Von Rospach wrote:

On 2/17/02 7:48 PM, "Larry McVoy" <lm@bitmover.com> wrote:

...

Second, the point is that even if mailman is 100% perfect, it's not at all clear that that would result in even 1% less spam hitting home. If that's even remotely close, then it seems like efforts could be better spent on screening technology.

You can't assume your admins are going to want/have screening technology, unless you build it into mailman. And I don't think Mailman can simply say "hey, that's some other program's problem".

I'm not in charge of as much mail as you, Chuq, but I've been around the block a couple times too... and I'm not sure I agree with that.

                                         We need to find ways to not

become an easy source for the harvester machines. I DO know from my sites that addresses published ONLY as mailman admins get harvested and hit by spam.

Yup, and so does every web page on the net, and it will keep happening until other things outside our control change markedly -- either on the network provider TOS enforcement side...

or on the find offenders and burn down their buildings side.

And I'm only partly kidding there.

To me, it's more an issue of "we can't be part of the problem", not "we're the solution". I have a couple of admins who want their addresses removed from all public pages -- which I've refused to do, because I think the need for access by a user in trouble trumps the admin's privacy.

Damn right it does. You're gonna be in the movies, you gotta expect to sign the occasional autograph at dinner.

                                                       I think at least

one of those admins has solved it by setting up an admin-specific account,

That's the proper solution.

and redirecting it to /dev/null, which, if I ever definitely catch him doing so, will get him in trouble...

But that's not, and I concur with your appraisal.

But at the same time -- I don't blame him. And Mailman has a responsibility to do something about that, the way we (as admins) have a responsibility ot our users not to make them easy fodder for the harvesters by publishing archives in an easy to harvest format...

Look up "enabler". This is an old argument. I don't know that I concur that reducing the pain threshold of people who might otherwise have an incentive to do *useful* work on spam reduction is a good idea.

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

At 7:12 -0500 2/18/2002, Damien Morton wrote:

There are several approaches to this, including the use of javascript email decryptors and/or publishing email addresses as rendered images.

I don't think we can assume that the user who feels a need to send mail to the admin has a JavaScript-capable browser with JavaScript turned on. Nor can we require it, IMHO.

--John (right now, I can't remember which browsers on which machines have Javascript turned on. Not good)

-- John Baxter jwblist@olympus.net Port Ludlow, WA, USA

On Mon, Feb 18, 2002 at 01:34:11PM -0500, Damien Morton wrote:

What do you think, then, of rendering the text of the email into a GIF or somesuch.

Combined with javascript, the clickable email functionality would be able to be retained, but for users without javascript functionality, they would have to read and type the email address manually.

I think it's about as worthless a solution as those 'Hey you! Don't steal my pictures!' javascripts that pop up when I right click ... to hit Back on the menu.

If the email address is in a user@domain.ext form *anywhere in the HTML code that's returned*, I can sift it out.

You'll have to forgive me, but this sort of 'too-clever by all' solution gives me hives.

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

At 10:47 AM 18/02/02 -0800, Chuq Von Rospach wrote:

...

You'll have to forgive me, but this sort of 'too-clever by all' solution gives me hives. And you have to be wary of solutions that make it tough for the naïve/novice net user to figure out what needs to be done. Those of us who geek tend to forget those that don't. And Mailman can't create systems non-geeks can't

On 2/18/02 10:37 AM, "Jay R. Ashworth" <jra@baylink.com> wrote: figure out, even if your preferred audience is geeks.

I don't know... I think rendering email addresses into pictures (say .png instead of .gif, but to A. User it makes no difference as long as it's read by the browser) is hardly something the average user can't understand. When you phone up tech support and they tell you to go to a web page, it's not like the spoken link is clickable. I'd say most people are quite capable of reading something and typing it out manually if clicking it doesn't work, otherwise there'd be no success in printing addresses in print ads, on T-shirts, etc. and I know I've seen plenty of lower-tech users type in urls from magazines. Sure, it's a hoop to jump through, but I wouldn't say that it's out of reach for anyone but geeks!

Of course, if you're talking about the javascript, that's something else entirely.

On 2/18/02 11:58 AM, "Damien Morton" <dm-temp-310102@nyc.rr.com> wrote:

I would suggest that a naïve/novice net user will be more familiar with web-based forms and web-based email than the email we know.

I did ten years of tech support.. Wanna bet?

You could, actually, be right. But making assumptions is a great way to screw it up. Thought, design and testing are the keys, not guessing.

The first is to enable users to engage list admins and have their problems sorted out, while discouraging or eliminating spam being sent to list admins. For this functionality, a web-based email form can be created. If you don’t know the admins email address, you use the form to initiate your conversation.

Some form of obfuscating the email address is needed. But here's the problem. If you use a web-based form to send email to the admin, how do you email the admin to say "did you know your site is broken and none of your pages are working?"

If the form breaks, how do you contact the admin through the form?

That's sort of a worst-case scenario -- but it's also a rather practical one. It happens. So at some point, you need some kind of mailto. But once you do -- it opens you up for spam.

Finding the tradeoffs here is the fun part.

The second issue is to prevent the email addresses of list members from being harvested from the archives.

Short answer; archives go behind a password. You authenticate access. Don't go over-fancy with images and scan/replace stuff. Right now, I have a hardwired password. Once 2.1 hits beta, I plan on working towards a solution that authenticates in apache to a mailman-subscribed address. I simply haven't had time yet.

-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.

Very funny, Scotty. Now beam my clothes down here, will you?

Chuq Von Rospach:

On 2/18/02 11:58 AM, "Damien Morton"

...

The first is to enable users to engage list admins and have their problems sorted out.

Some form of obfuscating the email address is needed. But here's the problem. If you use a web-based form to send email to the admin, how do you email the admin to say "did you know your site is broken and none of your pages are working?"

I propose a web-based form _with_ an image rendered email address.

If the form breaks, how do you contact the admin through the form?

Using the image rendered email address provided. You just cant click on it.

One might want to make it obvious that the image is an image rather than text, so that unwary users arent tempted to try cut and paste.

...

The second issue is to prevent the email addresses of list members from being harvested from the archives.

Short answer; archives go behind a password. You authenticate access. Don't go over-fancy with images and scan/replace stuff. Right now, I have a hardwired password. Once 2.1 hits beta, I plan on working towards a solution that authenticates in apache to a mailman-subscribed address. I simply haven't had time yet.

But we do want google et al to index the archives don't we? Ive found myself joining all sorts of lists that I found googling for this or that subject.

Put the raw mbox behind a reverse turing test. (See http://www.captcha.net/ for the orginal idea). Make the rest publically accessible, but with the actual email addresses obscured.

On 2/18/02 12:59 PM, "Daniel J. Cody" <djc@members.evolt.org> wrote:

Speaking of tradeoffs, it's my opinion that hiding archives behind a password protection scheme for fear that the administrator, who probably deals with oodles of email anyways and is probably the *most* experienced person in regards to email filtering etc, is a poor one.

whew.

The archives for a list I run happen to get around 100K referers from google a month, and again IMO, blocking those people out just because I'm getting 5 spams a month doesn't seem like the best idea.

You misread the intent here, probably because I was unclear.

You protect the archives because otherwise, your subscribers will be harvested. If your archives are in google, you're handing all of your subscribers to the spammers. You might as well burn them a CD.

To me, that's not remotely an option. If your archives are google-searchable, you're being harvested, and your users, if they ever figure it out, will thank you. Probably with a pitchfork.

Users of a mail list have a right to be protected from spam caused by your mail list. If you don't protect the archives from harvesting, frankly, you might as well stop rejecting spam sent directly to the list as well. And you know how well your users would take THAT decision.

We can argue the philosophy of archives in search engines -- but I consider stuffing email addresses in search engines to be a fatal error. You'll never convince me that's okay. And I've never convinced myself that castrating email out of an archive and then publishing the archive is worth the work and hassle. Your mileage on that latter probably varies.

Protecting admin addresses from spam is a second, separate issue. An admin has a responsibilty to be accessible to the outside public to answer questions and deal with problems. And because, if the pages DO break, one would hope the admin would like to know that so it can be fixed.

So you can't hide an admin -- but I think you also have a responsibility to protect that admin as much as you can, because it's already enough fun for the admin to run a list that adding "oh, yeah. Eat all this spam" on top doesn't seem to add many gold stars to the job description. So you have to look for ways to not make it easy for spammers, while not making it hard for real users.

http://evolt.org/article/mmdev/18/15126/index.html

Thanks. I'll go take a look. I'm always looking for better mousetraps.

But I'm curious whether your setup would catch and protect users from this: Last Friday, I got an emergency call from my assistant (I was at home, watching curling on CBC. Um, well, I was working from home). Our Mailman box at work was thrashed and shutting down.

I logged in and looked, and found that the web site was being whacked -- a robot of some sort was pulling down 40 pages in parallel, all at once. Definitely not a well-behaved beast.

When I went looking in the logs to see whether it was a system problem, an attack, or merely some clueless idiot interrupting my day, I found that while it was clearly an automated spider of some sort doing the page grabs, its user-agent promoted itself as a nice, generic IE on Microsoft Windows user. In other words, if you are assuming the harvesters aren't obfuscating the user-agent, I found out the hard way last week that's not true.

I'm still waiting to see if that guy comes back. I'm curious. And, now, watching...

I haven't seen a bot-catcher that I think reliably stops a bot that is actively trying to hide from me. Which means the GOOD spammers are going to fall under the radar, and you get this false sense of security, because of all of the stuff you Are stopping... Until I do find one, I'll use a password and some kind of authentication, and work my butt off to not let the data get out of my hands if there are email addresses in it (I just modified my T&C to explicitly deny people setting up public, third party archives without our approval of the archive, specifically so we have teeth to force them to protect their archives at least as much as we protect ours. It makes no sense putting a second deadbolt on the front door if you never lock the back. Letting your archives into google, IMHO, is putting the silver on the front porch so they can take it easier...

As an aside, how many that run 'larger' lists get a lot of spam? Using the same email address for list-admin going on 3 years now, I can probably count on my fingers and toes how many spams I've gotten to that address.

Oh, gee. You can have some of mine. You don't want to know. On my home/small server, a couple of the mail lists average 10-15 pieces a day, to it and to the admin. Right now, it's gone from making it bigger and increasing the volume to making it taste sweet.. Sigh.

-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.

On Tuesday 19 February 2002 04:21, Jay R. Ashworth wrote:

On Sun, Feb 17, 2002 at 09:37:31PM -0800, Chuq Von Rospach wrote:

...

...

I never understood why mailman wasn't changed to allow users to change there own addresses years ago. Being able to add valid receiving addresses would help, too. That is also something mailman can help with.

All it takes is code. Volunteering? (grin)

Because there's not a sufficiently strong method of authenticating that the person trying to change the address is actually the *user*?

No, it just involves squashing the two actions a user needs to take into one, more obvious action - rather than subscribe a new address, confirm it, then delete the old address and confirm it, you change the address (keeping the settings), and confirm both dropping the old address and sending to the new one as a pair of emails. Iff both confirmations succeed, the address changes, otherwise it stays as it was. Adding other valid sending addresses will also require an email confirmation action.

John

On Mon, Feb 18, 2002 at 02:58:01PM -0500, Terri Oda wrote:

I don't know... I think rendering email addresses into pictures (say .png instead of .gif, but to A. User it makes no difference as long as it's read by the browser) is hardly something the average user can't understand. When you phone up tech support and they tell you to go to a web page, it's not like the spoken link is clickable. I'd say most people are quite capable of reading something and typing it out manually if clicking it doesn't work, otherwise there'd be no success in printing addresses in print ads, on T-shirts, etc. and I know I've seen plenty of lower-tech users type in urls from magazines. Sure, it's a hoop to jump through, but I wouldn't say that it's out of reach for anyone but geeks!

Of course, if you're talking about the javascript, that's something else entirely.

Well, neither the JavaScript *nor* the picture are going to do me much good on the two browsers I use most often: Lynx 2.8.3 in a konsole window... and GoWeb 6 on my Palm/Minstrel handheld.

The former may not be especially mainstream, but anyone who ignores the latter category (not to mention my blind friend's screen reader) does so at their peril.

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

...

...

...

...

"Chuq" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

Chuq> Are there any other benefits to being googled than being a
Chuq> walking billboard to the list?

Yes. I do see a fair number of "non-subscriber" posts that go "we need to do job X, and according to a post I dug up googling for `job X' you can do this". It's hard to see how you can replace google for that purpose for XEmacs ... many values of "job X" you wouldn't normally associate with a text editor, even XEmacs. Those people are not going to go fishing in our archives, even if we had a reliable search function. So there is a lot of information in those archives that people are not going to be able to access without Google.

OTOH, I suspect that's pretty rare for Mailman, or even Python. Sure, you'll see the "job X" post, but they'll already know that Mailman or Python might do it, usually no need for Google, and definitely not to dig into ML archives. XEmacs is a special case.

I'll admit I'm not proud of the fact that it also publishes all those addresses, but I've got other things to do than sink a lot of time into changing something that's a long established practice at my organization, set up by somebody who knows a lot more about all this than me (and I'd really rather it stayed that way), and nominally a third person's job in any case.

-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

On 2/18/02 7:15 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:

Yup, and so does every web page on the net, and it will keep happening until other things outside our control change markedly -- either on the network provider TOS enforcement side...

Oh boy. Now I get to sound like your mother.. "If the other boys are going to jump off a bridge, does that mean you should?"

I can't fix the universe. I think it's silly to try. But you gotta start somewhere, and I think it's important to do what you can to fix the part of the universe you control. Because if you say "hell, it won't get fixed until someone else fixes it", doesn't that simply make it easier for all those "someone else"'s to do exactly the same?

You gotta start somewhere. You won't stop it yourself. But if everyone made some improvement, they all pile together into a big improvement.

Damn right it does. You're gonna be in the movies, you gotta expect to sign the occasional autograph at dinner.

I agree. But that also doesn't mean you should expect your home address and phone number to be published in the national enquirer.

...

and redirecting it to /dev/null, which, if I ever definitely catch him doing so, will get him in trouble...

But that's not, and I concur with your appraisal.

And that is why I'm forced to write a formal T&C (terms and conditions), which all my admins are going to be forced to agree to follow, or their lists will be shut down. And if they don't follow it, their lists will be shut down. Because I've tried the "we're all mature adults here, and I expect you'll do your job" and found that it works -- almost all the time. And the times when it doesn't are simply not acceptable. So I'm going to have to go through all this, just so there's no ambiguity in what's expected and what's allowed FOR THE ADMIN, so I can thumbscrew two or three into cooperation because treating them like mature adults didn't work. And the other 99% of my admins get taken along for the ride, since I have to be consistent here, if only to save myself from the next re-org...

Look up "enabler". This is an old argument. I don't know that I concur that reducing the pain threshold of people who might otherwise have an incentive to do *useful* work on spam reduction is a good idea.

These people have real jobs. Running mail lists is a secondary task (at best). "finding and killing spammers" is nowhere to be found. It's not enablement. If it were me, it'd be enablement. For them -- it's a pain in the butt and disincentive to do their real work. The people you're trying to turn into enablers never were and never will be part of the anti-spam war. They're collateral damage -- and I don't agree with you that "sharing the pain" will do anything but make them pissed and bitter. And I don't see that as an advantage.

-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.

The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after

Jay R. Ashworth writes: Well, neither the JavaScript *nor* the picture are going to do me much good on the two browsers I use most often: Lynx 2.8.3 in a konsole window... and GoWeb 6 on my Palm/Minstrel handheld.

The former may not be especially mainstream, but anyone who ignores the latter category (not to mention my blind friend's screen reader) does so at their peril.

I was wondering how long it would be before someone brought up the case for Lynx. Blind people I had not though about, although I had thought about text based reverse turing tests.

I know nothing of this GoWeb 6 that you speak of, youll have to describe it to me, but I assume its some kind of transcoding browser that doesnt handle images very well.

So one solution would be to have both public and private archives. The public archives have the email addresses obfuscated in some way, the private archives would not.

List members, and those able to pass a reverse turing test, would have access to the private archives, while the rest of the world would have access to the public archives.

Once we are talking about both public are private archives, however, we are probably also talking about the use of a cgi script which renders emails on the fly, depending on some kind of authentication. A cookie, perhaps.

Thoughts?

On Tue, Feb 19, 2002 at 04:46:24AM -0500, Damien Morton wrote:

...

Jay R. Ashworth writes: Well, neither the JavaScript *nor* the picture are going to do me much good on the two browsers I use most often: Lynx 2.8.3 in a konsole window... and GoWeb 6 on my Palm/Minstrel handheld.

The former may not be especially mainstream, but anyone who ignores the latter category (not to mention my blind friend's screen reader) does so at their peril.

I was wondering how long it would be before someone brought up the case for Lynx. Blind people I had not though about, although I had thought about text based reverse turing tests.

:-)

I know nothing of this GoWeb 6 that you speak of, youll have to describe it to me, but I assume its some kind of transcoding browser that doesnt handle images very well.

It's the browser on my wireless handheld, and, in general, it doesn't handle images *at all*. Nor will the microbrowsers on some people's cell phones.

So one solution would be to have both public and private archives. The public archives have the email addresses obfuscated in some way, the private archives would not.

Oh. We're talking about *archives*? Silly me. I thought we were talking about maintainer addresses on sign-up pages.

List members, and those able to pass a reverse turing test, would have access to the private archives, while the rest of the world would have access to the public archives.

Once we are talking about both public are private archives, however, we are probably also talking about the use of a cgi script which renders emails on the fly, depending on some kind of authentication. A cookie, perhaps.

Thoughts?

It's ASCII text. It's useful. Making it into something else makes it less useful, and as I noted in another posting, reduces the incentive to locate the spammers and commit arson upon their persons and property.

Cheers, -- jr 'closed captioned for the humor impaired' a

-- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

On 2/19/02 1:46 AM, "Damien Morton" <dm-temp-310102@nyc.rr.com> wrote:

Once we are talking about both public are private archives, however, we are probably also talking about the use of a cgi script which renders emails on the fly, depending on some kind of authentication. A cookie, perhaps.

That's pretty much exactly the path I felt this needed to go. Remove the password protection, and if you're not-authenticated as a subscriber to that list, all e-mail addresses are removed. If you are, you get the unedited message.

Whether you do this by putting all access to a directory structure behind a CGI, or whether you load it into a database, I'm not sure yet. The former would likely be less massive in the infrastructure. The latter might buy us a built-in search engine and a replacement for pipermail at the same time, but at the expense of a big glop-o-code and infrastructure requirements.

-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.

On 2/19/02 7:48 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

To be precise, it's not the subscriber list; only about 1 in 5 posts, ever.

And if you're that one, you don't really care that it's only 20%, do you?

I don't know. The people who post are a pretty public-spirited bunch, and they might very well volunteer for the abuse if that means that non-subscriber XEmacs users get better service.

Ask them! If they say yes, your situation is resolved. But those that say no are likely to drop off the list. But -- shouldn't they be given a chance to make an informed decision?

God, I think I sound like I'm beating on you again. I'm sorry. I'm not saying "the archives have to be protected" but "the users deserve to know what is going on and have some say in the use of their addresses". It's more informed consent issues. And this is an issue that I'm harping on because it's a piece of the net-reality that's changed over the last couple of years, from "standard practice/safe" to "jesus, not at all safe any more" and we're just getting visibility into what this means. And I'm doing it HERE because Mailman is one of those tools that is going to set default policy on how the non-savvy mail-list admins and sites are going to build and manage archives for the next five years -- so I feel we need to make sure Mailman does it in a way that does things "right", whatever that is.

So as Jay talks about enablers, one of the things I'm doing here overtly is trying to act as one on this topic, because if I can help make Mailman do it right, and educate the folks here, that'll make a positive difference in a way few other things can. I can't shut down open relays in Malaysia, but maybe, I can help educate folks on how to better limit access for the spammers in a tool that's becoming defacto-standard on the net as it supplants majordomo...

And with any luck, that's the last time I'll ever use the word "enabler"... (grin)

But once again, I'd like to point out that _I didn't explicitly ask for this job_. I'm doing it because the mailing list is an essential service to XEmacs users, and the archives are too. Since the guy who was list admin ran out of volunteer time, leaving things in this state, I'm "it".

Understood. The joys of volunteerism. You don't know what's under the carpet until you pull out the broom. You only hope the broom will kill it...

If a conscientious expert sets things up this way, how was I supposed to know? I certainly hope Mailman will _by default_ make it easy for people in my position to do the right thing.

You weren't. Hell, a year ago, NOBODY really knew about this issue. As I say, this is something we're just starting to really get a handle on. It's not something you should have known about -- it's a new monster under the bed. Or maybe an old one we just got a photo of for the first time...

I apologize -- I'm trying not ot beat on you or your mail list. I'm beating on a situation. Of course, since you're currently the drum, that's probably not making you feel better... (really. I'm sorry)

-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.

On Tue, Feb 19, 2002 at 08:52:40AM -0800, Chuq Von Rospach wrote:

On 2/19/02 7:09 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:

...

...

I was wondering how long it would be before someone brought up the case for Lynx. Blind people I had not though about, although I had thought about text based reverse turing tests.

:-)

Lynx access is a really gnarly issue. Lynx usage on my sites has gone from about 4% a couple of years ago, to < 1% these days, from what I've seen. On the other hand, Lynx is the litmus test for sight-limited access tools. If it don't work with lynx, you lock out those with seeing problems (and with a mother who has some macular degeneration, I'm a bit enlightened by those issues. Thank god for Macs and the ability to make font sizes bigger...)

While I'll happily tell the "I don't like cookies" people to get over it,

Well, actually, there are still a couple browsers that don't *do* cookies. 2.8.3, I think, doesn't do persistence, yet.

I'm not sure if GoWeb does or not...

Lynx access isn't something I can or will easily blow off. And something geeks tend not to think of, you start getting into issues of ADA compliance issues, which is a non-trivial issue we haven't even started thinking about here...

Was thinking about that, yes. :-)

...

It's the browser on my wireless handheld, and, in general, it doesn't handle images *at all*. Nor will the microbrowsers on some people's cell phones.

Yup. And while I'd say today it's not a huge issue, 2-3 years down the road, when the version of mailman we're currently noodging over gets into wide usage, it'll be there, and it'll only become more endemic. If you design stuff like this for what's Out There today, by the time it's written, it'll be missing What's Coming...

My outlook exactly. I like to try to keep people honest; it ain't easy.

...

...

So one solution would be to have both public and private archives. The public archives have the email addresses obfuscated in some way, the private archives would not.

Oh. We're talking about *archives*? Silly me. I thought we were talking about maintainer addresses on sign-up pages.

We're talking about both, actually. It's a floor wax and a dessert topping!

You got that backwards, Chuq. :-)

...

It's ASCII text. It's useful. Making it into something else makes it less useful,

But it's the kind of tradeoff we have to consider -- we ARE going to have to give up some stuff in one place to make improvements in another. You aren't going to find a way to better protect the admins without cost in usability somewhere. It's a no-free-lunch situation, or we would have solved it already. The key is to understand the situation and find the most appropriate compromise, because a solution without compromise doesn't seem to exist.

Yeah, cost-benefit analyses are hell, ain't they?

The whole topic is probably going to drve us all plaid...

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

On 2/20/02 9:45 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:

...

While I'll happily tell the "I don't like cookies" people to get over it,

Well, actually, there are still a couple browsers that don't *do* cookies. 2.8.3, I think, doesn't do persistence, yet.

My answer: get a real browser... (grin)

...

geeks tend not to think of, you start getting into issues of ADA compliance issues, which is a non-trivial issue we haven't even started thinking about here...

Was thinking about that, yes. :-)

Yeah. I'd really hate to see Mailman thrown out of, say, all usage in the US government because it's not ADA compliant. If we want to turn Mailman into the replacement defacto standard for majordomo, things like that can't happen.

Yeah, cost-benefit analyses are hell, ain't they?

The whole topic is probably going to drve us all plaid...

Somedays, I think that's all I do any more...

-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.

The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after

On Wed, Feb 20, 2002 at 10:17:58AM -0800, Chuq Von Rospach wrote:

On 2/20/02 9:45 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:

...

...

While I'll happily tell the "I don't like cookies" people to get over it,

Well, actually, there are still a couple browsers that don't *do* cookies. 2.8.3, I think, doesn't do persistence, yet.

My answer: get a real browser... (grin)

On behalf of vt102 lovers everywhere, "Hey!"

...

...

geeks tend not to think of, you start getting into issues of ADA compliance issues, which is a non-trivial issue we haven't even started thinking about here...

Was thinking about that, yes. :-)

Yeah. I'd really hate to see Mailman thrown out of, say, all usage in the US government because it's not ADA compliant. If we want to turn Mailman into the replacement defacto standard for majordomo, things like that can't happen.

Egg-salad point.

...

Yeah, cost-benefit analyses are hell, ain't they?

The whole topic is probably going to drve us all plaid...

Somedays, I think that's all I do any more...

I can't *begin* to imagine why...

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

Have you seen what slashdot is doing? I think it has promise, because while it's still reversible programmatically, it makes it much more difficult to do. Will they still get harvested? Most likely. But not nearly as quickly as most other sites, and it's going to make the spambots crazy trying to eat each page looking to figure out if it knows which obfuscation to de-obfuscate.

What exactly is slashdot doing?

As far as I can see thay are using url/cgi encoding in the email address. This is trivial to circumvent, as is using html entities, or any other reversible scheme.

The use of images for email addresses is the only scheme that will raise the cost of harvesting high enough to make it effectively impossible. You can think of it as either hash-cash for email addresses, or a reverse turing test, depending on your point of view.

On 2/20/02 1:37 PM, "Damien Morton" <dm-temp-310102@nyc.rr.com> wrote:

As far as I can see thay are using url/cgi encoding in the email address. This is trivial to circumvent, as is using html entities, or any other reversible scheme.

With a constantly varying algorithm. So they obfuscate, but they never obfuscate in a predictable way. Which means if you're a spambot, you have to look at every byte of every page and attempt to de-obfuscate it in every possible way to see if it's obfuscated. You CAN do it, but you make it computationally massively expensive.

-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.

No! No! Dead girl, OFF the table!

On 2/20/02 2:13 PM, "John W Baxter" <jwblist@olympus.net> wrote:

At least in Chuq's context, in which Apple claims in their privacy policy to protect the addresses of us innocent subscribers to their lists.

That context may not match the context of other list operators, who may feel that the subscribers are out in the main stacks somewhere. Or in a drawer in the librarian's desk for "suitable" review.

Both true, but I have two points to carry this further.

1. I think a tool like Mailman has to implement to the highest-reasonable security, so if people want to be looser, fine. It's easier to loosen the reins than expect JrandomeUser to implement extra features on an ad hoc basis. I also think a tool like Mailman ought to try to set a "best practices" model for how it operates. Mailman should set the standard for how we think mail lists ought to be run, not be the least common denominator that everyone has to hack extras into to make it fit their needs.

2. admins can set whatever policies they want -- but I think it's important they disclose them, so users can make informed choices. That includes, frankly, letting users know their addresses are potentially exposed to spammers, so if a user is sensitive to this, they can choose to not subscribe, or to leave the list.

I'm not telling admins what their policies need to be, but I do think Mailman needs to understand it's role as a "best practices" tool -- and I do feel strongly that whatever an admin does, they do so in a mode that involves informed consent with their users.

-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/

Someday, we'll look back on this, laugh nervously and change the subject.

On 2/20/02 2:43 PM, "Dale Newfield" <dale@newfield.org> wrote:

(Or a header that can be set to cause a message not to get archived?)

That already exists -- X-No-Archive, which I believe pipermail understands.

-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/

Stress is when you wake up screaming and you realize you haven't fallen asleep yet.

On Wed, Feb 20, 2002 at 01:42:34PM -0800, Chuq Von Rospach wrote:

On 2/20/02 1:18 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:

...

...

And burglary is not caused by my owning nice things, either. It's caused by burglars. But that's no excuse to not put locks on the doors.

A mailing list -- a publically accessible mailing list -- isn't your house. It's the city library. Those are typically not locked up as tightly your house, during the day.

You misread my analogy, or perhaps it's a philsophical disagreement. A

A touch of both, I think.

library is not locked up as tightly as a house, but it also has a person in charge of watching the door to make sure stuff doesn't leave if it's not checked out, and most of them have door sensors now, too.

Stipulated.

And any decent library also has a rare books room, which IS tightly locked up. And while the content of a mail list qualifies as a public library to some degree, the subscriber addresses live in that rare book room.

Hmmm...

...

...

You're right, Jay, but does being right matter? Unless you know how to stop the spammers, it's a pyhrric victory -- because it does nothing to protect yourself from the spammers.

*I* protect *myself* from the spammers, actually, thank you very much.

Perhaps that sounds elitist. So be it.

So, you're saying because you protect yourself from the spammers, that EVERYONE should, too?

As a matter of fact, yes, I am saying that. There are cost-free, not especially difficult to set up, facilities for all environments that will protect you from the major portion of incoming unsolicited commercial email -- some ISP's run then for you, and are *trading* on the fact. So yes, if spam troubles people, they should indeed do something about it.

That's *not* to say that I don't think something should -- and can -- be done at the source, they're two different topics.

To move back to the burglary analogy, you've just told me that (a) if you do get burgled, you won't call the police, and (b), the police department should be shut down, because everyone should take care of themselves. Which, I guess, means if you get burgled, you'll pull out the gun, find the burglar, and shoot him yourself, right?

Actually, yes. Gun control is being able to hit your target. Anyone foolish enough to burgle my house in the middle of the night is running (hopefully knowingly) the risk of getting shot.

Jay, do you see the chaos that causes? You define anarchy, which is, to a degree, what we have in email today, but you then go one step further, and claim that it should be anarchy. My argument is that central tools that CAN do things should do things, because they help a common good -- the difference between a trained police force and a hundred citizens with guns looking for burglars. You get economies of scale that individuals "protecting themselves" can't get, plus, of course, there's nothing keeping you from doing MORE. I just don't understand why you seem to be insisting that because YOU can do it, everyone has to and mailman shouldn't.

Because I've been around long enough -- not that you haven't certainly -- to see the value in the way things are if the tool does *not* circumscribe useful things, and I do not see fit to let the Bad Guys make that utility go away. Aren't we having this argument with John Ashcroft right now about US civil rights?

Mailman's not written for you. It's written for many people with many needs, not all of them as competent in these areas as you. Why force them all to do it your way?

Cause my way is right? :-)

Certainly there are cost benefit analyses to be made here, with many different constituencies' requirements to be considered. And certainly, also, some of these requirements collide head on. That's not surprising.

The customary solution is provide {both,all the} options, and document the costs and benefits, try to choose a sane default, and let the operators decide. I'm sure that is what will happen here, too.

But I won't let that keep me from stumping for the approach I think is best, by any means. And if my approach seems impractical because of "the way the world is", well, how do we think other changes to make the world better have come about..?

...

Well, again: would you deadbolt the public library?

See above. You don't get the analogy right.

No, I merely don't value the email address's privacy as highly as you do. I get about 50 spam a day in 200 new messages including about 14 mailing lists -- I'm entitled to hold that opinion if I want.

You *can't* make addresses overly private; they cease to be usable.

At least, given the supporting tools and infrastructure we have today.

...

When I send a complaint to someone about something, *I want a copy of that message in my outbox*. I *hate* mail forms. With an unbridled, flaming passion. They usually don't spell check; they don't get my sig file, etc, etc, ad nauseum.

That's nice. But -- does that override the need to protect the admin from spammers? Again, do we only do things that you approve of, or for the common good, is this something where you compromise your position?

The admin works for me. Not the other way around.

Apologies if you think that sounds snotty or self-important. I expect people who stick their head up outof the foxhole (or, indeed, travel in questionable areas) to wear a helmet, yes.

See, my problem here is that you seem to have defined "no good" as "I don't like it". Your view is one, but not the only one. And you don't seem to be looking at mailman as a global tool, but mailman as your tool.

I'm sorry you think that way about what I'm saying. I'm trying to explain my motivations for having these opinions; I gather I'm not succeeding.

...

Personally, I'm a little tired of "But I'm too lazy" (to learn how to set up spam filters) being an acceptable excuse. If you can't find someone to run your list with a clue, then maybe you shouldn't have a list.

Personally, I find that attitude quite arrogant. Not everyone is you, or wants to be you. Or me. Or Barry. If you want to design things for you, do whatever you want. When you start designing for an open population, you have to start checking the ego at the door. This attitude, I'm afraid, doesn't, at least in my mind.

Again, apologies. If you can convince me that one Right outweighs the other one, for a sufficiently statistically significant number of possible cases, I'll change my outlook. I don't claim to be perfect.

But I don't form my opinions for fun, nor in total ignorance. And I *have* been doing this for 18 years.

No, 19.

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

On Wed, Feb 20, 2002 at 06:58:33PM -0500, Damien Morton wrote:

Anyone have any idea how I set X-No-archive on all emails being sent to a mailman list?

Im using Outlook 2002. As far as I know there is no ability to access internet headers in Outlook 2002 without the use of unusual COM objects to get at extended MAPI properties.

First, get a real email program. :-)

Secondly, if Piper implements this the same way that Google does, you can put it in as the first line of the body, starting in column 1, followed by an (additional) blank line, and it will still take effect.

Of course, it's pretty much immaterial, since if someome quotes you, *their* message may not have the header.

Are we beginning to understand the scope of this issue? :-)_

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

On Wed, Feb 20, 2002 at 06:49:53PM -0800, Chuq Von Rospach wrote:

On 2/20/02 5:36 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:

...

...

So, you're saying because you protect yourself from the spammers, that EVERYONE should, too?

As a matter of fact, yes, I am saying that. There are cost-free, not especially difficult to set up, facilities for all environments

Okay, what system exists for AOL users? How do you set up a system if you live on a corporate account with an imap mail box and no shell access to the server? What about a hotmail or yahoo account?

Show me the systems, jay, that work for real people, not us geeks that run our own boxes on our own desks.

Volvos are very safe, Toyotas are in the middle, sand rails are *just not safe at all*.

The risks are easy to discover for each category, and the same is true for choosing an email service. I overstated *slightly* in saying "all" environments; let me rephrase it:

For any given business or personal environment, a solution exists to be chosen which permits the filtering of unwanted mail. People can choose this solution, or they can choose others.

In the corporate situation, the responsible party is the MIS department, for whom this freedom of choice also exists.

Hotmail and Yahoo are jokes. They're free; you take what you're paying for.

As for IMAP, the Bat will filter just fine, thanks.

...

...

To move back to the burglary analogy, you've just told me that (a) if you do get burgled, you won't call the police, and (b), the police department should be shut down, because everyone should take care of themselves. Which, I guess, means if you get burgled, you'll pull out the gun, find the burglar, and shoot him yourself, right?

Actually, yes. Gun control is being able to hit your target. Anyone foolish enough to burgle my house in the middle of the night is running (hopefully knowingly) the risk of getting shot.

Only if you're home. And if he's IN your home, be my guest. But your analogy implies that you don't believe in the police, you believe in hunting him down and shooting him whenever you find him. Once you leave the confines of your property, your rights change radically here.

Certainly.

...

Because I've been around long enough -- not that you haven't certainly -- to see the value in the way things are if the tool does *not* circumscribe useful things, and I do not see fit to let the Bad Guys make that utility go away. Aren't we having this argument with John Ashcroft right now about US civil rights?

We? No, actually.

Ok.

*Lots* of people are having that argument with the AG, and I'm one of them.

...

Cause my way is right? :-)

Nope. Don't buy that. Especially for all those list admins in the three cases I gave you above. Once you solve THOSE problems, though, maybe we can start to talk. I'm really curious how you'll solve the problem of my mother doing her own anti-spam processing on her earthlink account. Because if you can't solve that problem, or the AOL problem -- you can't solve the problem, except for us geeks, and we can't write Mailman just for geeks.

Spaminator. You picked precisely the example I had in mind. If the masses *demand* solutions, those solutions *will* happen.

See, that's the other failure of your analogy. You assume everyone WANTS to have a gun and hunt down their own burglar. The vast majority of the public doesn't. They want to call the police.

Hmmm...

...

No, I merely don't value the email address's privacy as highly as you do.

Fair enough. But I think that disqualifies you from making design decisions about privacy issues then. It's Barry's call, but I'd argue that you take a position that is unacceptable in the design of this software for these issue.

See *all* my other commentary on the specific topic of "design decisions for Mailman"; I'm sure Barry will chime in here sometime soon...

...

...

That's nice. But -- does that override the need to protect the admin from spammers? Again, do we only do things that you approve of, or for the common good, is this something where you compromise your position?

The admin works for me. Not the other way around.

Apologies if you think that sounds snotty or self-important.

Yes, it does.

...

Again, apologies. If you can convince me that one Right outweighs the other one, for a sufficiently statistically significant number of possible cases, I'll change my outlook. I don't claim to be perfect.

Solve the problem for real users (the AOL account. The corporate IMAP account. The earthlink account. The hotmail account) and then maybe we'll talk. Until then, your solution only works for geeks, and is unacceptable for a tool designed to be used by regular people, not JUST geeks.

See above: no, some of those cases (specifically Yahoo and Hotmail) are in fact insoluble, but that's *Hotmail* and *Yahoo's* fault, and their user's problem. AOL needs to solve it's own problem -- they've made the bed, their users are laying in it. Deals with the devil never work out well.

But perhaps the availability of things like Earthlink and the Mindspring Spaminator will realign the playing field on that point -- Earthlink certainly appears to think so, given what they're spending on ads this year.

The IMAP account solution I've mentioned already.

And as for Earthlink, well... see above. :-)

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

...

...

...

...

"Chuq" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

Chuq> On 2/20/02 1:37 PM, "Damien Morton"
Chuq> <dm-temp-310102@nyc.rr.com> wrote:
>> As far as I can see thay are using url/cgi encoding in the
>> email address. This is trivial to circumvent, as is using html
>> entities, or any other reversible scheme.

Chuq> With a constantly varying algorithm. So they obfuscate, but
Chuq> they never obfuscate in a predictable way. Which means if
Chuq> you're a spambot, you have to look at every byte of every
Chuq> page and attempt to de-obfuscate it in every possible way to
Chuq> see if it's obfuscated. You CAN do it, but you make it
Chuq> computationally massively expensive.

Er, last I heard "massively expensive" ~ "exponential". This is O(n*m) where _n_ is the number of bytes and _m_ is the number of obfuscations, and _m_ is bounded by user patience.

Nor do the spammers need to deobfuscate all the obfuscations. They only need enough that they're getting a reasonable harvest rate. But the people who post to /. etc tend to be repeat offenders, and the obfuscation is random. So we lose as soon as the amount of address content obfuscated in this way becomes noticable.

And maybe before that, as many spammers seem to take address-hiding as a personal offense, in the same way that crackers view passwords.

-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

At 20:36 -0500 2/20/2002, Jay R. Ashworth wrote: [Quoting Chuq]

...

See above. You don't get the analogy right.

[Jay]

No, I merely don't value the email address's privacy as highly as you do. I get about 50 spam a day in 200 new messages including about 14 mailing lists -- I'm entitled to hold that opinion if I want.

You *can't* make addresses overly private; they cease to be usable.

At least, given the supporting tools and infrastructure we have today.

I have a domain, for no particularly good reason. (I saw the word in a book ad in Science News...I bought the book and the domain based on the ad. And since "you could look it up" it's scandaroon.com.)

Once I had the domain, I started registering each product (or company's products) with a unique local part @scandaroon.com. Late last year, I had a sudden infusion of Spam addressed to jwbpalm@scandaroon.com. [Company shall remain nameless ;-)] Sending mail to that address now produces a 550 response whose text is "sold down the river by Palm" (Which might be wrong...they might have leaked it instead...which IMHO is worse.) Palm is probably following the privacy policy as it has evolved since I registered the (early production) Palm IIIx.

For Usenet posting, I use an @spamcop.net address...the harvesters don't seem to bother with those...no obfuscation seems to be needed. (And yes, I get to deal with "our" SpamCop reports, but for THIS purpose the service works very well.)

Scrambling quickly back on topic: some list admins could do well to try a SpamCop address--or the like elsewhere--for list admin purposes for Mailman lists.

--John

-- John Baxter jwblist@olympus.net Port Ludlow, WA, USA

...

...

...

...

"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

>> (Or a header that can be set to cause a message not to get
>> archived?)

CVR> That already exists -- X-No-Archive, which I believe
CVR> pipermail understands.

Mailman's interface to Pipermail is what does this check, currently defined as:

X-No-Archive: yes
X-Archive: no

prevents the message from being archived in any way. I don't think there are standards for this particular header (else, why would it be an X- header?), so I'm wondering if I understand common practice well enough. I.e. should the presence of X-No-Archive: itself, regardless of value, prevent archiving of the message?

-Barry

...

...

...

...

"JRA" == Jay R Ashworth <jra@baylink.com> writes:

JRA> Spaminator.  You picked precisely the example I had in mind.
JRA> If the masses *demand* solutions, those solutions *will*
JRA> happen.

I tend to agree that the big ISPs will be forced by their users to put up their own spam prevention solutions. If the Earthlink ads are any indication, such tools will in fact be major marketing positions. I'd actually be surprised if any major ISP wasn't actively spam filtering for their customers.

That doesn't help the little guy like me who runs my own domain and tools and spends a 1/2 hour (or more) every morning just deleting spam, even while on vacation. :) And no itch is as persistent and annoying as my own.

Having said that, there's still no reason why Mailman can't and shouldn't do better, except perhaps for lack of resources <wink>. I'll follow up shortly with some other thoughts in this thread.

-Barry

On Mon, Feb 25, 2002 at 10:09:35AM -0500, Barry A. Warsaw wrote:

Mailman's interface to Pipermail is what does this check, currently defined as:

X-No-Archive: yes
X-Archive: no

prevents the message from being archived in any way. I don't think there are standards for this particular header (else, why would it be an X- header?), so I'm wondering if I understand common practice well enough. I.e. should the presence of X-No-Archive: itself, regardless of value, prevent archiving of the message?

This depends on which side of the "enabler" argument, discussed ad nauseum last week, you come down on. :-)

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

On 2/25/02 8:56 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:

That said, my normal daily mail load is almost 300 these days, including 9 mailing lists, and my spamcount is about 15; I deal with them in about 2 minutes; and that's with *no* automated de-spamming, and about 200 posts a week to Usenet in 12 different groups.

I guess I'm just lucky.

Yes, you are. You don't want to know how much mail I get (but I'm subscribed to every list my sites manage plus most of the -admin addresses to same, but my assistant gets first crack at those now...). I have lists that get 15 spam attacks a day now. I woke up to 27 pieces of spam in my personal mailbox, and that's just one address, and since midnight.

I also do almost not automated de-spamming at this point, other than basic sendmail relay checks and the like. I'll probably do more some day (at Apple, we use brightmail on the main mail systems, and I'd like to cloak the list servers on it as well; at home, once I upgrade the server to MacOS X, upgrade the MTA to Postfix and generally replace everything under the hood, I'm looking at spamassassin. But it makes no sense to do the work before the ugprade and move it...)

I think you do have a light spam load for someone with a public presence, Jay. Especially on usenet. Do you obfuscate your usenet address?

-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/

The first rule of holes: If you are in one, stop digging.

...

...

...

...

"JRA" == Jay R Ashworth <jra@baylink.com> writes:

>> Mailman's interface to Pipermail is what does this check,
>> currently defined as: X-No-Archive: yes X-Archive: no prevents
>> the message from being archived in any way.  I don't think
>> there are standards for this particular header (else, why would
>> it be an X- header?), so I'm wondering if I understand common
>> practice well enough.  I.e. should the presence of
>> X-No-Archive: itself, regardless of value, prevent archiving of
>> the message?

JRA> This depends on which side of the "enabler" argument,
JRA> discussed ad nauseum last week, you come down on.  :-)

For this particular issue, I'm happy to make it really easy for folks to make sure their article is not archived, even though I hope most people won't avail themselves of this (it harms public discourse). I can't imagine any other useful value for X-No-Archive: though, so I tend to think the value should be ignored.

-Barry

On Mon, Feb 25, 2002 at 12:32:44PM -0500, Barry A. Warsaw wrote:

>> practice well enough.  I.e. should the presence of
>> X-No-Archive: itself, regardless of value, prevent archiving of
>> the message?

JRA> This depends on which side of the "enabler" argument,
JRA> discussed ad nauseum last week, you come down on.  :-)

For this particular issue, I'm happy to make it really easy for folks to make sure their article is not archived, even though I hope most people won't avail themselves of this (it harms public discourse). I can't imagine any other useful value for X-No-Archive: though, so I tend to think the value should be ignored.

And worse, when people *quote* you, it doesn't track; I tend to think it's worse than useless (in the false sense of security sense) myself, but in for a penny, in for a pound, I guess... yeah, I'd ignore the argument.

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

On 2/25/02 10:03 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:

...

spam attacks a day now. I woke up to 27 pieces of spam in my personal mailbox, and that's just one address, and since midnight.

Eek.

Yeah, but that's still a small percentage compared to legitimate mail.

It's all over my weblog, too; not obfucsated there, either.

I don't obfuscate either. <digression> I decided long ago not to let the spammers get to my head. I'm just not that sensitive to it. I realize, though, that others feel differently -- I just don't see that the amount of time some folks put into dealing with spam is worth the investment. Part of the reason I get so much spam is that "chuqui" (I own chuqui.com) is the nickname of the largest open pit copper mine in the world, down in chile. So I get a lot of spanish language spam misdirected at that place...

I'm of the opinion "when you start spending more time fighting spam than you do simply deleting it, the spammers are winning". Spam doesn't cost me money (please, let's not get into the bandwidth-wars -- I'm on a fixed-price network with spare capacity), it costs me time. And time, in my life, is my most precious commodity. I've also found you don't stop spam, you maybe slow it down for a while, so it's a war of attrition. I decided a while back it was less hassle to just blow through it, since most spam you can delete just from the subject line.

But if you'll note, that's not the policy I propose for Mailman. I feel my approach works for me -- but is too laissez-faire for Mailman. A public tool like that needs to be more protective, even if I personally feel I can do with less. </digression>

Barry's overview this morning of what he's doing seems fine to me. I might quibble with some details, but I think it's reasonable. I especially agree with him about list admins needing some public face, not an anonymous voice from behind the curtain. That's explicitly why I admin from my address, not a generic postmaster box. And even though I now have a 2nd helping out and we use a shared mailbox, I still respond as me, not as A Generic Apple Postmaster.

Frankly, sometimes it causes problems, because some folks see you as a target. But I find humanizing it generally solves more problems than it causes. It's a lot easier to throw pitchforks at the abuse@ address, since you don't know who that is...

And my pain level *still* hasn't climbed high enough to merit automated methods (read: higher than the pain level of learning procmail. ;-)

Oh, heck. Procmail is the hard part, IMHO. What a bizarre, bogus syntax.

I really, really like Barry's idea of an API for integrating into things like SpamAssassin and auto-adminning based on the returned score. That's the sort of thinking we ought to be looking at. Not implementing it all ourselves, but finding ways to take advantage of what others are doing as well.

-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/

No! No! Dead girl, OFF the table!

On 2/25/02 6:38 PM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

BAW> 5) list rosters

I don't know of any lists where these are available to the members, let alone the public.

You know, now that I think about it. Wihle I think Mailman now has this turned off by default (does it? If not, it should...), perhaps it's time to just make the option dead and buried, so that naïve list admins don't have the ability to open it up any more...

-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/

The first rule of holes: If you are in one, stop digging.

...

...

...

...

"John" == John Morton <jwm@plain.co.nz> writes:

John> I find this feature is handy for small, private lists.

Sure. I have a couple that could be handled that way, but we just defaulted them all off. We post the names and addresses (they're basically lists of project staff) on the home page, with mailtos and fancy formatting, instead. When the staff forget who handles what, they use that interface, just like the clients do. (It's voluntary, they are warned about harvesting; nobody has refused yet.)

John> I'd rather it was still around and just disabled by default
John> with warning stickers all over it than we dumb down mailman

To me, it's not really an issue of dumbing down. It would be easy enough to do this with a separate app, so the question is "should a deprecated feature continue to encruft MM?"

-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

You can argue that "barry at zope.com" isn't obfuscated enough, and you might be right. I'm against any image or JavaScript approach to protecting these because I really do want to keep Mailman's web interface as pedestrian as possible. In principle I don't mind if JavaScript or images are used, but they should never be the only way to navigate a Mailman site. Mailman must degrade gracefully for browsers that either don't support these features or have them disabled. I'd do the same with cookies if I could figure out how to do low-frustration-factor authentication without them.

...

...

...

...

"JRA" == Jay R Ashworth <jra@baylink.com> writes:

JRA> And, of course, if it *will* degrade, then address-snarfers
JRA> will figure out how to *make* it degrade, so it's not worth
JRA> doing in the first place, at least not for *that* reason.

Agreed.

MM3 will likely integrate admin addresses and list memberships into an object called a "roster" (essentially just a list of email addresses). This will let us define a pipeline for each roster, which could include a spam filter that performs an action based on some criteria (e.g. drop it, reject it, mark a header, etc.). So we can do more protection on the -owner address than we can do now (without hacking).

JRA> I do see one problem here, and I don't know if you already
JRA> address it below.  [ looks ] You don't; it's this: if the
JRA> list-owner addresses go through the MM machinery, as well,
JRA> then they too can die if MM crashes the wrong way.

JRA> This implies, as I believe has already been discussed, that
JRA> the *server* admin address must be publicly accessible, not
JRA> be piped into MailMan at all, and preferably, should actually
JRA> not even be handled by the same machine...  ("Single point of
JRA> failure")

Well, what machine it's handled by isn't Mailman's business, but you do have a point. Until recently, I recommended that you install aliases mailman' and mailman-owner', but now I recommend that `mailman' be an actual list, and it is from this list that things like password reminders look to come from. Also, if the site list gets a bounce, it'll check all the existing lists for a match against the bouncing address.

You make the valid point that if the Mailman system were to break, you'd have no way to contact the site administrator, save for typical aliases like postmaster. It seems like you want:

• A non-list, plain alias to contact the human in case of emergency

• Some place that password reminders come from. Since this will be receiving bounces, it ought to be a real list.

• A site-wide list of maintainers of the site who can take care of normal operations (i.e. panicky unsubscription requests).

Perhaps #3 can be the same as #1 for those sites that have a collaborative management arrangement. So the question is, what do we call the alias and what do we call the list? I have definitely seen people try to send mail commands to `mailman@python.org' and from my Majordomo days, this seems like a reasonable thing to (eventually) implement. Is it sufficient to recommend that postmaster@ point to a real human, not a list, and leave mailman@dom.ain a normal list?

If not, i'd still opt for `mailman' to be the site list, and add something like mailman-panic to be a human address. Or perhaps make mailman-owner pipe both to the wrapper and to postmaster. I dunno, I'm open to suggestions.

Mailman should avoid getting deeply into the spam detection and prevention business, except for some really really basic stuff (probably not much more or less than it does now). It should integrate well with external spam detection programs like SpamAssassin or commercial equivalents. E.g. if we always send the message through SA, and the message gets some score, we could decide to hold messages below say 5.0 on the Spamster Scale, discard anything about 5.0, etc.

JRA> That sounds good, and if there isn't already a "plugin" API
JRA> for that, we ought to give some thought to that...

Agreed. I just have no idea what a reasonable API would be, although we're planning on doing some experiments with SA on {python,zope}.org to see what might make sense.

#4 is interesting too. I'm not against putting the raw archive behind a turing-test, since I suspect that very few people will ever want it. It means that we won't be able to write an automated wget-ish script to do off-site backups, but so be it.

JRA> Is there a difference between raw and private that I'm
JRA> missing?  Do you mean the mbox format files?

Yup. raw == mbox.

• Someone needs to step up and "own" Pipermail if any of these problems are going to be fixed, or if the obfuscation is going to happen.

JRA> Not much danger of that, is there?

Not so far. :(

• Remember that Pipermail itself is completely optional. An API is defined between Mailman and the archiver and that's all the interaction they have. Maybe the API needs to be more elaborate to support obfuscation. It definitely needs some changes if we ever want to add some of the features I'd like to add (but that's off-topic here).

JRA> Well, that's probably the best point yet: this isn't
JRA> *MailMan's* problem, except to the extent that we "recommend"
JRA> Piper as out archiver.

I don't know if I recommend it, in fact I try to dis-recommend it. Still, I think we do more good than harm in distributing an archiver that works out of the box. And the advantage of Pipermail is that for really really critical problems, we /can/ go in and hack on it. I'm torn, but still come down on the side of including Pipermail, even with all its worts.

• I'll note that one of the early design decisions for Pipermail was that public archives should be vended directly from the file system for performance reasons. That decision may not be appropriate for today's operations. Certainly maintaining two static versions of the pages isn't feasible, so I think you have to vend one or the other (probably the obfuscated version) from a cgi.

JRA> No, but the performance reasons aren't as much of an issue
JRA> now...

Nope.

-Barry

...

...

...

...

"SJT" == Stephen J Turnbull <stephen@xemacs.org> writes:

SJT> To me, it's not really an issue of dumbing down.  It would be
SJT> easy enough to do this with a separate app, so the question
SJT> is "should a deprecated feature continue to encruft MM?"

I'm not sure I'm ready to deprecate the roster until we can come up with a simple recipe for people to unsubscribe themselves unambiguously via the web. Right now I say:

• Go to the listinfo page for this list

• Click on "Visit Subscriber List"

• Find your address, click on it.

• Click on "Unsubscribe".

Unless they know what address they're subscribed with, anything else involves a bunch of fumbling.

-Barry

...

...

...

...

"BAW" == Barry A Warsaw <barry@zope.com> writes:

BAW> Yeah, it's just that I generally hate cookies too.

So call them [Kerberos] "tickets". (Me like cookies, one, two, I put them away now. Tickets have no flavor and are hard to chew.) You aren't going to make cookies go away, because they really really do constitute a service to the browsing public.

This is a generic problem on the 'net. Making the 'net work for you most effectively requires that you carry a persona with you, whether you call that "cookie", "ticket", "published email address", or "shopping cart". This necessarily conflicts with privacy.

One may hope that Mailman's specific set of solutions can contribute to that broader set of issues.

BAW> If you only knew, you might be horrified.

Naw. I'm an economist in Japan. Beyond horror.

-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

From: Barry A. Warsaw

...

...

...

...

...

"SJT" == Stephen J Turnbull <stephen@xemacs.org> writes:

SJT> You aren't going to make cookies go away, because they really
SJT> really do constitute a service to the browsing public.

I've given up on the anti-cookie rants, for the most part. I still haven't given up my rage against JavaScript or Java, but I get derided daily by my Pythonlabs counterparts for it. :)

You could always use Basic Authentication, with authentication being done by the cgi scripts against the membership list (emailaddress,password) rather than the webserver. As far as I can tell, this operates somewhat like a cookie in that identifying information is handed to the server on every request.

On 2/25/02 10:08 PM, "Barry A. Warsaw" <barry@zope.com> wrote:

The problem is that I suspect it makes it much harder for a person to find their user account and get themselves unsubscribed. Without the roster, they have to know the address they're subscribed with to get anywhere. And lots of people don't.

Do users actually look themselves up? To be blunt about it, as far as I can tell, they simply email the admin and say "help me!". Is this a real issue any more? Not to me, it's not. The exposure risk is worth a couple of extra help requests to the admin -- and I doubt any significant group of users actually look themselves up any more.

-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/

He doesn't have ulcers, but he's a carrier.

--- "Barry A. Warsaw" <barry@zope.com> wrote:

...

...

...

...

...

"DM" == Damien Morton <dm-temp-310102@nyc.rr.com> writes:

DM> You could always use Basic Authentication, with authentication
DM> being done by the cgi scripts against the membership list
DM> (emailaddress,password) rather than the webserver. As far as I
DM> can tell, this operates somewhat like a cookie in that
DM> identifying information is handed to the server on every
DM> request.

Yeah, except that AFAICT, basic auth is broken in that you can't re-authenticate yourself or un-authenticate yourself. I.e. you need to do `Logout', especially when you're debugging the admin interfaces. ;)

I believe there is a way to to do logout; it involves sending another 401 header to the client, which causes the browser to think it now has the wrong password and forget it. apologies for being fuzzy on the details.

While I'm on the topic.... http://www.apple.com/downloads/macosx/system_disk_utilities/spamstopper.html

That utility translates all the characters in an email address to character entities, something spambots aren't likely to pick up on. for now, anyway.

i.e. mailman could incorporate something like this.

Paul

Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com

On Tuesday 26 February 2002 02:14 am, you wrote:

On 2/25/02 10:05 PM, "Barry A. Warsaw" <barry@zope.com> wrote:

...

I'm not sure I'm ready to deprecate the roster until we can come up with a simple recipe for people to unsubscribe themselves unambiguously via the web.

If you go to VERP (or more correctly, customized email), you can set up the footer of each message to include a URL to take them right ot the unsub page. Or then mimic lyris with a "you are subscribed as" in the footer.

Actually, this 'you are subscribed as' is a good idea anyway. When people subscribe under one address and it goes through a couple of forwarding mailboxes that mung the headers and then dies, it's difficult to tell what the original subscriber name was sometime. This would alleviate that.

I have a list right now that has this problem and I've yet to figure out which subscriber is causing the problem.

On Tue, Feb 26, 2002 at 12:56:45AM -0500, Barry A. Warsaw wrote:

JRA> I do see one problem here, and I don't know if you already
JRA> address it below.  [ looks ] You don't; it's this: if the
JRA> list-owner addresses go through the MM machinery, as well,
JRA> then they too can die if MM crashes the wrong way.

JRA> This implies, as I believe has already been discussed, that
JRA> the *server* admin address must be publicly accessible, not
JRA> be piped into MailMan at all, and preferably, should actually
JRA> not even be handled by the same machine...  ("Single point of
JRA> failure")

Well, what machine it's handled by isn't Mailman's business, but you do have a point. Until recently, I recommended that you install aliases mailman' and mailman-owner', but now I recommend that `mailman' be an actual list, and it is from this list that things like password reminders look to come from. Also, if the site list gets a bounce, it'll check all the existing lists for a match against the bouncing address.

Hmmm...

You make the valid point that if the Mailman system were to break, you'd have no way to contact the site administrator, save for typical aliases like postmaster. It seems like you want:

• A non-list, plain alias to contact the human in case of emergency

Yep; and it's fine if this is an alias; I agree with Chuq's opinion about 'Real people", but I don't mind *sending* to a role account, as long as the *reply* comes from a human, with a .sig file.

• Some place that password reminders come from. Since this will be receiving bounces, it ought to be a real list.

Yeah, probably.

• A site-wide list of maintainers of the site who can take care of normal operations (i.e. panicky unsubscription requests).

Perhaps #3 can be the same as #1 for those sites that have a collaborative management arrangement. So the question is, what do we call the alias and what do we call the list? I have definitely seen people try to send mail commands to `mailman@python.org' and from my Majordomo days, this seems like a reasonable thing to (eventually) implement. Is it sufficient to recommend that postmaster@ point to a real human, not a list, and leave mailman@dom.ain a normal list?

Hmmm... I see the problem: mailman is the obvious alias for the server admin, but I also see why you want to leave it a list.

*I* think that postmaster@ the mailing list machine (or domain) is a good enough answer, but I think Chuq will accuse me of geeking out again, and on this one, I'm afraid I'd agree with him.

The number of people on the net with *no* indoctrination at all is truly stunning.

If not, i'd still opt for `mailman' to be the site list, and add something like mailman-panic to be a human address. Or perhaps make mailman-owner pipe both to the wrapper and to postmaster. I dunno, I'm open to suggestions.

Well, here's the problem: it has to be predictable, because

1. you can't put in every mail footer cause you don't *want* people using it unless something goes Horribly Wrong, but

2. if something *does* go Horribly Wrong, they won't be *able* to get it from the website...

...

Mailman should avoid getting deeply into the spam detection and prevention business, except for some really really basic stuff (probably not much more or less than it does now). It should integrate well with external spam detection programs like SpamAssassin or commercial equivalents. E.g. if we always send the message through SA, and the message gets some score, we could decide to hold messages below say 5.0 on the Spamster Scale, discard anything about 5.0, etc.

JRA> That sounds good, and if there isn't already a "plugin" API
JRA> for that, we ought to give some thought to that...

Agreed. I just have no idea what a reasonable API would be, although we're planning on doing some experiments with SA on {python,zope}.org to see what might make sense.

I suspect that, at least for Unixy installs, a system call to the appropriate binary, with percentized arguments, will fill the bill nicely; you can catch the exit value -- and if your package doesn't do it that way, you can write a script to parse the output and send a return value.

I, personally, would re-read the message from the file I put it in, in case someone's package (wants to) rewrite the MIME to remove and quarantine suspicious attachments.

...

#4 is interesting too. I'm not against putting the raw archive behind a turing-test, since I suspect that very few people will ever want it. It means that we won't be able to write an automated wget-ish script to do off-site backups, but so be it.

JRA> Is there a difference between raw and private that I'm
JRA> missing?  Do you mean the mbox format files?

Yup. raw == mbox.

Ok. I've often found it quite useful to snarf those down for lists I'm not on (yet); I wouldn't mind having to prove I was human, though.

My real problem was just that the obfuscation breaks Google, and since "Get the glue right" is one of my loudest systems-design mantras...

JRA> Well, that's probably the best point yet: this isn't
JRA> *MailMan's* problem, except to the extent that we "recommend"
JRA> Piper as out archiver.

I don't know if I recommend it, in fact I try to dis-recommend it.

Sounds like a good call to me...

Still, I think we do more good than harm in distributing an archiver that works out of the box. And the advantage of Pipermail is that for really really critical problems, we /can/ go in and hack on it. I'm torn, but still come down on the side of including Pipermail, even with all its worts.

Until Zest is a solution...

...

• I'll note that one of the early design decisions for Pipermail was that public archives should be vended directly from the file system for performance reasons. That decision may not be appropriate for today's operations. Certainly maintaining two static versions of the pages isn't feasible, so I think you have to vend one or the other (probably the obfuscated version) from a cgi.

JRA> No, but the performance reasons aren't as much of an issue
JRA> now...

Nope.

Optimizing for performance in the core design of a system is nearly always a bad idea, at least on this end of the performance curve.

If you're redesigning Amadeus, or SABRE; perhaps not.

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

...

...

...

...

"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

>> The problem is that I suspect it makes it much harder for a
>> person to find their user account and get themselves
>> unsubscribed.  Without the roster, they have to know the
>> address they're subscribed with to get anywhere.  And lots of
>> people don't.

CVR> Do users actually look themselves up? To be blunt about it,
CVR> as far as I can tell, they simply email the admin and say
CVR> "help me!". Is this a real issue any more? Not to me, it's
CVR> not. The exposure risk is worth a couple of extra help
CVR> requests to the admin -- and I doubt any significant group of
CVR> users actually look themselves up any more.

I'm willing to change the default roster view to list-members-only.

-Barry

At 12:36 -0500 2/26/2002, Jay R. Ashworth wrote:

*I* think that postmaster@ the mailing list machine (or domain) is a good enough answer, but I think Chuq will accuse me of geeking out again, and on this one, I'm afraid I'd agree with him.

The number of people on the net with *no* indoctrination at all is truly stunning.

Earthlink seems to think that postmaster@ should be a synonym for abuse@, and that a robot should scan the incoming message and say "nothing here seems like abuse of an Earthlink account...go away". And all I was trying to do was tell them "hey, in the odd moments when I can actually use the POP server, I've gotten a dozen Welcome messages for other users, 4 invoices for other users, two responses from support robots destined for other users which about said other users having similar problems." The robot is right...no abuse there. ;-(

With that kind of training, no one will find the postmaster@ address.

--John

-- John Baxter jwblist@olympus.net Port Ludlow, WA, USA

...

...

...

...

"PB" == Phil Barnett <midnight@the-oasis.net> writes:

PB> Actually, this 'you are subscribed as' is a good idea
PB> anyway. When people subscribe under one address and it goes
PB> through a couple of forwarding mailboxes that mung the headers
PB> and then dies, it's difficult to tell what the original
PB> subscriber name was sometime. This would alleviate that.

PB> I have a list right now that has this problem and I've yet to
PB> figure out which subscriber is causing the problem.

Again, another of the wonderful things you can do if you turn on personalized email and don't mind the extra resources that consumes. The additional substitution variable is `user_address'.

time-machine-again-ly y'rs, -Barry

...

...

...

...

"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

CVR> So just be aware -- if you create a server-wide "list", you
CVR> may well be creating a point of conflict, based on my
CVR> experience. And it wasn't a situation where, at least for
CVR> those users, "if you subscribe to a list on this site, you
CVR> have to get this" was an acceptable answer to these people.
CVR> So instead of getting a message once, they get it four or
CVR> five times, and since they come in the name of the list they
CVR> subscribed to, evidently that's okay.

CVR> Go figure. But be wary here, Barry. My experience doing
CVR> something very similar was horrible.

Actually, we're no worse off than we were before, in fact, it should now be better. How many messages have /you/ gotten from people receiving the password reminder from a list they never heard of? Remember that 2.0.x just picked the first public list at random (well, lexically sorted) and used /that/ for the origin of the reminder. That's so obviously broken that it had to be fixed.

-Barry

On Tue, Feb 26, 2002 at 07:40:20PM -0500, Barry A. Warsaw wrote:

Actually, we're no worse off than we were before, in fact, it should now be better. How many messages have /you/ gotten from people receiving the password reminder from a list they never heard of?

The funny thing is that I've gotten lots of hate mail saying "how do you dare sending my my mailman password in cleartext. STOP THIS NOW!!!", but not one "why did this come from test-admin@lists.sf.net" :-)

That said, I very much welcome the new option in 2.1.

Am I to understand however that the sitewide list doesn't have to be a list and can be a mail alias instead?

Marc

Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking

Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key

On Tue, Feb 26, 2002 at 08:03:14PM -0500, Barry A. Warsaw wrote:

MM> The funny thing is that I've gotten lots of hate mail saying
MM> "how do you dare sending my my mailman password in
MM> cleartext. STOP THIS NOW!!!", but not one "why did this come
MM> from test-admin@lists.sf.net" :-)

MM> That said, I very much welcome the new option in 2.1.

And of course, in MM2.1 they can turn their password reminders off entirely.

Yes, I was very relieved when that feature appeared :-)

MM> Am I to understand however that the sitewide list doesn't have
MM> to be a list and can be a mail alias instead?

No, as it stands in cvs, it has to be a list.

Not that it is a big deal to me, but out of curiosity: what part of mailman cares that it's a list and not a mail alias? Does mailman act on the bounces sent back to the envelope from when it sends password reminders?

Marc

Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking

Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key

I find it very rare that anybody actually responds to postmaster@ addressed email. I suspect that for most sites, nobody reads them.

Hmmm...could that be why other admins seem surprised when I answer? ;-)

--John

John Baxter jwblist@olympus.net Port Ludlow, WA, USA

On Tue, Feb 26, 2002 at 07:38:08PM -0500, Barry A. Warsaw wrote:

...

...

...

...

...

"JWB" == John W Baxter <jwblist@olympus.net> writes:

JWB> With that kind of training, no one will find the postmaster@
JWB> address.

I find it very rare that anybody actually responds to postmaster@ addressed email. I suspect that for most sites, nobody reads them.

Well, *my* domains comply with the RFC. I don't actually *get* a lot of postmaster mail, though.

I think I'm coming down on the side that mailman@ should be a tee, one to the list machinery and another to a Real Human.

Yeah, that would work, too.

Cheers,

• jra

  Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

  "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

On 2/27/02 1:40 AM, "Nigel Metheringham" <Nigel.Metheringham@dev.InTechnology.co.uk> wrote:

On Tue, 2002-02-26 at 19:43, Barry A. Warsaw wrote:

...

I'm willing to change the default roster view to list-members-only.

For those within the EU*, the only correct setting is for the list admin only to be able to see the roster.

Oh, good point. I'd forgotten that.

• ie those with EU data protection legislation affecting them.

FWIW, at Apple, our corporate policy is to manage to the EU standards globally, because of the nature of the internet.

-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/

Yes, I am an agent of Satan, but my duties are largely ceremonial.

...

...

...

...

"MM" == Marc MERLIN <marc_news@vasoftware.com> writes:

MM> Not that it is a big deal to me, but out of curiosity: what
MM> part of mailman cares that it's a list and not a mail alias?
MM> Does mailman act on the bounces sent back to the envelope from
MM> when it sends password reminders?

Yup, and it'll try to register the bounce for every list at the site, if the bounce comes back to the site list.

-Barry

--- "Barry A. Warsaw" <barry@zope.com> wrote:

...

...

...

...

...

"PS" == Paul Schreiber <cheesefactory@yahoo.com> writes:

PS> While I'm on the topic....
PS>

http://www.apple.com/downloads/macosx/system_disk_utilities/spamstopper.html

PS> That utility translates all the characters in an email address
PS> to character entities, something spambots aren't likely to
PS> pick up on. for now, anyway.

PS> i.e. mailman could incorporate something like this.

Interesting, except that I suspect the mailto: is a dead giveaway. Seems like something the harvesters could easily adjust for and detect, so I don't see the value in spending time implementing it.

Yes,, but you can encode the "mailto:" as well, like so: <a href="mailto:joe@aol.com">me</a>

I would guess most spambots are pretty dumb, probably using a silly regex like <a href="mailto:([^"]+)">.

Paul

Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com

...

...

...

...

"PS" == Paul Schreiber <cheesefactory@yahoo.com> writes:

PS> Yes,, but you can encode the "mailto:" as well, like so: <a
PS> href="mailto:joe@aol.com">me</a>

PS> I would guess most spambots are pretty dumb, probably using a
PS> silly regex like <a href="mailto:([^"]+)">.

This /is/ kind of interesting. Anybody want to write a patch?

-Barry

Well, I figured out my HostileAddress problem (a typo in CVS) and the problem that was hiding (it's Invite*New*Member, not InviteMember <sigh>)... and now my confirmation reply is erroring out. The traceback:

Jun 05 12:02:33 2002 (1522) Traceback (most recent call last): File "/appl/mailman2.1/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/appl/mailman2.1/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/appl/mailman2.1/Mailman/Queue/CommandRunner.py", line 192, in _dispose res.do_command('confirm', (mo.group('cookie'),)) File "/appl/mailman2.1/Mailman/Queue/CommandRunner.py", line 118, in do_command return handler.process(self, args) File "/appl/mailman2.1/Mailman/Commands/cmd_confirm.py", line 44, in process results = mlist.ProcessConfirmation(cookie, res.msg) File "/appl/mailman2.1/Mailman/MailList.py", line 1015, in ProcessConfirmation # Confirmation processing File "/appl/mailman2.1/Mailman/Pending.py", line 97, in confirm db = _load() File "/appl/mailman2.1/Mailman/Pending.py", line 121, in _load return cPickle.load(fp) AttributeError: 'module' object has no attribute 'UserDesc'

I'm not sure if this is because InviteNewMember doesn't take the ack argument that ApprovedAddmember does, or if it's something else... I'd like to think that it's *not* the fact that I added a human-readable address to GetConfirmEmail -- which otherwise worked fine -- or that I changed the subject line (which, since I'm using VERPed confirmations, theoretically ought to be acceptable, as well.

Any ideas?

And, BTW: is there anyway to get the Python traceback to show the damned *values* of the arguments? Am I the only one who's noticed that the current scheme is almost useless? ;-)

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274

"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")