Interesting study -- spam on posted addresses...
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...
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?
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 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.
-- 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 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 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.
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...
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...
-- 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 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 2/17/02 8:16 PM, "Keith Howanitz" <howanitz@nindo.com> wrote:
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.
Then you probably shouldn't be using a list server at all. Simply have people send you admin requests, and manually add and delete them from the alias file.
Why complicate things? Oh -- to make your life easier. That's different. (grin)
-- 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 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 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.
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!" and "My stupid IS department changed my address again and I need help!" problems?
-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.
No! No! Dead girl, OFF the table!
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
On 2/17/02 9:25 PM, "John Morton" <jwm@plain.co.nz> wrote:
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.
I'm not sure I agree. But that's the point -- because it's not easy or obvious is no reason not to try. And because it's not likely to be a 100% soilution is no reason to not do what you can.
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)
-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.
No! No! Dead girl, OFF the table!
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*?
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 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
"JM" == John Morton <jwm@plain.co.nz> writes:
JM> No, it just involves squashing the two actions a user needs to
JM> take into one, more obvious action - rather than subscribe a
JM> new address, confirm it, then delete the old address and
JM> confirm it, you change the address (keeping the settings), and
JM> confirm both dropping the old address and sending to the new
JM> one as a pair of emails. Iff both confirmations succeed, the
JM> address changes, otherwise it stays as it was. Adding other
JM> valid sending addresses will also require an email
JM> confirmation action.I'm working on a longer response to this thread, but let me just point out that MM2.1 already allows users to change their email address (even globally for all lists at the site). It requires only a confirmation from the new address because the action is hidden behind a password screen. So we know the old address has been authenticated and we need only verify that the new address wants the change as well.
Adding email addresses to the user's record requires a more radical change to the underlying schema so that's put off for MM3, but there are plans and (tentative) designs for it.
-Barry
On 2/18/02 7:21 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:
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*?
So we get back to the core of the problem: until we get true authenticatable e-mail addresses, everything we do is fingers in the dike. And even then, I've had some long, technical dialogs with my elder gods of e-mail that have convinced me that even a fully-implemented public-key auth system won't solve all of the problems...
And I have only ten fingers, and ten toes.
-- 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?
There are some very simple solutions to the problem of email harvesting.
The first is to whitelist all mail. Anything not on the whitelist (be it list membership, or whatever) is responded to with an invitation to fill in a web based form to join the whitelist, the mail is held in abeyance until the whitelist is joined. You can hide the whitelist join function behind a POST operation, but can also do a reverse turing test of the 'type what you read in the image above' type to verify that it's a human joining the list.
The second is to avoid publishing email addresses to the world in machine readable form. There are several approaches to this, including the use of javascript email decryptors and/or publishing email addresses as rendered images.
-----Original Message----- From: mailman-developers-admin@python.org [mailto:mailman-developers-admin@python.org] On Behalf Of John Morton Sent: Monday, 18 February 2002 00:25 To: Chuq Von Rospach Cc: mailman-developers@python.org Subject: Re: [Mailman-Developers] Interesting study -- spam on posted addresses...
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
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers
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
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.
-----Original Message----- From: mailman-developers-admin@python.org [mailto:mailman-developers-admin@python.org] On Behalf Of John W Baxter Sent: Monday, 18 February 2002 13:25 To: mailman-developers@python.org Subject: RE: [Mailman-Developers] Interesting study -- spam on posted addresses...
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
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers
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")
On 2/18/02 10:37 AM, "Jay R. Ashworth" <jra@baylink.com> 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 figure out, even if your preferred audience is geeks.
-- 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
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 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")
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 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, 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...
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...
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!
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.
-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.
No! No! Dead girl, OFF the table!
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")
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.
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.
As I see it there are two issues here:
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 dont know the admins email address, you use the form to initiate your conversation.
The second issue is to prevent the email addresses of list members from being harvested from the archives. I think that using rendered images and/or javascript can help here. In implementation, as the archive is being rendered out, one would scan for email addresses, rendering image files whose names are hashes of the email address, and replace the email address with an <img src="hash"> tag. In this way, there would be no 'foo@bar.com' to sift for.
The <img src="hash(email_address)"> approach can also be used for admin's email addresses on any page of the site.
-----Original Message----- From: mailman-developers-admin@python.org [mailto:mailman-developers-admin@python.org] On Behalf Of Chuq Von Rospach Sent: Monday, 18 February 2002 13:47 To: Jay R. Ashworth; mailman-developers@python.org Subject: Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/18/02 10:37 AM, "Jay R. Ashworth" <jra@baylink.com> 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 figure out, even if your preferred audience is geeks.
-- 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
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers
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 dont 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?
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.. Mailing lists by their nature facilitate communitcation between people, and shutting people out of past or current communication to block out a small to moderate amount of crap goes against that.
Instead of just waxing poetic, one solution I've come up with is to block the spambots out from the archives, not the users. Using Apache to Stop Spambots: http://evolt.org/article/mmdev/18/15126/index.html
I've just finished the follow up to that article and it will hopefully get published today. It deals with some of the concerns people brought up regarding User-Agents.. If anyones interested, I'll fwd it on when its live.
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.
At any rate, I know what you're saying Chuq, just wanted to offer the counter-point ;)
Dan
On Mon, 18 Feb 2002, Chuq Von Rospach wrote:
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.
On 2002.02.18, in <Pine.LNX.4.33.0202181446580.30163-100000@meo.evolt.org>, "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.
I think you left something out there -- for fear that the administrator what? :)
Anyway, I wish I had your admins. My admins are just like my subscribers: most of them are ordinary users, and a few are somewhat knowledgeable of the technology. And I expect this to become more common as Mailman grows more popular and "more de facto", if that means anything.
-- -D. dgc@uchicago.edu NSIT University of Chicago Colons and slashes and dots, oh my!
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.
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 Mon, Feb 18, 2002 at 01:57:50PM -0800, Chuq Von Rospach wrote:
Users of a mail list have a right to be protected from spam caused by your mail list.
Ok. I don't want to start a philosophical war here, and I'm perfectly familiar with the concept enshrined in the phrase "that's fine, sonny, but this here's the fleet"...
But I still think it's important to keep firmly uppermost in our minds here that the spam is not *caused* by the mailing list.
Nor is it caused by Google
It's *caused* by the spammers.
I realize that we have practical considerations to deal with which are much closer to our feet, but I think that it's quite important that we don't lose sight of the forest for the trees.
I personally can't think of any method of programmatically obscuring email addresses that can't be programmatically reversed. So, I'm thinking that having a publicly and privately accessible version may be the only answer. I do, though, sort of like the "turing test" idea -- I've often found a useful contact for a project by Googling to mailing lists; having to subscribe to get an email address for an off-llist contact is too steep a hill to climb.
I figure if it's a "public" mailing list (by which I mean, one to which anyone is invited to belong), then such inquiries are the price you pay, so I think this is a reasonable analogy, and thereby, justification for my argument here. Others may disagree.
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:31 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:
But I still think it's important to keep firmly uppermost in our minds here that the spam is not *caused* by the mailing list.
Nor is it caused by Google
It's *caused* by the spammers.
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.
I realize that we have practical considerations to deal with which are much closer to our feet, but I think that it's quite important that we don't lose sight of the forest for the trees.
See, here's our disagreement here. You're saying "put the damn burglars in jail already!" and I'm saying "I agree, but until that's done, I still think I'm installing that deadbolt on the front door".
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.
Even with a good deadbolt, burglaries still happen. Is that an excuse not to put the deadbolt on in the first place? No.
I personally can't think of any method of programmatically obscuring email addresses that can't be programmatically reversed.
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.
But I've been thinking about this, and I want to throw a couple of ideas out. I'm speaking just of the admin-access issue, not archives.
Admin-access has three components to it, all in conflict.
The list admin needs to be accessible to everyone, not just subscribers.
the list admin shouldn't be an open target to spam.
Someone has to be accessible for problem reports even if the Mailman system is malfunctioning.
That third point is a bit of a shift. I've come to the thought (and we can argue it) that LIST admins don't need to be accessible if MAILMAN fails. The MAILMAN admin does. And I think the chances are good that the MAILMAN admin is more likely than not also the person who gets abuse@, root@, postmaster@, so the SITE admin mailbox is already wide open to all these idiots. Making it wide open to mailman spam simply isn't significant.
That, basically, allows us to stuff mailtos somewhere pointing to an address you can mail to to report site failures. I'll even go farther and say that address can simply be on a web page, not linked to a Mailto, and if you really, reallly want, obscure it further as a JPG or something. But I think that's all overkill, given that spammers now automatically spam root/postmaster/etc on domains anyway.
That takes care of the "access in case of failure" mode, mostly by, frankly, simply annointing ONE person (the site admin) as "it" for open access. Not great, but it's sure better than making all admins deal with it.
That then allows us to deal with (1) and (2). Which means we can now put admin access behind some kind of web interface. And - we already have 80% of that, in the current admin interface.
So I recommend this:
You no longer advertise admin's real addresses. Instead, you advertise a feedback that sends messages to the admin, to discourage mailing directly. A year ago, I probably would have insisted on SOME kind of email contact point, but frankly -- the percentage of users who can't use a web page is pretty much zero now.
when you contact a list admin, that message is sent in like existing admin stuff -- the the mailman/admindb/listname page.
The admin stuff is extended to not only handle moderation requests, but also to handle admin email, allowing an admin to delete, respond, send a standard form letter, forward, or whatever.
And since 2.1 has better filtering capabilities, we get those filtering capabilities for free on incoming admin email. And this stuff isn't thrown in an admin's mailbox -- it's dealt with as part of the normal admin list functions, reducing the interruption/hassle factor. And the admin addresses won't end up in spammer databases, because they no longer exist.
Thoughts? It's not perfect, but now only one guy is "it", and the admins are accessible but protected -- and can better separate their list-admin "me" from their real "me" on top of it. And the site admin is more likely IMHO to be capable of managing their mailbox from spam than forcing all list admins to learn how to do that...
-- 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
At 10:15 -0800 2/20/2002, Chuq Von Rospach wrote:
That, basically, allows us to stuff mailtos somewhere pointing to an address you can mail to to report site failures. I'll even go farther and say that address can simply be on a web page, not linked to a Mailto, and if you really, reallly want, obscure it further as a JPG or something. But I think that's all overkill, given that spammers now automatically spam root/postmaster/etc on domains anyway.
Which (as the reader of many of those, and as the person who adds content filters) I find amusing: they deliberately attract the attention of the one most likely to do something. I guess it makes sense when they think about individual's machines sitting there accepting mail; it doesn't make sense when then send to a server which serves lots of users.
It reminds me of the punt returner signalling for a fair catch when the ball will come down near the goal line. What that says to the onrushing troops is "ignore me and my teammates: we can't hurt you anyhow...go after the ball and keep it this side of the line." Exactly what the troops' coach wants them to be told.
So I recommend this:
You no longer advertise admin's real addresses. Instead, you advertise a feedback that sends messages to the admin, to discourage mailing directly. A year ago, I probably would have insisted on SOME kind of email contact point, but frankly -- the percentage of users who can't use a web page is pretty much zero now.
[Good justification snipped.]
I think you're on to something, Chuq.
It also helps those admins who prefer to use a role address rather than a personal one, as things stand now. Saves inventing yet another of those which isn't specially handled by the MTA/Mailman combination.
--John
-- John Baxter jwblist@olympus.net Port Ludlow, WA, USA
On Wed, Feb 20, 2002 at 10:15:33AM -0800, Chuq Von Rospach wrote:
On 2/20/02 9:31 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:
But I still think it's important to keep firmly uppermost in our minds here that the spam is not *caused* by the mailing list.
Nor is it caused by Google
It's *caused* by the spammers.
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.
I realize that we have practical considerations to deal with which are much closer to our feet, but I think that it's quite important that we don't lose sight of the forest for the trees.
See, here's our disagreement here. You're saying "put the damn burglars in jail already!" and I'm saying "I agree, but until that's done, I still think I'm installing that deadbolt on the front door".
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.
Even with a good deadbolt, burglaries still happen. Is that an excuse not to put the deadbolt on in the first place? No.
Well, again: would you deadbolt the public library?
I personally can't think of any method of programmatically obscuring email addresses that can't be programmatically reversed.
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.
Actually, no, I haven't bothered with /. in some time... I'll take a look.
[ looks ]
Hmmm... there are a couple of ways that you *don't* want to despam an adress; hope they didn't hit any of them.
But I've been thinking about this, and I want to throw a couple of ideas out. I'm speaking just of the admin-access issue, not archives.
Admin-access has three components to it, all in conflict.
The list admin needs to be accessible to everyone, not just subscribers.
the list admin shouldn't be an open target to spam.
Someone has to be accessible for problem reports even if the Mailman system is malfunctioning.
That third point is a bit of a shift. I've come to the thought (and we can argue it) that LIST admins don't need to be accessible if MAILMAN fails. The MAILMAN admin does. And I think the chances are good that the MAILMAN admin is more likely than not also the person who gets abuse@, root@, postmaster@, so the SITE admin mailbox is already wide open to all these idiots. Making it wide open to mailman spam simply isn't significant.
I don't need to argue it; I concur: if the server falls over, the server admin is the target. And yeah, they should be wearing armor already.
That, basically, allows us to stuff mailtos somewhere pointing to an address you can mail to to report site failures. I'll even go farther and say that address can simply be on a web page, not linked to a Mailto, and if you really, reallly want, obscure it further as a JPG or something. But I think that's all overkill, given that spammers now automatically spam root/postmaster/etc on domains anyway.
That takes care of the "access in case of failure" mode, mostly by, frankly, simply annointing ONE person (the site admin) as "it" for open access. Not great, but it's sure better than making all admins deal with it.
No problem there.
That then allows us to deal with (1) and (2). Which means we can now put admin access behind some kind of web interface. And - we already have 80% of that, in the current admin interface.
So I recommend this:
You no longer advertise admin's real addresses. Instead, you advertise a feedback that sends messages to the admin, to discourage mailing directly. A year ago, I probably would have insisted on SOME kind of email contact point, but frankly -- the percentage of users who can't use a web page is pretty much zero now.
This is, alas, a different topic.
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.
I can at least tolerate it, if you'll carbon me a copy, but it's still suboptimal.
And since 2.1 has better filtering capabilities, we get those filtering capabilities for free on incoming admin email. And this stuff isn't thrown in an admin's mailbox -- it's dealt with as part of the normal admin list functions, reducing the interruption/hassle factor. And the admin addresses won't end up in spammer databases, because they no longer exist.
Now *that* part, I like.
Thoughts? It's not perfect, but now only one guy is "it", and the admins are accessible but protected -- and can better separate their list-admin "me" from their real "me" on top of it. And the site admin is more likely IMHO to be capable of managing their mailbox from spam than forcing all list admins to learn how to do that...
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.
But that's why *I'm* not the Mailman product line manager. :-)
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 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 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.
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.
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?
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?
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.
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?
Even with a good deadbolt, burglaries still happen. Is that an excuse not to put the deadbolt on in the first place? No.
Well, again: would you deadbolt the public library?
See above. You don't get the analogy right.
This is, alas, a different topic.
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?
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.
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.
-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.
At 13:42 -0800 2/20/2002, Chuq Von Rospach wrote:
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.
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.
--John
John Baxter jwblist@olympus.net Port Ludlow, WA, USA
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.
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.
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 Wed, 20 Feb 2002, Chuq Von Rospach wrote:
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.
So should there be a user-settable option "don't archive my posts"? (Or a header that can be set to cause a message not to get archived?)
-Dale
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.
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.
-----Original Message----- From: mailman-developers-admin@python.org [mailto:mailman-developers-admin@python.org] On Behalf Of Chuq Von Rospach Sent: Wednesday, 20 February 2002 18:40 To: Dale Newfield; mailman-developers@python.org Subject: Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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.
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailma> n-developers
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")
"JRA" == Jay R Ashworth <jra@baylink.com> writes:
JRA> Secondly, if Piper implements this the same way that Google
JRA> does, you can put it in as the first line of the body,
JRA> starting in column 1, followed by an (additional) blank line,
JRA> and it will still take effect.It doesn't, currently. IIRC, only the new topics feature does a body scan for header-like directives. In the face of increasing html and multipart/alternative messages, it's a little tricky to code correctly. We should probably factor that out into a utility.
-Barry
"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: noprevents 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
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: noprevents 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")
"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")
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")
On Wed, Feb 20, 2002 at 02:31:54PM -0800, Chuq Von Rospach wrote:
- 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.
And, to clarify my opinion, I don't disagree with this in the least.
That doesn't mean I think it's *right*.
- 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.
*Definitely... but people should realize that that's a possibilty *any time the give their address out*.
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.
Surely.
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 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 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.
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.
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.
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.
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.
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.
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.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after
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")
On 2/20/02 7:26 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
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*.
You're avoiding the issue. If you don't build the system so real people can use it, real people won't. Which means they'll go use something else, so why bother build this at all?
Hotmail and Yahoo are jokes. They're free; you take what you're paying for.
They're popular. And you ignored AOL, the 500 pound gorilla. Just because you don't like them doesn't give you the right to tell others not to use them, just to fit your idea of how this stuff ought to be done.
Spaminator. You picked precisely the example I had in mind. If the masses *demand* solutions, those solutions *will* happen.
Oh, god. You're going to castrate mailman just to try to force users to take up arms in your personal fight? Convince them to join. Don't destroy other tools to try to coerce them into it.
Wrong attitude. Sory, I won't buy into it. You can't gut one tool to try to force people into buying into a fight. They aren't stupid -- they don't buy in, they go elsewhere. And I won't support your castrating mailman for a personal agenda for how spam ought to be fought. I'm not interested in those fights. I'm interested in building tools that get the right job done for people.
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.
Nope. Sorry. That's a copout.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Very funny, Scotty. Now beam my clothes down here, will you?
"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:25:49AM -0500, Barry A. Warsaw wrote:
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.
"I'm here to talk to you about an itch *so* private..." Yeah. :-)
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.
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.
Well, I think the argument was over what constituted 'better', on which topic I think Chuq and I disagree a bit. ;-)
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.
On Mon, Feb 25, 2002 at 09:23:59AM -0800, Chuq Von Rospach wrote:
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.
Eek.
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?
Nope. Same address for 5 years, too. And I'm a lightning rod on Usenet, just as much as I am here. ;-)
It's all over my weblog, too; not obfucsated there, either.
And my pain level *still* hasn't climbed high enough to merit automated methods (read: higher than the pain level of learning procmail. ;-)
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!
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
"JWB" == John W Baxter <jwblist@olympus.net> writes:
JWB> Once I had the domain, I started registering each product (or
JWB> company's products) with a unique local part @scandaroon.com.
JWB> Late last year, I had a sudden infusion of Spam addressed to
JWB> jwbpalm@scandaroon.com. [Company shall remain nameless ;-)]
JWB> Sending mail to that address now produces a 550 response
JWB> whose text is "sold down the river by Palm" (Which might be
JWB> wrong...they might have leaked it instead...which IMHO is
JWB> worse.) Palm is probably following the privacy policy as it
JWB> has evolved since I registered the (early production) Palm
JWB> IIIx.Neat! I do the same thing with my wooz.org domain. I get no spam on any of those product-derived addresses.
-Barry
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!
"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.
On 2/20/02 8:23 PM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Nor do the spammers need to deobfuscate all the obfuscations. They only need enough that they're getting a reasonable harvest rate.
A very good point. We want to make it tough on spambots, but adding complexity to the system is useful only if it actually makes it tough on the spambots. If, instead, it merely ends up adding complexity, we might as well not do it.
If the real answer is "well, it means they have to harvest our site five times to ge the address instead of once", we shouldn't bother. Does anyone know if the /. System actually accomplishes anything? Or have the spambots adapted already?
We can't do nothing until we get a 100% solution -- those don't exist. But we also shouldn't do things just to be seen as doing things, if those things we do don't really help or are merely minor inconveniences for the spam harvesters that are easily worked around.
Ah, the joys of design and architecture. Of course, if it was easy, it'd be written by now.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Yes, I am an agent of Satan, but my duties are largely ceremonial.
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 1:07 PM, "Damien Morton" <dm-temp-310102@nyc.rr.com> wrote:
But we do want google et al to index the archives don't we?
I don't, no.
I've found myself joining all sorts of lists that I found googling for this or that subject.
So you see the archives as marketing to increase usage of the list? And for that, you'll give away your users email addresses to the spammers?
Do you get high quality new subscribers through google? Do you know? Or does it attract vampires and trolls?
Are there any other benefits to being googled than being a walking billboard to the list?
-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.
No! No! Dead girl, OFF the table!
"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 11:17 PM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Chuq> Are there any other benefits to being googled than being a Chuq> walking billboard to the list?
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.
But -- I hate to be bullheaded about this, but I will be -- how does this benefit YOUR LIST? Yes, it benefits others, and there's some value to that, but does it actually add value to your list? Enough value to warrant handing your subscriber list to the spammers?
See, if I'm going to expose my users to spammers, there better be value to those users worth the hassle. So far, I've seen value in being google to marketing the list, and value to non-subscribers. But what advantage do the users being handed to the spammers get?
Do your users know (and understand) that the global archives make them open season for spambots? Have they agreed to this? Have you discussed it with them? Or is this soemthing you've hoped they didn't discover on their own?
If you "put it up to a vote" after explaining the situation, do you think the subscribers of your list would vote to stay in google? If not, how do you justify doing it to them anyway?
I'm not picking on you, stephen, at least not personally. But yours is a very common attitude, one that was mostly entrenched in mailing list philosophy five or more years ago before spammers and spambots became such a nasty problem. I'm suggesting that it's time to rethink this on all lists that globally expose their archives, because life has changed. And I kinow that my users, as they've learned about then issue, have become very noisy about not being openly distributed (in fact, to some degree, it was my users that educated me into looking at the issue...).
I mean, years ago mail lists were open to all posters, too, and many had usenet gateways. These days, the spam problems have forced changes to those, also, on many (most?) lists. The only reason the archive issue has less visibility is that the spam ends up directly in the users mailbox, so the connection isn't as visible to a typical user. But that doesn't mean it's not there.
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
No offense, but "long established" doesn't mean it's still the correct decision. Times change -- especially on the internet. Frankly, the longer a practice is established, the more I think it needs to be rethought.
We're all busy -- but what's more important than protecting our users from the outside world? Don't the users come first?
Chuq
-- 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
"Chuq" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
Chuq> But -- I hate to be bullheaded about this, but I will be --
Chuq> how does this benefit YOUR LIST? Yes, it benefits others,
Chuq> and there's some value to that, but does it actually add
Chuq> value to your list? Enough value to warrant handing your
Chuq> subscriber list to the spammers?To be precise, it's not the subscriber list; only about 1 in 5 posts, ever.
Chuq> If you "put it up to a vote" after explaining the situation,
Chuq> do you think the subscribers of your list would vote to stay
Chuq> in google?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. It may not be all that costly to them, either. I only see about 15% of the spam sent my way, and I don't filter very hard. I think a lot of the posters do substantially better than that (eg, we've got several TMDA users).
But it really doesn't matter, because the XEmacs devel lists are an extreme case as far as I can tell. I guess my bottom line here is that you've got me convinced that the _default_ should be no Google and private archives. My basic point was to give an example of a case where the purpose of the list is more than just communication among the subscribers. I suppose that in some cases that purpose warrants considering open archives, just as list managers have to have published addresses so they can perform subscriber services.
Now that I'm aware of the issue, I'll have to do something about assessing whether the value to non-subscriber users outweighs the abuse the posters take.
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". Note: he was presumably aware of the issue---he's a long-time TMDA user. And he took a fair amount of care to make things as easy as possible for those who followed; he moved to Mailman as the list server, for example, although as far as the list subscribers were concerned the existing Majordomo installation was working fine.
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.
-- 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/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 Mon, Feb 18, 2002 at 10:47:16AM -0800, Chuq Von Rospach wrote:
On 2/18/02 10:37 AM, "Jay R. Ashworth" <jra@baylink.com> 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 figure out, even if your preferred audience is geeks.
Well, it sounded to *me* like he was *trying* to mediate for the UnGeeked, merely unsuccessfully.
I get paid to remember what you've pointed out, and I'm pretty good at it, but I still sometimes forget...
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/18/02 8:58 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
I get paid to remember what you've pointed out, and I'm pretty good at it, but I still sometimes forget...
Me, too, on both counts. I tend to be good at questions, but the answers aren't nearly as easy...
-- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware.
No! No! Dead girl, OFF the table!
I /think/ I've caught up on this thread, but I'm sure I've missed a bunch. As I see it there are really these issues to protecting email addresses in Mailman:
- list admin addresses
- public archives
- private archives
- raw archive
- list rosters
For #1, MM2.1 changes what gets included at the bottom of list pages. The admin's personal address is no longer included in the link's text or in mailto: href. In the mailto: you'll see something like mylist-owner@dom.ain and in the text you'll see something like "barry at zope.com". I see no point in trying to obscure the former -- or put it behind a web form -- because it's easily guessed given a probe of existing lists, as is every other list-related email address. More on protecting the -owner from spam below. I claim that the guessability is a feature, btw.
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.
(Aside: I really really hate websites that are only viewable with JavaScript on, and I often send a friendly ADA-ish noodge to webmaster when I find such beasts, although it rarely does any good).
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). Rosters and the improved user database will allow us to actually equate admin email addresses with Real Names, so you could conceivably see something like
List run by <a href="mailto:mylist-owner@dom.ain">Barry Warsaw</a>at the bottom of the pages. You'd be within your rights to argue that end users never even need know who admins the list, but I think it helps to avoid the "faceless droid" syndrome.
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.
As for #2, I'd go for the low-tech approach of simply discarding the hostname part of the email address in all public archives. Certainly this is easy in the headers, and we'll have to decide whether we're going to expend the resources to do body searches for email addresses, and obfuscate those as well. If people want to make contacts based on some public archive message, they can email the list. Until we've got web-posting, I don't think it matters if they lose the full email address in the public archives.
As for #3, I don't mind not obscuring the email addresses since a login will be required. If we think we don't trust the current private archive login procedures to be secure against bots, then we can fix that, but I don't see it as a high priority.
#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.
Things to note for #'s 2-4:
The Pipermail implementation has lots of well-known problems. I'm personally not willing to spend a lot of time fixing them, and I still recommend Real Sites use a Real Archiver. I've just thrown the majority of the email obfuscation problems over the fence into someone else's back yard <wink>.
Adding public archive obfuscation is fine and dandy for new messages added to the archives but what about all the existing archived messages? Re-running Pipermail (i.e. bin/arch) to regenerate from scratch has two significant drawbacks. 1) Message url's can change, especially if you also fix broken From_ delimiters, and that in turn breaks bookmarks, 2) on large mboxes, you simply can't do bin/arch because of memory problems.
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.
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).
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.
Anybody who's really interested in archiving (I'm not) should take a look at Zest and think about contributing to it, so that it does stuff like this correctly from the start. I really like the Zest interface and think it ought to at least be a bundled alternative to Pipermail, some day.
Nobody's even mentioned #5, which are available publically via the "Visit Subscriber List" button, or the email command "who" to the -request address. If I were a spam harvester, I wouldn't even bother with scanning the archives if either of these were publically enabled. When you turn them off, especially the former, just remember that you've now made it much harder for Joe User to unsubscribe themselves. Catch 22.
-Barry
On Mon, Feb 25, 2002 at 12:27:23PM -0500, Barry A. Warsaw wrote:
I /think/ I've caught up on this thread, but I'm sure I've missed a bunch. As I see it there are really these issues to protecting email addresses in Mailman:
- list admin addresses
- public archives
- private archives
- raw archive
- list rosters
I believe you've synopsized it correctly, yes.
For #1, MM2.1 changes what gets included at the bottom of list pages. The admin's personal address is no longer included in the link's text or in mailto: href. In the mailto: you'll see something like mylist-owner@dom.ain and in the text you'll see something like "barry at zope.com". I see no point in trying to obscure the former -- or put it behind a web form -- because it's easily guessed given a probe of existing lists, as is every other list-related email address. More on protecting the -owner from spam below. I claim that the guessability is a feature, btw.
Concur.
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.
And, of course, if it *will* degrade, then address-snarfers will figure out how to *make* it degrade, so it's not worth doing in the first place, at least not for *that* reason.
(Aside: I really really hate websites that are only viewable with JavaScript on, and I often send a friendly ADA-ish noodge to webmaster when I find such beasts, although it rarely does any good).
Hear hear!
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).
I do see one problem here, and I don't know if you already address it below. [ looks ] You don't; it's this: if the list-owner addresses go through the MM machinery, as well, then they too can die if MM crashes the wrong way.
This implies, as I believe has already been discussed, that the *server* admin address must be publicly accessible, not be piped into MailMan at all, and preferably, should actually not even be handled by the same machine... ("Single point of failure")
Rosters and the improved user database will allow us toactually equate admin email addresses with Real Names, so you could conceivably see something like
List run by <a href="mailto:mylist-owner@dom.ain">Barry Warsaw</a>at the bottom of the pages. You'd be within your rights to argue that end users never even need know who admins the list, but I think it helps to avoid the "faceless droid" syndrome.
Concur *strongly*.
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.
That sounds good, and if there isn't already a "plugin" API for that, we ought to give some thought to that...
As for #2, I'd go for the low-tech approach of simply discarding the hostname part of the email address in all public archives. Certainly this is easy in the headers, and we'll have to decide whether we're going to expend the resources to do body searches for email addresses, and obfuscate those as well. If people want to make contacts based on some public archive message, they can email the list. Until we've got web-posting, I don't think it matters if they lose the full email address in the public archives.
Well, personally, I don't ever assume that someone who posted a message a year ago with 95% of the answer to my question is even *on* the list anymore -- a situation I don't think you thought of -- but...
As for #3, I don't mind not obscuring the email addresses since a login will be required. If we think we don't trust the current private archive login procedures to be secure against bots, then we can fix that, but I don't see it as a high priority.
Concur.
#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.
Is there a difference between raw and private that I'm missing? Do you mean the mbox format files?
Things to note for #'s 2-4:
- The Pipermail implementation has lots of well-known problems. I'm personally not willing to spend a lot of time fixing them, and I still recommend Real Sites use a Real Archiver. I've just thrown the majority of the email obfuscation problems over the fence into someone else's back yard <wink>.
:-)
- Adding public archive obfuscation is fine and dandy for new messages added to the archives but what about all the existing archived messages? Re-running Pipermail (i.e. bin/arch) to regenerate from scratch has two significant drawbacks. 1) Message url's can change, especially if you also fix broken From_ delimiters, and that in turn breaks bookmarks, 2) on large mboxes, you simply can't do bin/arch because of memory problems.
See above. :-)
- 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.
Not much danger of that, is there?
- 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).
Well, that's probably the best point yet: this isn't *MailMan's* problem, except to the extent that we "recommend" Piper as out archiver.
- 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.
No, but the performance reasons aren't as much of an issue now...
Nobody's even mentioned #5, which are available publically via the "Visit Subscriber List" button, or the email command "who" to the -request address. If I were a spam harvester, I wouldn't even bother with scanning the archives if either of these were publically enabled. When you turn them off, especially the former, just remember that you've now made it much harder for Joe User to unsubscribe themselves. Catch 22.
<chuckle>
Not enough experience in the field, or I'd probably have mentioned that already.
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")
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
On 2/25/02 9:56 PM, "Barry A. Warsaw" <barry@zope.com> wrote:
- Some place that password reminders come from. Since this will be receiving bounces, it ought to be a real list.
Cautionary tale here.
A long time ago, in a galaxy far, far away, I decided to do my users a favor, and created an over-arching meta-list of all subscribers (effectively, an umbrella list of all lists on my site). I figured users would appreciate getting the monthly messages and admin notices once, instead of once-per-subscription.
Silly me. All it did was start a continuing set of firefights with people who demanded the right to unsubscribe from the umbrella list. And they were quite unpleasant about it. I never did figure this out, either -- people that never complained about getting five copies of the monthly notice started screaming bloody murder when they started getting ONE, because they insisted on the right to get zero.
It was such a nasty situation I blew the whole thing up after a few months, and went back to mailing admin and monthly notices to each list. And people stopped screaming.
So just be aware -- if you create a server-wide "list", you may well be creating a point of conflict, based on my experience. And it wasn't a situation where, at least for those users, "if you subscribe to a list on this site, you have to get this" was an acceptable answer to these people. So instead of getting a message once, they get it four or five times, and since they come in the name of the list they subscribed to, evidently that's okay.
Go figure. But be wary here, Barry. My experience doing something very similar was horrible.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
No! No! Dead girl, OFF the table!
"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
"MM" == Marc MERLIN <marc_news@vasoftware.com> writes:
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.
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.
-Barry
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
On Tue, Feb 26, 2002 at 05:07:41PM -0800, Marc MERLIN wrote:
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?
The *user*, when the list machinery breaks completely, and there's no obvious target address to complain to.
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")
"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
On 2/26/02 4:50 PM, "Marc MERLIN" <marc_news@vasoftware.com> wrote:
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's our experience, exactly. And it's mostly the same people, every month, making accusations about my mother's morals.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Yes, I am an agent of Satan, but my duties are largely ceremonial.
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' andmailman-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
you can't put in every mail footer cause you don't *want* people using it unless something goes Horribly Wrong, but
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")
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
"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.
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.
-barry
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")
"BAW" == Barry A Warsaw <barry@zope.com> writes:
BAW> I /think/ I've caught up on this thread,Like JRA I think your synopsis is accurate, with respect to the issues that can be addressed by code.
BAW> I claim that the guessability [of list-related addresses] is
BAW> a feature, btw.Yes.
BAW> I'd do the same with cookies if I could figure out how to do
BAW> low-frustration-factor authentication without them.Don't even think such things. You're just tempting the Lords of Chaos. Ie, in this case, if you can't support HTTP well enough to handle cookies, you aren't going to support anything powerful enough for any kind of authentication very well either. It's just not the same as supporting multimedia.
BAW> 5) list rostersI don't know of any lists where these are available to the members, let alone the public.
-- 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/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.
On Tuesday 26 February 2002 15:47, Chuq Von Rospach wrote:
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�e list admins don't have the ability to open it up any more...
I find this feature is handy for small, private lists. I'd rather it was still around and just disabled by default with warning stickers all over it than we dumb down mailman to Fisher Price levels just in case some twit exposes people to a greater likelihood of receiving junk mail. Perhaps it can be made to be disabled in a site-wide fashion?
John
"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 mailmanTo 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.
"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
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.
Much preferable to hoping they go and find themselves in the roster.
I think the whole roster thing is obsolete technology, and few users today are on lists that actually disttribute them, so few know they exist, much less think to use them. I'd love to see data from sites that DO promote them to see how they're actually being used.
-- 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 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 08:30:02AM -0500, Phil Barnett wrote:
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.
*Whoa* yeah!
Any error message that doesn't include the parameter of a bad call should cause it's writer to be shot.
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")
"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:
>> 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.
CVR> If you go to VERP (or more correctly, customized email), you
CVR> can set up the footer of each message to include a URL to
CVR> take them right ot the unsub page. Or then mimic lyris with a
CVR> "you are subscribed as" in the footer.In fact, when email personalization is enabled, there's a new substitution variable `user_optionsurl' which gets replaced with the url for the user's login page (which itself contains a big prominent Unsubscribe button).
CVR> Much preferable to hoping they go and find themselves in the
CVR> roster.
CVR> I think the whole roster thing is obsolete technology, and
CVR> few users today are on lists that actually disttribute them,
CVR> so few know they exist, much less think to use them. I'd love
CVR> to see data from sites that DO promote them to see how
CVR> they're actually being used.Me too. Until then, I'm making the default for new mailing lists be private rosters.
-Barry
On Tuesday 26 February 2002 16:52, Stephen J. Turnbull wrote:
"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.)
Unless the membership data that mailman stores has suddenly got a lot better documented since I last looked, I assume you're basically maintaining a separate list for your roster. I'd rather have one source of member data.
John> I'd rather it was still around and just disabled by default John> with warning stickers all over it than we dumb down mailmanTo 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?"
I agree that when Mailman has a nice, well documented data schema and a datastore that accepts concurrent client access, then this sort of feature ought to be deprecated from the MM core.
John
On Mon, Feb 25, 2002 at 06:47:43PM -0800, Chuq Von Rospach wrote:
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.
Waaaal, there's
http://crackmonkey.org/mailman/roster/crackmonkey
--
Dan Wilder <dan@ssc.com> Technical Manager & Editor SSC, Inc. P.O. Box 55549 Phone: 206-782-8808 Seattle, WA 98155-0549 URL http://embedded.linuxjournal.com/
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
>> BAW> 5) list rosters
>> I don't know of any lists where these are available to the
>> members, let alone the public.
CVR> You know, now that I think about it. Wihle I think Mailman
CVR> now has this turned off by default (does it? If not, it
CVR> should...), perhaps it's time to just make the option dead
CVR> and buried, so that naïve list admins don't have the ability
CVR> to open it up any more...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.
-Barry
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.
"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
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. You may be able to make a case for not even them to be able to see the roster :-)
ie those with EU data protection legislation affecting them. I have a vague idea that there are EU attempts to make this legislation stick worldwide where EU citizens are involved, and US attempt to be able to rape the data whoever its on.
Nigel.
[ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ]
On Wed, Feb 27, 2002 at 09:40:20AM +0000, Nigel Metheringham 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. You may be able to make a case for not even them to be able to see the roster :-)
- ie those with EU data protection legislation affecting them. I have a vague idea that there are EU attempts to make this legislation stick worldwide where EU citizens are involved, and US attempt to be able to rape the data whoever its on.
Well, presumably, if you *tell the users before hand that it's a condition*, then could make the information available, right?
Lawyers will be happy to make it impossible for you to actually conduct business, if you let them; after all, *everything* is a legal exposure.
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.
"NM" == Nigel Metheringham <Nigel.Metheringham@dev.InTechnology.co.uk> writes:
NM> * ie those with EU data protection legislation affecting them.
NM> I have a vague idea that there are EU attempts to make this
NM> legislation stick worldwide where EU citizens are involved,
NM> and US attempt to be able to rape the data whoever its on.Lovely. There's probably some stupid-ass DMCA, SSSCA, or other idiocy that'll get passed in the US that will prohibit you from disabling the roster because then you'll be circumventing some digital security device. Then we're in a catch-22 where Mailman will only be legal in Togo, but only there until the Dizz Knee Police need a boondoggle enforcement expedition.
can-i-be-a-rock-star-yet?-ly y'rs, -Barry
"SJT" == Stephen J Turnbull <stephen@xemacs.org> writes:
BAW> I'd do the same with cookies if I could figure out how to do
BAW> low-frustration-factor authentication without them.
SJT> Don't even think such things. You're just tempting the Lords
SJT> of Chaos. Ie, in this case, if you can't support HTTP well
SJT> enough to handle cookies, you aren't going to support
SJT> anything powerful enough for any kind of authentication very
SJT> well either. It's just not the same as supporting
SJT> multimedia.Yeah, it's just that I generally hate cookies too. But there's not much value in debating this. It is what it is.
BAW> 5) list rosters
SJT> I don't know of any lists where these are available to the
SJT> members, let alone the public.If you only knew, you might be horrified (I know Chuq would be).
-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.
"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. :)
BAW> If you only knew, you might be horrified.
SJT> Naw. I'm an economist in Japan. Beyond horror.Try setting up a bona fide IRS approved not-for-profit in the USA. We humans have devised so many creative ways to reduce our brains to tasty grey jelly, it's almost funny.
-Barry
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.
"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 could be totally off base though.
-Barry
--- "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
"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.
-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
--- Paul Schreiber <cheesefactory@yahoo.com> wrote:
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:([^"]+)">.
Be careful if you read my last message via a web browser; it may have shown up as a plain text mailto instead of being encoded as entities.
here, i've purposely broken the entities by adding spaces: <a href="& # 109;& # 97;& # 105;& # 108;& # 116;& # 111;& # 58;& # 106;& # 111;& # 101;& # 64;& # 97;& # 111;& # 108;& # 46;& # 99;& # 111;& # 109;">me</a>
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
Hmm, Ill have a bash at it.
Its better than no protection at all, and its easy enough to do.
A function that resolves entities isnt hard to write though, heres one:
rentity = re.compile(r"&(\w+);") rhashentity = re.compile(r"&#(\d+);")
from htmlentitydefs import entitydefs
#escapes entities of the form 'ϧ' and '&aaa;' into ascii strings def unentity(s): s = rentity.sub(lambda m: entitydefs.get(m.group(1), m.group()), s) s = rhashentity.sub(lambda m: chr(int(m.group(1))), s)
It's a shame you cant define your own entities in html.
-----Original Message----- From: Barry A. Warsaw [mailto:barry@zope.com] Sent: Thursday, 28 February 2002 23:01 To: Paul Schreiber Cc: Damien Morton; mailman-developers@python.org Subject: RE: [Mailman-Developers] Protecting email addresses from spam harvesters
"PS" == Paul Schreiber <cheesefactory@yahoo.com> writes:
PS> Yes,, but you can encode the "mailto:" as well, like so: <a PS>href="mailto:jo 1;@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
On Tue, Feb 26, 2002 at 01:40:20AM -0500, Barry A. Warsaw wrote:
Try setting up a bona fide IRS approved not-for-profit in the USA. We humans have devised so many creative ways to reduce our brains to tasty grey jelly, it's almost funny.
I'm a director of one; secretary, in fact; that stack of paper lives in a box in my van.
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 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 notbecome 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 leastone 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")
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
On Tue, Feb 19, 2002 at 12:04:54AM -0800, Chuq Von Rospach wrote:
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.
Yup. It's just like edge providers enforcing source address spoofing prevention. It doesn't cure DDoS attacks, but it makes every other kind easier to trace... and for that matter, it makes DDoS's easier to trace, not that you have the time. :-)
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.
No. It's definitely a judgement call here how far the analogy ought reasonably to be expected to stretch.
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...
<sigh>
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 still enablers, regardless of their conscious intent...
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.
Yeah, the difference between theory and practice is much greater in practice than in theory. <sigh^2>
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 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
participants (20)
-
barry＠zope.com -
Chuq Von Rospach -
Dale Newfield -
Damien Morton -
Dan Wilder -
Daniel J. Cody -
David Champion -
Jay R. Ashworth -
John Morton -
John W Baxter -
Keith Howanitz -
Larry McVoy -
mac＠wooz.org -
Magnus Stenman -
Marc MERLIN -
Nigel Metheringham -
Paul Schreiber -
Phil Barnett -
Stephen J. Turnbull -
Terri Oda