Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/17/02 7:39 PM, "Larry McVoy" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/17/02 7:48 PM, "Larry McVoy" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Sun, 17 Feb 2002, Chuq Von Rospach wrote: > On 2/17/02 7:48 PM, "Larry McVoy" <[EMAIL PROTECTED]> 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 ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/17/02 8:16 PM, "Keith Howanitz" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/17/02 8:39 PM, "John Morton" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- http://www.chuqui.com/) Will Geek for hardware. No! No! Dead girl, OFF the table! ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/17/02 9:25 PM, "John Morton" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- http://www.chuqui.com/) Will Geek for hardware. No! No! Dead girl, OFF the table! ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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 [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/18/02 10:37 AM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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 tag. In this way, there would be no '[EMAIL PROTECTED]' to sift for. The approach can also be used for admin's email addresses on any page of the site. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Chuq Von Rospach Sent: Monday, 18 February 2002 13:47 To: Jay R. Ashworth; [EMAIL PROTECTED] Subject: Re: [Mailman-Developers] Interesting study -- spam on postedaddresses... On 2/18/02 10:37 AM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/18/02 8:58 PM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- http://www.chuqui.com/) Will Geek for hardware. No! No! Dead girl, OFF the table! ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/18/02 7:15 AM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/18/02 7:21 AM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- http://www.chuqui.com/) Will Geek for hardware. Very funny, Scotty. Now beam my clothes down here, will you? ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/19/02 1:46 AM, "Damien Morton" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- http://www.chuqui.com/) Will Geek for hardware. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/19/02 7:09 AM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- http://www.chuqui.com/) Will Geek for hardware. No! No! Dead girl, OFF the table! ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/20/02 9:45 AM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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 [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Wed, Feb 20, 2002 at 10:15:33AM -0800, Chuq Von Rospach wrote: > On 2/20/02 9:31 AM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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. > > 1) The list admin needs to be accessible to everyone, not just subscribers. > > 2) the list admin shouldn't be an open target to spam. > > 3) 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 > capabilitie
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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 [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/20/02 2:13 PM, "John W Baxter" <[EMAIL PROTECTED]> wrote: > At least in Chuq's context, in which Apple claims in their privacy policy > to protect the addresses of us innocent subscribers to their lists. > > That context may not match the context of other list operators, who may > feel that the subscribers are out in the main stacks somewhere. Or in a > drawer in the librarian's desk for "suitable" review. Both true, but I have two points to carry this further. 1) I think a tool like Mailman has to implement to the highest-reasonable security, so if people want to be looser, fine. It's easier to loosen the reins than expect JrandomeUser to implement extra features on an ad hoc basis. I also think a tool like Mailman ought to try to set a "best practices" model for how it operates. Mailman should set the standard for how we think mail lists ought to be run, not be the least common denominator that everyone has to hack extras into to make it fit their needs. 2) admins can set whatever policies they want -- but I think it's important they disclose them, so users can make informed choices. That includes, frankly, letting users know their addresses are potentially exposed to spammers, so if a user is sensitive to this, they can choose to not subscribe, or to leave the list. I'm not telling admins what their policies need to be, but I do think Mailman needs to understand it's role as a "best practices" tool -- and I do feel strongly that whatever an admin does, they do so in a mode that involves informed consent with their users. -- Chuq Von Rospach, Architech [EMAIL PROTECTED] -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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 ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/20/02 2:43 PM, "Dale Newfield" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of > Chuq Von Rospach > Sent: Wednesday, 20 February 2002 18:40 > To: Dale Newfield; [EMAIL PROTECTED] > Subject: Re: [Mailman-Developers] Interesting study -- spam > on postedaddresses... > > > On 2/20/02 2:43 PM, "Dale Newfield" <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] -- http://www.chuqui.com/ > > Stress is when you wake up screaming and you realize you > haven't fallen asleep yet. > > > ___ > Mailman-Developers mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/mailma> n-developers > ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Wed, Feb 20, 2002 at 01:42:34PM -0800, Chuq Von Rospach wrote:
> On 2/20/02 1:18 PM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Wed, Feb 20, 2002 at 02:31:54PM -0800, Chuq Von Rospach wrote: > 1) I think a tool like Mailman has to implement to the highest-reasonable > security, so if people want to be looser, fine. It's easier to loosen the > reins than expect JrandomeUser to implement extra features on an ad hoc > basis. I also think a tool like Mailman ought to try to set a "best > practices" model for how it operates. Mailman should set the standard for > how we think mail lists ought to be run, not be the least common denominator > that everyone has to hack extras into to make it fit their needs. And, to clarify my opinion, I don't disagree with this in the least. That doesn't mean I think it's *right*. > 2) admins can set whatever policies they want -- but I think it's important > they disclose them, so users can make informed choices. That includes, > frankly, letting users know their addresses are potentially exposed to > spammers, so if a user is sensitive to this, they can choose to not > subscribe, or to leave the list. *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[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Wed, Feb 20, 2002 at 06:49:53PM -0800, Chuq Von Rospach wrote: > On 2/20/02 5:36 PM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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 tha
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Wed, 20 Feb 2002, Damien Morton wrote: > I still think the email-address-as-jpeg solution is prohibitively > expensive to reverse; effectively impossible for machines, entirely easy > for people. But it does have drawbacks. It only works with graphical browsers. It can't be enlarged for people that have poor vision. It can be reverse-engineered -- all they have to do is decode a single font, then they're all simple to snag. In fact, as someone with lots of computer graphics experience, I'd say it would be almost no harder to write code to decode them than it would be to write code to generate them. > Web Forms for contacting the admin cold. If the admin replies, you can > continue the conversation via email. Right, assuming the web form doesn't break. > Private and Public views of the archives. > > Private archives are restricted to list members and those that can pass > a reverse turing test. People keep using this term, but I'm not sure what they mean, or if I trust that they'd be so reliable... > Public archives render all email addresses as jpegs. If they're automatically generated, it'd be easier to create pngs or gifs, or lots of other formats than jpgs. Think about this, though--how do you actually generate the images and serve them properly without either including the email address in the html code anyway (so the img request specifies what image to generate), or building a whole database mapping arbitrary numbers to email addresses (so they can either be generated on the fly or stored pre-generated). Once you've got that database, why not just have that database front a web form instead of displaying the address? -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
>> I still think the email-address-as-jpeg solution is prohibitively >> expensive to reverse; effectively impossible for machines, entirely easy >> for people. > > But it does have drawbacks. > > It only works with graphical browsers. This is a very good point. I mentioned ADA compliance yesterday. To be ADA compliant, if you rendered the e-mail address as a graphic, you'd also have to put the text into the ALT tag. Which would enable it for lynx and sight-limited solutions -- and make putting into a graphic kinda meaningless. So you can't use this approach unless you want to ignore the ADA and lock out your blind users from those functions. I'm not willing to make that tradeoff. While I'm not going to live or die on the ADA compliance issue, I think it's important to keep it in mind because it forces us to focus on more than the "easy" case or the "geek" case and worry about solutions that work across the spectrum of users, from the AOL newbie to Jay. We can't solve problems just for Jay, or just for Newbies, we have to find a solution that works as well as possible for as many of those groups as possible. ADA compliance is a useful strawman that keeps us focussed away from "I want it this way, so that's the right way". -- Chuq Von Rospach, Architech [EMAIL PROTECTED] -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thursday 21 February 2002 17:15, Dale Newfield wrote: > On Wed, 20 Feb 2002, Damien Morton wrote: > > Web Forms for contacting the admin cold. If the admin replies, you can > > continue the conversation via email. > > Right, assuming the web form doesn't break. Monitor the form. Your monitoring tools should be telling you when bits of your site break before users have a need to report the problem. > > Private and Public views of the archives. > > > > Private archives are restricted to list members and those that can pass > > a reverse turing test. > > People keep using this term, but I'm not sure what they mean, or if I > trust that they'd be so reliable... It's a test to find out if the agent that requested the page is human or some bot of some sort. In order to progress past the form you have to enter something into the box as a reply to some text in the form. If the question and answer can be arbitary on a site by site, or better, hit by hit basis, then it becomes infeasible to build a spambot to enter such sites. > > Public archives render all email addresses as jpegs. > > If they're automatically generated, it'd be easier to create pngs or gifs, > or lots of other formats than jpgs. Think about this, though--how do you > actually generate the images and serve them properly without either > including the email address in the html code anyway (so the img request > specifies what image to generate), or building a whole database mapping > arbitrary numbers to email addresses (so they can either be generated on > the fly or stored pre-generated). I'd pregenrate them, give them an arbitary name and store a dictionary mapping email addresses to the image for page building purposes. > Once you've got that database, why not > just have that database front a web form instead of displaying the > address? I'm not sure what you mean by this. Can you explain? (Not that I think image addreses are a good idea for all the reasons you mentioned earlier. I'd prefer a slashdot style per user 'display address' option. It can be obfuscated by default, but it allows the user to restore there actual address, or render it unrecognizable depending on there personal spam tolerance threshold.) John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thu, 21 Feb 2002, John Morton wrote: > It's a test to find out if the agent that requested the page is human or some > bot of some sort. Assuming you can build such a test. Good luck. > If the question and answer can be arbitary on a site by site, or better, > hit by hit basis, then it becomes infeasible to build a spambot to enter > such sites. If it's arbitrary, it's generated by some algorithm. If it's generated by some algorithm, I just need to figure out the algorithm and I can always get it. > I'd pregenrate them, give them an arbitary name and store a dictionary > mapping email addresses to the image for page building purposes. > > > Once you've got that database, why not > > just have that database front a web form instead of displaying the > > address? > > I'm not sure what you mean by this. Can you explain? If you've got a database mapping arbitrary number/name/string to an email address, then why not just have a web form that sends mail to that address knowing only the arbitrary value (and never divulge the email address)? > I'd prefer a slashdot style per user 'display address' option. I don't believe any system like slashdot's is worth the time to implement, since it is just as easily broken, and now you've got more useless stuff for every single user to manage. --- Dale Newfield <[EMAIL PROTECTED]> "To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -T. Roosevelt ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
>> It's a test to find out if the agent that requested the page is human or some >> bot of some sort. > > Assuming you can build such a test. Good luck. That some other programmer can't cheat on. Even gooder luck. > If it's arbitrary, it's generated by some algorithm. If it's generated by > some algorithm, I just need to figure out the algorithm and I can always > get it. There is some validity to the "the club" mentality, of "we don't have to fix it, we only have ot make it difficult enough to convince them to annoy someone else". But if we assume we're building the New Defacto Standard Listserver for the Internet here with mailman, that strategy fails, because if we succeed, then it becomes worth their time to find the anti-Club. Security by obscurity only works if you're really obscure, which implies failure of the software to thrive. I'm not interested in that (and even then, you aren't guaranteed success by being obscure). Another way of looking at it is "I don't have to outrun the lion. I only have to outrun you" -- but that doesn't work if the lion is infinitely hungry and doesn't get tire.d Which defines a spambot. I'm more and more ocnvinced the answer is simply putting admins behind a web form, and telling site admins to publicize an emergency address (like postmaster), and putting up a watcher on the system to set off alarms when it breaks. > If you've got a database mapping arbitrary number/name/string to an email > address, then why not just have a web form that sends mail to that address > knowing only the arbitrary value (and never divulge the email address)? Basically, what I'm proposing. And I'm more and more convinced it's the right way to do this, for all that web forms are less personal than sending email directly. I think admins have to make themselves accessible. I don't think they have to make themselves accessible on the user's terms... Another of those tradeoffs. -- Chuq Von Rospach, Architech [EMAIL PROTECTED] -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thursday 21 February 2002 18:08, Dale Newfield wrote: > On Thu, 21 Feb 2002, John Morton wrote: > > It's a test to find out if the agent that requested the page is human or > > some bot of some sort. > > Assuming you can build such a test. Good luck. Building a good one is tricky. It depends on your model of the attacker, and while I've seen some wild speculation of the capabilities of email address harvesters, I don't have any hard facts about the cost/benifit equations they use. > > If the question and answer can be arbitary on a site by site, or better, > > hit by hit basis, then it becomes infeasible to build a spambot to enter > > such sites. > > If it's arbitrary, it's generated by some algorithm. If it's generated by > some algorithm, I just need to figure out the algorithm and I can always > get it. Arbitary as in 'doesn't have to be fixed'. Allowing the site admin the ability to build there own set wouldn't have to involve an algorithm (though I'm spliting hairs, really; I don't think this is a workable idea, either). > > I'd pregenrate them, give them an arbitary name and store a dictionary > > mapping email addresses to the image for page building purposes. > > > > > Once you've got that database, why not > > > just have that database front a web form instead of displaying the > > > address? > > > > I'm not sure what you mean by this. Can you explain? > > If you've got a database mapping arbitrary number/name/string to an email > address, then why not just have a web form that sends mail to that address > knowing only the arbitrary value (and never divulge the email address)? "What if the form breaks down?" :-) Actually, the reason not to use it is that it can be used to spam anyone who's id mapping you can grab from the archive! > > I'd prefer a slashdot style per user 'display address' option. > > I don't believe any system like slashdot's is worth the time to implement, > since it is just as easily broken, and now you've got more useless stuff > for every single user to manage. You've got three statements here, I'll address them one at a time: 1) 'I don't believe any system like slashdot's is worth the time to implement' How hard is it, really. All we're looking at is adding an extra field to the each member record, to the forms for managing user settings, a method to generate a default obfuscation and anther one to substitute addresses in the archive. 2) 'since it is just as easily broken' I never bothered to obfuscate my address, and while I seldom post, I hardly ever recieve spam either (and my address is attached to all sorts of things that are more likely to be harvested). The best we can do is come up with some 'good enough' solutions, and one that offers a user the opportunity to have their address displayed as 'no spam please' is about the best I can think of. Rather than have the whole list exhale great gouts of hot air about what obfuscation methods are broken or not, why don't we do an experiment? Someone should sign up for a couple of email addresses at a free mail service, subscribe to slashdot and post to several stories with each over the month. One account can use their raw email address in each posting, and the other can use some obfuscation method. Then, as the weeks tick by, we can actually see just how useless, or otherwise, obfuscation really is. 3) 'and now you've got more useless stuff for every single user to manage.' If 16 million people can operate the Hotmail UI, I think mailman list users can handle another text field. Especially if it's already filled out for them. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thursday 21 February 2002 18:41, Chuq Von Rospach wrote: > There is some validity to the "the club" mentality, of "we don't have to > fix it, we only have ot make it difficult enough to convince them to annoy > someone else". But if we assume we're building the New Defacto Standard > Listserver for the Internet here with mailman, that strategy fails, because > if we succeed, then it becomes worth their time to find the anti-Club. > Security by obscurity only works if you're really obscure, which implies > failure of the software to thrive. I'm not interested in that (and even > then, you aren't guaranteed success by being obscure). > > Another way of looking at it is "I don't have to outrun the lion. I only > have to outrun you" -- but that doesn't work if the lion is infinitely > hungry and doesn't get tire.d Which defines a spambot. Indeed. Email addresses aren't secrets - even more so than credit card numbers and biometric data - and the attackers have more than enough resources to seek them out. > I'm more and more ocnvinced the answer is simply putting admins behind a > web form, and telling site admins to publicize an emergency address (like > postmaster), and putting up a watcher on the system to set off alarms when > it breaks. For the admin addresses, I'd agree with you. Building up a document of pointers to good spam filtering tools couldn't hurt either. For archives that aren't behind a login, I think slashdot style obfuscation is the best we can do. The list admin can pick the default obfuscation scheme or none at all. Users who want there email address out there for whatever reason can do so, and rely on their 'War and Peace' spam filters to keep the noise down, while other folks can opt in even further and replace the obfuscated email address with some useless string. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
At 0:08 -0500 2/21/2002, Dale Newfield wrote: >> If the question and answer can be arbitary on a site by site, or better, >> hit by hit basis, then it becomes infeasible to build a spambot to enter >> such sites. > >If it's arbitrary, it's generated by some algorithm. If it's generated by >some algorithm, I just need to figure out the algorithm and I can always >get it. Not to mention that people surprisingly often mess up answers to questions as easy as "Who is buried in Grant's Tomb?" --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA Who is buried in Grant's Pass? Many people who lived there, and some who had moved away. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Wed, 20 Feb 2002, Chuq Von Rospach wrote: > > If you've got a database mapping arbitrary number/name/string to an email > > address, then why not just have a web form that sends mail to that address > > knowing only the arbitrary value (and never divulge the email address)? > > Basically, what I'm proposing. And I'm more and more convinced it's the > right way to do this, for all that web forms are less personal than sending > email directly. I think admins have to make themselves accessible. I don't > think they have to make themselves accessible on the user's terms... Another > of those tradeoffs. I was meaning the archives. We have a database describing lists, so we can handle that. -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thu, 21 Feb 2002, John Morton wrote: > Actually, the reason not to use it is that it can be used to spam anyone > who's id mapping you can grab from the archive! That's a separate issue and can have a separate solution. Make the form smart--for example, make it only accept 10 messages from a single IP address in a single day. If we want/expect Maimlan to succeed, then there will be enough incentive for someone to break the obfuscation mechanism. Are you suggesting we restrict access to part of Mailman's source code? Are you suggesting that with the source I can't reverse-engineer every obfuscation (as opposed to information removing) system you try? Why add more points of failure into a system if they don't gain you anything? Basically it looks to me like there ultimately can be no successful obfuscation technique. Why not instead simply remove the information and ONLY provide web-forms? (Again, I'm talking only about archives--I think at least some mailto: is required in case of systemic failures.) -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
At 23:15 -0500 2/20/2002, Dale Newfield wrote: >On Wed, 20 Feb 2002, Damien Morton wrote: >> I still think the email-address-as-jpeg solution is prohibitively >> expensive to reverse; effectively impossible for machines, entirely easy >> for people. > ... > >It can't be enlarged for people that have poor vision. Opera is a counter-example, but doesn't defeat your point. (Tidbits the cat enlarged the web page my Windows laptop was idling on to 200% earlier today in a walk across the keyboard: Opera has keystrokes for nearly everything.) --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> Have you seen what slashdot is doing? unobscured mailto: links? What am I missing? ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> From: Dale Newfield [mailto:[EMAIL PROTECTED]]
>
> On Wed, 20 Feb 2002, Damien Morton wrote:
> > I still think the email-address-as-jpeg solution is prohibitively
> > expensive to reverse; effectively impossible for machines, entirely
> > easy for people.
>
> But it does have drawbacks.
>
> It only works with graphical browsers.
This is true. We are in the 21st century now. Expecting a graphical
client isnt such a huge leap of faith, unless we allow ourselves to be
guided by recidivist or luddite lynx users and their ilk.
> It can't be enlarged for people that have poor vision.
This is true, for the public archives.
> It can be reverse-engineered -- all they have to do is decode
> a single font, then they're all simple to snag.
Assuming you use a single font.
Assuming you don't add some noise to the resulting image.
Assuming you don't do some geometric distortion to the resulting image.
To reverse engineer, a harvester would have to examine pretty much every
image it finds, OCR it with some fantastic military grade image
recognition software, and see if theres an email address buried in
there.
As I said, "prohibitively expensive to reverse"
> In fact, as someone with lots of computer graphics
> experience, I'd say it would be almost no harder to write
> code to decode them than it would be to write code to generate them.
As someone with lots of computer graphics experience, you will probably
know that OCR is hard. Its even harder with a non-cooperating document,
hidden amongst many other documents.
> > Web Forms for contacting the admin cold. If the admin
> replies, you can
> > continue the conversation via email.
>
> Right, assuming the web form doesn't break.
In my experience, the mostly likely route to a web form breaking is if
the email address it sends to breaks.
> > Private and Public views of the archives.
> >
> > Private archives are restricted to list members and those that can
> > pass a reverse turing test.
>
> People keep using this term, but I'm not sure what they mean,
> or if I trust that they'd be so reliable...
Some examples of reverse turing tests. (http://www.captcha.net/)
http://www.captcha.net/cgi-bin/bongo
http://www.captcha.net/cgi-bin/stumpy
http://drive.to/research (this one uses audio)
http://www.captcha.net/gimpy.html
Any of those tests can be implemented in Python using PIL.
Between an audio test and a visual test, you've got the blind and the
deaf covered.
> > Public archives render all email addresses as jpegs.
>
> If they're automatically generated, it'd be easier to create
> pngs or gifs, or lots of other formats than jpgs. Think
> about this, though--how do you actually generate the images
> and serve them properly without either including the email
> address in the html code anyway (so the img request specifies
> what image to generate), or building a whole database mapping
> arbitrary numbers to email addresses (so they can either be
> generated on the fly or stored pre-generated). Once you've
> got that database, why not just have that database front a
> web form instead of displaying the address?
I suggested JPEGs because they are computationally more expensive to
decode than other formats. Also: compression is lossy and adds a certain
amount of noise to an image.
Generating and serving the images would be done as follows:
filename =
md5.new('list-specific-salt-string'+'[EMAIL PROTECTED]').hexdigest() +
'.jpg'
if not exists(filename):
img = render_email('[EMAIL PROTECTED]')
img.save(filename)
Then you relace every occurrence of '[EMAIL PROTECTED]' with '' % filename
Replacing the email addresses with a link to a webform would be another,
perfectly acceptable solution, assuming you can get over your own
objections to web forms.
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thu, 2002-02-21 at 13:28, Damien Morton wrote: > > From: Dale Newfield [mailto:[EMAIL PROTECTED]] > > It only works with graphical browsers. > > This is true. We are in the 21st century now. Expecting a graphical > client isnt such a huge leap of faith, unless we allow ourselves to be > guided by recidivist or luddite lynx users and their ilk. You haven't been following this, have you... Chuq Vos Rospach wrote yesterday in response to Dale's point:- > This is a very good point. I mentioned ADA compliance yesterday. > To be ADA compliant, if you rendered the e-mail address as a graphic, > you'd also have to put the text into the ALT tag. Which would enable > it for lynx and sight-limited solutions -- and make putting into a > graphic kinda meaningless. So you can't use this approach unless you > want to ignore the ADA and lock out your blind users from those > functions. > I'm not willing to make that tradeoff. While I'm not going to live or > die on the ADA compliance issue, I think it's important to keep it in > mind because it forces us to focus on more than the "easy" case or the > "geek" case and worry about solutions that work across the spectrum of > users, from the AOL newbie to Jay. We can't solve problems just for > Jay, or just for Newbies, we have to find a solution that works as > well as possible for as many of those groups as possible. ADA > compliance is a useful strawman that keeps us focussed away from > "I want it this way, so that's the right way". plus enforcing a minimum browser standard (other than minimal text/html) is going to hit deep water with the various PDAs, phones, WAP and other stuff that almost has real browsers on. And insulting lynx users isn't a way to increase your expected life span. Go do something less controversial like arguing the advantages of vi in the emacs news groups. Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ Phone: +44 1423 85 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> From: Nigel Metheringham > > > > From: Dale Newfield [mailto:[EMAIL PROTECTED]] > > > It only works with graphical browsers. > > > > This is true. We are in the 21st century now. Expecting a graphical > > client isnt such a huge leap of faith, unless we allow > ourselves to be > > guided by recidivist or luddite lynx users and their ilk. > > You haven't been following this, have you... I have actually, although I do admit I probably stepped over the line there. > Chuq Vos Rospach wrote yesterday in response to Dale's point:- > > This is a very good point. I mentioned ADA compliance > yesterday. To be > > ADA compliant, if you rendered the e-mail address as a > graphic, you'd > > also have to put the text into the ALT tag. Which would > enable it for > > lynx and sight-limited solutions -- and make putting into a graphic > > kinda meaningless. So you can't use this approach unless > you want to > > ignore the ADA and lock out your blind users from those functions. Chuq, you wouldn't have to do this if it rendered the purpose of emails-as-jpegs invalid. > > I'm not willing to make that tradeoff. While I'm not going > to live or > > die on the ADA compliance issue, I think it's important to > keep it in > > mind because it forces us to focus on more than the "easy" > case or the > > "geek" case and worry about solutions that work across the > spectrum of > > users, from the AOL newbie to Jay. We can't solve problems just for > > Jay, or just for Newbies, we have to find a solution that works as > > well as possible for as many of those groups as possible. ADA > > compliance is a useful strawman that keeps us focussed away from "I > > want it this way, so that's the right way". > > plus enforcing a minimum browser standard (other than minimal > text/html) is going to hit deep water with the various PDAs, > phones, WAP and other stuff that almost has real browsers on. I have been proposing the use of advanced browser standards for the 'public' archives, i.e. those archives that are accessible to the world, be it users, email harvesters, or the spiders of search engines. Making a private archive available to those who are list members or who are willing to authenticate themselves as human, and making the private archive plain unobfuscated text should mean that everyone is at least able to get what they need, if only after jumping through some hoops. Those hoops could be a visual test, an audio test, or a list membership test (which depends on having provided a valid email address). Further, the public archive would differ from the private archive only by the obfuscation of email addresses. That would be the only difference. I wonder if the ADA would accept the need to obscure email addresses, and I wonder if they would accept the extra authentication step required to get at the unobscured email address? Would they understand that it protects all mailman users, including the disabled? Would Lynx users and other browser-disadvantaged users accept the extra authentication/authorisation step to get at the unobscured email addresses? Would they understand that it protects _them_ as well? > And insulting lynx users isn't a way to increase your > expected life span. Go do something less controversial like > arguing the advantages of vi in the emacs news groups. Agreed, appologies to recidivists, luddites and lynx users :) ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thu, 21 Feb 2002, Damien Morton wrote: > Making a private archive available to those who are list members I haven't commented on this before, but the reason I find this solution lacking is that most mailman lists (in my experience) don't require list admin permission to join. If this is the hurdle, as a spammer I'd just create a hotmail account that I can automatically subscribe to any mailman mailing list, and then gain access to the honeypot. -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thu, 21 Feb 2002, Damien Morton wrote: > OCR is hard OCR is hard mostly because of the analog components (and the variety of fonts that exist). If you are generating the image digitally (and with a limited set of fonts), most of the OCR problems go away. > Some examples of reverse turing tests. (http://www.captcha.net/) It appears that each of those introduces non ADA compliant aspects. The first and third can be defeated with a database no larger than that needed to implement it, the third is unlikely to work on many platforms (audio dependancies kept it from working for me), and the fourth I couldn't even figure out as a human--not what we're looking for. > Between an audio test and a visual test, you've got the blind and the > deaf covered. And you've introduced lots of browser/platform dependancies that mean you can't use new low-bandwidth platforms, like WAP. -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On 2/21/02 5:28 AM, "Damien Morton" <[EMAIL PROTECTED]> wrote: >> It only works with graphical browsers. > > This is true. We are in the 21st century now. Expecting a graphical > client isnt such a huge leap of faith, unless we allow ourselves to be > guided by recidivist or luddite lynx users and their ilk. Or those who are sight-limited and using talker browsers, but the heck with the blind and aged, we don't need them anyway. Or those on wireless browsers, like cell phones, PDA's, blackberries and the like. And those can be ignored, they're merely the fastest growing segment of the industry. (grin) -- Chuq Von Rospach, Architech [EMAIL PROTECTED] -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> From: Dale Newfield > > On Thu, 21 Feb 2002, Damien Morton wrote: > > OCR is hard > > OCR is hard mostly because of the analog components (and the > variety of fonts that exist). If you are generating the > image digitally (and with a limited set of fonts), most of > the OCR problems go away. Youre assuming a simplistic implementation. The use of a single font, and the absence of noise or distortion. At any rate, its certainly much harder than writing a perl regex, both in terms of brainpower and in terms of computing power required. > > Some examples of reverse turing tests. (http://www.captcha.net/) > > It appears that each of those introduces non ADA compliant > aspects. The first and third can be defeated with a database > no larger than that needed to implement it, the third is > unlikely to work on many platforms (audio dependancies kept > it from working for me), and the fourth I couldn't even > figure out as a human--not what we're looking for. Youre assuming a simplistic implementation; a database of words and images. A sophisticated implementation would generate images from random words with random distortions added, sounds by overlaying random words with random backgrounds. You've also ignoring the third test, which is list membership. If youre not capable of passing the reverse turing tests offered, you can always join the list for unobscured access. > > Between an audio test and a visual test, you've got the > blind and the > > deaf covered. > > And you've introduced lots of browser/platform dependancies > that mean you can't use new low-bandwidth platforms, like WAP. You're ignoring the third test offered, which is list membership. 'enter your email address and password here'. Between the three kinds of tests, a person who desires at least the same functionality as is offered today, can do so, no matter what platform they are on. Let me reiterate that what is being proposed here is the obscuration of email addresses in the public archives; that is, the archives available to the world for casual inspection. Perhaps it might be fruitfull to look at omitting the email addresses in the public archives entirely. That would certainly be ADA compliant, and would be useable by anyone with any html 1.0 capable browser. As I see it, the questions are: Is it desireable to prevent the whole world seeing email addresses in mailman archives? If yes then should there be public and private archives, with the public archive obscuring addresses? if yes how should the access to the private archives be controlled? list membership? reverse truing tests? other? what should go into the public archives? obscured email? email as images? text based obfuscation? links to web form email? omit email addresses entirely? other? else if no should an obfuscation scheme be used at all? if yes what obfuscation scheme(s) should be used? obscured email? email as images? text based obfuscation? links to web form email? omit email addresses entirely? other? else if no talking in circles else if no end of conversation ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thu, 21 Feb 2002, Damien Morton wrote: > should an obfuscation scheme be used at all? > if yes > what obfuscation scheme(s) should be used? > obscured email? > email as images? > text based obfuscation? > links to web form email? > omit email addresses entirely? > other? The two I marked with () above are not obfuscation schemes. They involve not the obfuscation of information, but rather it's removal. (While there are reasons webforms are evil, they still provide a way to contact people whose email addresses have been removed.) This is what I am advocating. -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thu, Feb 21, 2002 at 08:28:13AM -0500, Damien Morton wrote: > > On Wed, 20 Feb 2002, Damien Morton wrote: > > > I still think the email-address-as-jpeg solution is prohibitively > > > expensive to reverse; effectively impossible for machines, entirely > > > easy for people. > > > > But it does have drawbacks. > > > > It only works with graphical browsers. > > This is true. We are in the 21st century now. Expecting a graphical > client isnt such a huge leap of faith, unless we allow ourselves to be > guided by recidivist or luddite lynx users and their ilk. And Chuq says *I'm* arrogant. There are lots of people who run their graphical browsers with J/Jscript off for security and images off for the same reason (much faster browsing) that I use Lynx. And see above about wireless browsers, and below about the blind. And get the phuque over yourself. > > It can't be enlarged for people that have poor vision. > > This is true, for the public archives. > > > It can be reverse-engineered -- all they have to do is decode > > a single font, then they're all simple to snag. > > Assuming you use a single font. > Assuming you don't add some noise to the resulting image. > Assuming you don't do some geometric distortion to the resulting image. > > To reverse engineer, a harvester would have to examine pretty much every > image it finds, OCR it with some fantastic military grade image > recognition software, and see if theres an email address buried in > there. It doesn't matter, really. > As I said, "prohibitively expensive to reverse" And just imaging -- yet another way to make 15 bytes into 15 kilobytes. Yeah, the network operators oughtta like that. You get a commission? > Replacing the email addresses with a link to a webform would be another, > perfectly acceptable solution, assuming you can get over your own > objections to web forms. We seem to keep conflating the "admin mailto problem" with the "list member mailto problem"; they have fairly widely diverging solutions. Could we please be a bit more cautious about that? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Friday 22 February 2002 05:28, Dale Newfield wrote: > On Thu, 21 Feb 2002, Damien Morton wrote: > > Making a private archive available to those who are list members > > I haven't commented on this before, but the reason I find this solution > lacking is that most mailman lists (in my experience) don't require list > admin permission to join. If this is the hurdle, as a spammer I'd just > create a hotmail account that I can automatically subscribe to any mailman > mailing list, and then gain access to the honeypot. I think we're really getting into wild speculation territory here. No one will bother hacking the code to automatically get new free mail accounts (this requires staying up to date with some range of mail service's cgi interface for their join function), automatically join any mailing list they find (same problem as before, coupled with having an automated way of finding lists to plunder), then going through the usual email confirmation step (ok, not hard if your mail service lets you pop mail from them). No one is going to bother implementing and maintaining this attack while they can grep addresses straight out of Usenet, off the web and out of DNS. If at some point in the future, those sources dry up, then it might be time to rearm. If there's compeling evidence that private archives and voluntary address obfuscation methods are failing, then it's time to rearm. But let's just keep in mind that this will always be an arms race, and that at the end of the day, it's only junk mail. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thu, Feb 21, 2002 at 09:23:51AM -0800, Chuq Von Rospach wrote: > This hits another aspect of my design philosophy. Don't sweat making one > part of the system more secure than the other parts. And very well phrased. > In this case, you hit a nail on the head. If a spammer really, really wants > your subscribers, we can't stop him. They can simply subscribe to a list and > harvest it as it comes across. Unless you choose to anonymize every bloody > message -- a spammer will win if they're motivated enough, and a smart > spammer will do so in a way you'll never find. Like setting up a hotmail > address for each list, so you can't see that all 30 lists have the same > address in common, and simply reading messages as they come by. > > And since, inherently, you can't stop THAT, it makes no sense to make > archives more secure than that. Any spammer smart enough to be willing to > subscribe to a list to do their harvesting, you're going to have a very > tough time stopping. Basically, you have to get lucky or hope they make a > mistake or some sort. My problem is with your characterization of that as "smart". I don't think that requires a whole helluva lot of brains, myself. > Yes, I am an agent of Satan, but my duties > are largely ceremonial. Are you the guy who goes in the convenience store to get him cigarettes? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thu, Feb 21, 2002 at 10:27:08AM -0500, Damien Morton wrote: > I wonder if the ADA would accept the need to obscure email addresses, > and I wonder if they would accept the extra authentication step required > to get at the unobscured email address? Would they understand that it > protects all mailman users, including the disabled? Stunningly unlikely... > Would Lynx users and other browser-disadvantaged users accept the extra > authentication/authorisation step to get at the unobscured email > addresses? Would they understand that it protects _them_ as well? If each page had a link to the version of that same page that required authentication, so that I wouldn't have to go do a whole-nother damned search, yeah... > > And insulting lynx users isn't a way to increase your > > expected life span. Go do something less controversial like > > arguing the advantages of vi in the emacs news groups. > > Agreed, appologies to recidivists, luddites and lynx users :) Nice to know that you understand now that those are three separate groups. :-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> From: Jay R. Ashworth > > On Thu, Feb 21, 2002 at 10:27:08AM -0500, Damien Morton wrote: > > I wonder if the ADA would accept the need to obscure email > addresses, > > and I wonder if they would accept the extra authentication step > > required to get at the unobscured email address? Would they > understand > > that it protects all mailman users, including the disabled? > > Stunningly unlikely... Would they accept it if the email addresses were omitted in the public archives, and an extra authentication step required to get into the private archives. These might be a questions better answered by the ADA themselves. > > Would Lynx users and other browser-disadvantaged users accept the > > extra authentication/authorisation step to get at the > unobscured email > > addresses? Would they understand that it protects _them_ as well? > > If each page had a link to the version of that same page that > required authentication, so that I wouldn't have to go do a > whole-nother damned search, yeah... Cookies can be your friend. Remember, we arent talking about putting obstacles in the way of getting access to pages, but merely to pages that contain raw email addresses. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
At 12:15 -0500 2/21/2002, Dale Newfield wrote: >The two I marked with () above are not obfuscation schemes. >They involve not the obfuscation of information, but rather it's removal. Oh, good...another debating point. Is removal the limiting case of obfuscation, or something different in kind? ;-) --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Friday 22 February 2002 11:20, Chuq Von Rospach wrote: > On 2/21/02 2:00 PM, "John Morton" <[EMAIL PROTECTED]> wrote: > > I think we're really getting into wild speculation territory here. No one > > will bother hacking the code to automatically get new free mail accounts > > [...] > > Nobody has bothered to do this YET. That we know of. But the spamhacks are > evolving rapidly. Well, let's find out shall we? Set up a honeypot private list containing a collection of free mail accounts, then cycle through the account every week checking for spam and making some postings to keep the traffic up. Enough with the armchair anthropology, already! > More rapidly than the anti-spam hacks in many ways. I > sure wouldn't depend on them never doing this. I agree. That's because we're in an arms race here. Email harvesters are probably evolving faster than the countermeasures because of the tendency to deploy one countermeasure and forget about it. > I'm not sure what we'd do if > they did, either, but some aspects of it have happened to me in small ways, > just not from the major spamhacks. So basically you need to deploy a countermeasure, monitor it's effectiveness, and deploy another when it fails. Repeat for as long as you consider it important, or can tolerate not resorting to private archives, and establishing better trust relationships with the subscribers. > Fact is, if they want your subscribers, they can get them. Or more > correctly, your subscribers that post -- but if everyone lurks in fear, why > hav a mail list? I think we all need to take a deep breath and say 'It's only junkmail'. They're not spending up large on your credit card or pouring sugar into your gas tank. > The question is, what can we do to make it as tough as we > can for the spammers, without screwing it up for us (as admins) or our list > users. If only because the harder we make it for them to hack us, they more > likely they'll go somewhere else that's easier to crack... Right. So let's go with contact forms for list admins, and slashdot style, per user configurable address mangling for the archives. Let's do a little research into the ongoing effectiveness of these methods, too, so we know when it's time to implement something more expensive. > On the other hand, if Mailman does become the de-factor mail list standard, > or one of a couple of key list servers, you can bet the spam ahcks will > focus on it, because if they can crack the code, they can crack a LOT of > lists really fast. So we have the potential to become a target of our > success, and we should be aware of that. It's probably one of the top three or four already. Do listserv and majordomo admins have a major spam problem? The two above techniques will work fine. If I, as a list subscriber feel that the signal to noise ratio is dropping, I can change my address mangling scheme. Hiding the otherwise web published list admin address behind a form should just about protect it by that vector for all time as it will just never be worthwhile hitting a collection of forms when you can get vast lists of addresses elsewhere. (of course you have to publish the mailing list address, so you can deduce the admin address from that...:-) > But what happens when other groups get smart too, and clean up the low > hanging fruit? Depending on that to protect us is a false security, > basically no better than the old security-by-obscurity issue. Given port > scanners and the like, there IS no obscurity from the crackers any more. The problem with obscurity as a security tool is that it's not reliable. You may as well assume that one day your secret will be out, so the decision as to where and how to deploy it needs to be made based on the cost of obscuring, the cost of having the information revealed, the cost of reimplementing the system to replace the obscured part, and the size of the window of opportunity created before you can fix the problem. Passwords, passphrases, keys and so forth are all examples of security through obscurity. They work because it's very easy to replace them; they work most effectively in systems that are good at detecting that they've been compromised. Striping identity strings from network daemons is another security through obscurity technique. No one would rely on it to protect them, but it does make the job harder for attackers and easier for the defenders - they have to try a lot more things to detect what software is behind the port, or just brute force it with known attacks, greatly increasing the detection and response time available to defenders. Obscurity is useful. In our case, it's the only prevention tool we have. Email addresses are not secrets, but we still want to protect them from the bad guys while making them available to the good guys. We will never solve this problem. Even if you made all the subscribers sign a contract promising not reveal the addresses of the list membership to non-
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Fri, 22 Feb 2002, John Morton wrote: > The best we can do here is implement something simple now that gets the > job done, and continuously test it to see if it's still good enough. > When it's not, we build another countermeasure. I completely disagree. You argue for job security. I argue for better software. Temporary solutions are not solutions. -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Friday 22 February 2002 18:36, Dale Newfield wrote: > On Fri, 22 Feb 2002, John Morton wrote: > > The best we can do here is implement something simple now that gets the > > job done, and continuously test it to see if it's still good enough. > > When it's not, we build another countermeasure. > > I completely disagree. You argue for job security. I argue for better > software. Temporary solutions are not solutions. Ok. Show me a solution that will protect list administrator addresses and publicly accessable list archives from email harvesting, while allowing list subscribers and members of the public the ability to contact the list admin in the event of a list related problem and allowing them to contact an individual personally in response to some message in the archive. The solution must not penalize text only web browser users, or the disabled, nor should it open up any other vectors for unsolicited mass emailing. I'd really like to see one. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Fri, 22 Feb 2002, John Morton wrote: > Ok. Show me a solution The point is that adding layer after layer of temporary solutions doesn't add up to an actual solution any more than not adding those layers. All it does add is more complexity to manage, more code to write and test, more annoyance to anyone trying to use the system, and more potential points of failure. Separate archives (public stripped of anything that looks like an email address, private unmodified), and an equivilant "give me archive access" path to the subscription path (through email) as has been suggested seems to be the best solution yet. -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Friday 22 February 2002 18:58, Dale Newfield wrote: > On Fri, 22 Feb 2002, John Morton wrote: > > Ok. Show me a solution > > The point is that adding layer after layer of temporary solutions doesn't > add up to an actual solution any more than not adding those layers. All > it does add is more complexity to manage, more code to write and test, > more annoyance to anyone trying to use the system, and more potential > points of failure. This depends on just how temporary your 'solution' turns out to be, and it's level of complexity and usability. I don't think anyone has really advocate any really kludgy hacks so far. > Separate archives (public stripped of anything that > looks like an email address, private unmodified), and an equivilant "give > me archive access" path to the subscription path (through email) as has > been suggested seems to be the best solution yet. Not bad; it looks fairly easy to implement. I'd build the archive access to be just like regular list access, except delivery is turned off by default, to keep it simple. The problem is that if you accept that those nefarious agents of mass email will start auto-joining lists and plunder the private archive and message feed for addresses sometime in the future, then you have to implement another layer of hackery to detect and block that sort of thing. Does that make your suggestion any less of an actual solution? :-) I'd still go as far as adding per user configurability for address display so people can adjust the option to suit there own level of hysteria. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Fri, 22 Feb 2002, John Morton wrote: > The problem is that if you accept that those nefarious agents of mass > email will start auto-joining lists and plunder the private archive and > message feed for addresses sometime in the future, then you have to > implement another layer of hackery to detect and block that sort of > thing. Does that make your suggestion any less of an actual solution? > :-) As was already pointed out, if the spambots get smart enough to subscribe, they don't need the archives--they just have to wait for the addresses to appear in their mailboxes. So once they've cleared that hurdle, nothing you do to the archives will help one bit. > I'd still go as far as adding per user configurability for address > display so people can adjust the option to suit there own level of > hysteria. That adds tremendous management headaches for both users and admins, as well as difficult coding problems (since whenever one subscriber quotes another you need to figure that out and do multiple "how should I obfuscate YOUR email adress?" lookups). Why not just ignore this non-solution and save everyone the headaches? -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Fri, 22 Feb 2002, John Morton wrote: > Not bad; it looks fairly easy to implement. I'd build the archive access > to be just like regular list access, except delivery is turned off by > default, to keep it simple. I thought about that, but do you really want to send monthly password reminders to people that just wanted to look at the archives? (Or do we not send those to people with "nomail" set?) -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
I repeat myself, but only Chuq seems to have noticed the other post. > "John" == John Morton <[EMAIL PROTECTED]> writes: John> This depends on just how temporary your 'solution' turns out John> to be, and it's level of complexity and usability. I don't John> think anyone has really advocate any really kludgy hacks so John> far. AFAICT both the trivial /. style obfuscation and the image style obfuscation are kludges because they ignore the statistical nature of harvesting. This works in two ways. First, since addresses are typically repeated but obfuscated in different ways, the probability that a given address gets harvested is much higher than the probability that any given obfuscated instance gets cracked. Second, you don't need to get 100% recognition, you don't even need to get 10% recognition, as long as you can process the bytes as fast as they come off the wire _and_ the number of harvested new addresses per megabyte is high enough. There is a third, "equilibrium" problem with obfuscation. Image obfuscation has the serious drawback that it looks "provably secure" if you don't think about it carefully. If this encourages lots more people to post real addresses, the value of the harvest rises proportionately and thus obfuscation decreases achieved security. I conclude that if obfuscated archives give a reasonable number of addresses per megabyte, and those addresses are drawn from a population that is not represented in other sources, spammers _will_ find cheap and dirty ways to achieve recognition, and then they will compete to improve it. People have seriously advocated obfuscation, especially images. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 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. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> From: Stephen J. Turnbull > > First, since addresses are typically repeated but obfuscated > in different ways, the probability that a given address gets > harvested is much higher than the probability that any given > obfuscated instance gets cracked. Second, you don't need to > get 100% recognition, you don't even need to get 10% > recognition, as long as you can process the bytes as fast as > they come off the wire _and_ the number of harvested new > addresses per megabyte is high enough. > > > > I conclude that if obfuscated archives give a reasonable > number of addresses per megabyte, and those addresses are > drawn from a population that is not represented in other > sources, spammers _will_ find cheap and dirty ways to achieve > recognition, and then they will compete to improve it. > > People have seriously advocated obfuscation, especially images. So obfuscation is imperfect, and the more effective it is, the more value there is in cracking it. Would you say, then, that youre advocating public and private list archives, with email addresses omitted from the public archives, and the private archives available to list members only? Im not clear on what your position is. A while ago, I laid out the decision/position tree, as I saw it. Only one person has clearly located their position in/on that tree, so I repeat it again. Im very interested to see where list members might locate their position in this decision tree. Please eel free to alter the tree, should your position not be included. Is it desireable to prevent the whole world seeing email addresses in mailman archives? If yes then should there be public and private archives, with the public archive protecting addresses? if yes how should the access to the private archives be controlled? list membership? (damien) reverse truing tests? (damien) other? what should go into the public archives? obfuscated email? email as images? (damien) text based obfuscation? links to web form email? (damien) omit email addresses entirely? other? else if no should an address protection scheme be used at all? if yes what protection scheme(s) should be used? obscured email? email as images? text based obfuscation? links to web form email? (dale) omit email addresses entirely? (dale) other? else if no talking in circles else if no end of conversation ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> "Damien" == Damien Morton <[EMAIL PROTECTED]> writes: Damien> So obfuscation is imperfect, and the more effective it is, Damien> the more value there is in cracking it. That's true, but that's not what I said. What I said is it is weak enough that a small amount of effort brings some payoff to harvesting, and the more effort, the higher the payoff. Furthermore, even though it is therefore not very effective, it's easy to convince yourself it is, and this _perception_ generates more value for spammers. Damien> Im not clear on what your position is. My position is that (1) obfuscation is unlikely to last 6 months after it becomes widespread, and (2) it is an unsatisfactory method for inclusion as a standard in Mailman, because it is costly to develop, and costly to all the legitimate users both in immediate inconvenience and in false sense of security, while probably not slowing down the spammers much. Beyond that, I don't have a position; I plan to ask my subscribers/ posters how they feel about it, and treat my own lists accordingly. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 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. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Fri, Feb 22, 2002 at 09:16:20AM -0500, Damien Morton wrote: > Is it desireable to prevent the whole world seeing email addresses in > mailman archives? > If yes then > should there be public and private archives, with the public > archive protecting addresses? > if yes > how should the access to the private archives be > controlled? > list membership? (damien) > reverse truing tests? (damien) > other? > what should go into the public archives? > obfuscated email? > email as images? (damien) > text based obfuscation? > links to web form email? (damien) > omit email addresses entirely? > other? > else if no > should an address protection scheme be used at all? > if yes > what protection scheme(s) should be used? > obscured email? > email as images? > text based obfuscation? > links to web form email? (dale) > omit email addresses entirely? (dale) > other? > else if no > talking in circles Well, this is where I sit -- and please note that I'm discussing *implementation of actual lists*, not *what facilities I think Mailman should provide*; if you feel this invalidates my opinion, so be it -- and I think that characterizing it as "talking in circle" is a bit digingenuous, at best. Please expand. > else if no > end of conversation Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> "CVR" == Chuq Von Rospach <[EMAIL PROTECTED]> writes: >> (Or a header that can be set to cause a message not to get >> archived?) CVR> That already exists -- X-No-Archive, which I believe CVR> pipermail understands. Mailman's interface to Pipermail is what does this check, currently defined as: X-No-Archive: yes X-Archive: no prevents the message from being archived in any way. I don't think there are standards for this particular header (else, why would it be an X- header?), so I'm wondering if I understand common practice well enough. I.e. should the presence of X-No-Archive: itself, regardless of value, prevent archiving of the message? -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> "JRA" == Jay R Ashworth <[EMAIL PROTECTED]> 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 ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> "JRA" == Jay R Ashworth <[EMAIL PROTECTED]> 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 . I'll follow up shortly with some other thoughts in this thread. -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> "DN" == Dale Newfield <[EMAIL PROTECTED]> writes: DN> I thought about that, but do you really want to send monthly DN> password reminders to people that just wanted to look at the DN> archives? (Or do we not send those to people with "nomail" DN> set?) We send password reminders to folks regardless of their delivery status. This actually makes sense in a VERP world because since password reminders are by nature personalized, we can piggyback the more accurate VERP bounce detection onto them. Note that in MM2.1, people can turn off password reminders altogether. -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Mon, Feb 25, 2002 at 10:09:35AM -0500, Barry A. Warsaw wrote: > Mailman's interface to Pipermail is what does this check, currently > defined as: > > X-No-Archive: yes > X-Archive: no > > prevents the message from being archived in any way. I don't think > there are standards for this particular header (else, why would it be > an X- header?), so I'm wondering if I understand common practice well > enough. I.e. should the presence of X-No-Archive: itself, regardless > of value, prevent archiving of the message? This depends on which side of the "enabler" argument, discussed ad nauseum last week, you come down on. :-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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 . > 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[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
> "JRA" == Jay R Ashworth <[EMAIL PROTECTED]> 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 ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Mon, Feb 25, 2002 at 09:23:59AM -0800, Chuq Von Rospach wrote: > On 2/25/02 8:56 AM, "Jay R. Ashworth" <[EMAIL PROTECTED]> 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[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
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[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://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") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
