Howdy, ya'll. Back from vacation, and opening up a few can o' worms (gotta big can opener here!) for everyone to chew on.... Apologize if this goes all over the map, a bunch of things have been simmering and I want to pass them along to get your perspective, see if they are issues that ought to be considered in Mailman somehow, and perhaps warn you of stuff I'm seeing before it hits you...
First, a minor announcement. I'm no longer in charge of the mailing lists at apple, sort of. We've hired a person full-time, and he's been taking over the lists server as his full-time responsibility, allowing me to go off and work on other projects. I'm still in the loop, just not "it". I'm still going to be heavily involved as we move that box to Mailman 2.1, and after that, probably fade a bit more into the woodwork (I still run my Mailman box at home, however, so I'm not going away. JC, quite jeering)
Anyway, on to issues more substantive.
With the explosion of spam, privacy issues and protection issues have been of great interest around here, including fascinating (but not family friendly) discussions with our legal beagles.
The end result of all of that is a decision that subscriber e-mail addresses are considered a significant asset that needs to be protected to the greatest extent possible. We're currently evaluating exactly what that means (and it means the list rules/T&Cs are going to need to be revamped as well, in ways we're still figuring out) to do what we can to make sure people who post to the mailing lists don't get harvested.
One thing we're definitely doing is moving to a cloaked archive. Since we already distribute all archives out of HTTP, not FTP, we're working on a CGI that'll strip all e-mail information out of messages on the fly (among other things, like header cleanup and some trivial formatting fixes). The idea is simple -- we've finally hit the point where you can't put an e-mail address up on a public site under any cirucmstance safely, so we're having to move to a system where we simply don't do that.
I think the Mailman stuff needs to think about this, also. It impacts the archiving setup and other issues, but the harvesters have hit the point where we simply can't risk disclosing that info. It creates other problems -- you can't see a posting in the archive and send email to that person with more questions (or answers), but that seems trivial compared to the problems the spammers are causing.
A secondary issue here is the problem of disclosing admins and admin addresses. I know we've hashed that through once, but we've come to the (somewhat reluctant) decision to whitelist all public, non-personal email addresses. We're going to be implementing TMDA to do this, and will be switching all admin to generic addresses that filter through TMDA, as well as things like postmaster@ and the like. While I hate making users jump through hoops to get through to a real person (for those that don't know, TMDA is an overt whitelist. If you're not on the whitelist, you get mail back telling you to take some action, and until you do, the mail isn't delivered), but the abuse by the spammers on admin addresses is now so bad I'm declaring defeat and going to the whitelist.
I'm going to look and see if I can interface TMDA to the subscriber databases so that subscribers are by definition whitelisted, but we've hit the poiint where we have to do this. I'm not happy about it, but the war is lost, I think.
And speaking of privacy, harvesting and spamming, a new and disturbing thing happened this weekend that I want to bring up -- one for which I have lots of questions, but no real answers. A bunch of users on some of our mail lists were spammed, and it became very clear very quickly that addresses were harvested off of at least one of our mail lists.
As you might guess, a lynch mob formed, and I lit the first virtual torch and we all sharpened the pitchforks. Fortunately, the person who did it came forward to me and admitted guilt, and explained what happened.
And what happened is pretty damn disturbing. See, he had one of those "I must tell the masses!" moments, where he finally felt it was time to send out a call to arms on a subject he felt strongly about.
So what he did was open up his address book and send his message to everyone in it. And he's running one of these new e-mail clients that happily caches addresses it sees in case you want them again. So all of the addresses of people posting to the mailing lists he subscribed to were in his address book cache, so when he grabbed his address book, he grabbed all of those addresses, too.
So we have a clear violation of our anti-harvesting rules -- yet he didn't overtly harvest. He just grabbed what was in his address book at the time.
This creates a major privacy quagmire. How do you set up rules for something like that? Where does ownership and protection end? (I'm talking ethically, not technically. I think we all realize that once someone posts email to a list, you've given up control to anyone who doesn't feel obligated to follow the rules). This wasn't a case of overtly violating the rules, but of a piece of technology creating a situation where it wasn't understood there were rules being violated.
I just don't know how to deal with the issues this address caching causes. Ultimately, we're going to have to rethink our "no harvesting" rules, and likely also write disclaimers explaining what our limits are. We've actually considered switching our lists to obscured addresses, turned that down as being worse than the disease (for now). But now we're wondering if we have to go to some sort of address cloaking ON lists, maybe some kind of address remapping through the server for replies, something. And I'm gritting my teeth at the developers who created those @#$@$#@$#23 caches (which are nice in some ways) for not also creating some way to flag addresses as not cacheable. Because, IMHO, that'd solve this problem.
But they didn't. Grumble.
I'm curious what people think about this latest thing. The good news is he wasn't trying to harvest us. The bad news is, he wasn't trying to harvest us. And the b-tch of it is, I really don't have a comfortable feeling for how to deal with this new situation yet... But I think it's an issue we have to come to grips with.
Are we hitting a point where mail list servers have to act as blind front ends for all of the subscribers, where replies are processed by those servers, and the server then takes on the job of acting as a troll-exterminator and spam blocker? And what does that really mean for things like Mailman?
Happy Macworld Expo week, all. If you need me, I'll be in the war room, beating my head against a wall.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
He doesn't have ulcers, but he's a carrier.
At 10:58 -0700 7/16/2002, Chuq Von Rospach wrote:
Are we hitting a point where mail list servers have to act as blind front ends for all of the subscribers, where replies are processed by those servers, and the server then takes on the job of acting as a troll-exterminator and spam blocker? And what does that really mean for things like Mailman?
I don't think so, quite yet. But I think we've reached the point that it is prudent for a user to use a different throwaway address for each different place one exposes one's address. (The address I use here isn't unique, but it is throwaway. And it isn't badly spammed yet.)
And we've reached the point that it's probably imprudent to gate mailing lists and Usenet (which we've never done anyhow).
I use an @spamcop.net address on Usenet...I get the distinct impression that most harvesters don't bother with those.
I think the issue is larger than just mailing lists: SMTP-based email will be unusable soon. The replacement will be something permission based with electronic signatures involved, and some TMDA-like way to get started conversing with someone.
--John the Disgusted
-- John Baxter jwblist@olympus.net Port Ludlow, WA, USA
On 7/16/02 12:19 PM, "John W Baxter" <jwblist@olympus.net> wrote:
I don't think so, quite yet. But I think we've reached the point that it is prudent for a user to use a different throwaway address for each different place one exposes one's address. (The address I use here isn't unique, but it is throwaway. And it isn't badly spammed yet.)
Problem is, many users don't know how. And one could argue who ought to solve this problem. Should users be forced to jump through hoops to use a mail list safely? Or is it the user's decision how safe to be? I could make a pithy comparison between spammers, computer viruses, AIDS and safe sex, but you'd all throw veggies at me.
And we've reached the point that it's probably imprudent to gate mailing lists and Usenet (which we've never done anyhow).
Agreed, unless it's carefully controlled. We gateway only to internal, private lists.
I think the issue is larger than just mailing lists: SMTP-based email will be unusable soon.
No, but it has to adapt and evolve. Quickly.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> Problem is, many users don't know how. And one could argue
CVR> who ought to solve this problem. Should users be forced to
CVR> jump through hoops to use a mail list safely? Or is it the
CVR> user's decision how safe to be? Nope, I think it's the ISPs that will solve the problem, although it might be in ways mom-and-pops don't like.
-Barry
On 7/16/02 2:46 PM, "Barry A. Warsaw" <barry@zope.com> wrote:
Nope, I think it's the ISPs that will solve the problem, although it might be in ways mom-and-pops don't like.
Actually, the mom and pops will love it. It's us geeks who whine on slashdot about stuff who'll hate it, because the ISPs will solve it for the moms and pops, and those of us capable of and willing to handle it ourselves won't have that option any more...
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Stress is when you wake up screaming and you realize you haven't fallen asleep yet.
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
>> Nope, I think it's the ISPs that will solve the problem,
>> although it might be in ways mom-and-pops don't like.
CVR> Actually, the mom and pops will love it. It's us geeks who
CVR> whine on slashdot about stuff who'll hate it, because the
CVR> ISPs will solve it for the moms and pops, and those of us
CVR> capable of and willing to handle it ourselves won't have that
CVR> option any more...That's kind of what I meant by the "moms-and-pops", i.e. the little guys, anybody not on a big ISP. I predict that AOL, Microsoft, the cable companies, and the content industry will decide How It Shall Be -- likely involving secure hardware -- and we simply won't be able to (or want to) play by their rules.
-Barry
At 17:46 -0400 7/16/2002, Barry A. Warsaw wrote:
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> Problem is, many users don't know how. And one could argue CVR> who ought to solve this problem. Should users be forced to CVR> jump through hoops to use a mail list safely? Or is it the CVR> user's decision how safe to be?
Nope, I think it's the ISPs that will solve the problem, although it might be in ways mom-and-pops don't like.
I don't think the ISPs *can* solve the problem in the near-to-medium-term future. [Longer term, with the demise of SMTP and its "everything open to all except for a few bandaids" approach, maybe.]
At some point, the SpamAssassin/quarantine model breaks down...when you quarantine 10 large messages to let one smaller message go through, you're somewhere close to that point. As it is, we're busily installing four machines to do the work that one would do quite well in the absence of spammers (and they'll have help from another machine or two so that users can see their quarantined mail and rescue their false positives). And yes, SpamAssassin is part of that picture.
Plus, I fear the "new breed" spammers (the ones who actually think their advertising is useful and welcome and only sent to opt-in lists, although they buy the lists from guys who [figuratively] sell them from under a trenchcoat at the entrance to a dark alley) will cause legislation to be passed forbidding filtering at the mail server level. It nearly happened last time around.
Ah, well...we'll see how it goes.
--John
-- John Baxter jwblist@olympus.net Port Ludlow, WA, USA
Not to get too far OT here but...
I've seen the next generation of spammer software at work recently. Spammer's machine makes direct SMTP connection to my box, gives MY address as the FROM:, TO:, and REPLY-TO:. This bypasses all the open relay testing, and would only leave stuff like SA to detect it.
Bob
On 7/16/02 5:35 PM, "Bob Puff@NLE" <bob@nleaudio.com> wrote:
I've seen the next generation of spammer software at work recently. Spammer's machine makes direct SMTP connection to my box
Actually, the REAL state of the art is that they look up your MX records, and do this to the HIGHEST ranked one (not the lowest). This is on the (it turns out, quite valid) assumption that it won't be spamblocked as well as the main MX relay is, but will be validated to forward stuff in to you. And where they're trying that, we're finding it works (grumble grr) damn well.
Which means some of the assumptions we make on allowing, say, me on plaidworks to generate email as chuq@apple.com and forward it to someone at Apple are rapidly becoming obsolete, and how we design our backup MX systems need to be looked at, also.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
No! No! Dead girl, OFF the table! -- Shrek
Actually, the REAL state of the art is that they look up your MX records, and do this to the HIGHEST ranked one (not the lowest). This is on the (it turns out, quite valid) assumption that it won't be spamblocked as well as the main MX relay is, but will be validated to forward stuff in to you. And where they're trying that, we're finding it works (grumble grr) damn well.
Exactly. I didn't state that, but you put it well. But who cares if it's the primary MX or not? If it hits any of my MXs, it will be delivered.
Bob
At 17:28 -0700 7/16/2002, Chuq Von Rospach wrote:
On 7/16/02 5:35 PM, "Bob Puff@NLE" <bob@nleaudio.com> wrote:
I've seen the next generation of spammer software at work recently. Spammer's machine makes direct SMTP connection to my box
Actually, the REAL state of the art is that they look up your MX records, and do this to the HIGHEST ranked one (not the lowest). This is on the (it turns out, quite valid) assumption that it won't be spamblocked as well as the main MX relay is, but will be validated to forward stuff in to you. And where they're trying that, we're finding it works (grumble grr) damn well.
Which means some of the assumptions we make on allowing, say, me on plaidworks to generate email as chuq@apple.com and forward it to someone at Apple are rapidly becoming obsolete, and how we design our backup MX systems need to be looked at, also.
The least-preferred MX ploy isn't terribly new. They don't even have to try the least-preferred first...just keep trying when rebuffed until one works (what...5xx means permanent?...hah).
By the way, I saw a neighbor ISP shoot itself in the foot with a backup MX a couple of years ago (they reacted very quickly and very well when I called them, and fixed the problem, and now their mail goes to outsourced scanning before reaching them anyhow).
They had their backup MX with a well known large provider and backbone (now part of a very well known very troubled organisation (spelling intentional)). And their backup MX got into one of the relay blocking lists. And it was an RBL they used (without exempting their own backup MX from checking).
It took a bit of header reading to figure out why we sometimes couldn't send mail to them but the bounces weren't immediate. But only a bit.
I don't think one can reasonably use a backup MX one doesn't control, these days (I suppose for Apple, that means Austin backs up Cupertino, and...).
--John
-- John Baxter jwblist@olympus.net Port Ludlow, WA, USA
On Tue, Jul 16, 2002 at 05:28:07PM -0700, Chuq Von Rospach wrote:
Actually, the REAL state of the art is that they look up your MX records, and do this to the HIGHEST ranked one (not the lowest). This is on the (it turns out, quite valid) assumption that it won't be spamblocked as well as the main MX relay is, but will be validated to forward stuff in to you. And where they're trying that, we're finding it works (grumble grr) damn well.
My secondary MXes are locked down even tighter for that exact reason, and you should use exim4 with the callout feature where you will not accept an rcpt to until after exim has down a callout from your secondary MX to your primary one. (if the primary one is actually down, then you do accept the mail)
Of course, my secondary MXes do reject mail at SMTP time with SA-Exim :)
Marc
"A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
On 7/18/02 3:15 PM, "Marc MERLIN" <marc_news@merlins.org> wrote:
On Tue, Jul 16, 2002 at 05:28:07PM -0700, Chuq Von Rospach wrote:
Actually, the REAL state of the art is that they look up your MX records, and do this to the HIGHEST ranked one
My secondary MXes are locked down even tighter for that exact reason,
One of the things I'm wondering is whether you could set up a trap up in the high MX records. You'd have to make sure your real mail system never failed badly enough to wander up there, but could you create problems by putting a tar baby up there?
I wonder...
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
He doesn't have ulcers, but he's a carrier.
On Fri, Jul 19, 2002 at 08:47:26AM -0700, Chuq Von Rospach wrote:
One of the things I'm wondering is whether you could set up a trap up in the high MX records. You'd have to make sure your real mail system never failed badly enough to wander up there, but could you create problems by putting a tar baby up there?
Ooooh.... that's diabolical.
I like it. :-)
Cheers,
jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
On Fri, Jul 19, 2002 at 08:47:26AM -0700, Chuq Von Rospach wrote:
My secondary MXes are locked down even tighter for that exact reason,
One of the things I'm wondering is whether you could set up a trap up in the high MX records. You'd have to make sure your real mail system never failed badly enough to wander up there, but could you create problems by putting a tar baby up there?
I don't know if I would. I'm sure some legitimate MTAs and DNS servers would somehow sometimes end up with your highest MX. That said, I have indeed not tried it, it may virtually never happen.
Marc
"A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
On Fri, Jul 19, 2002 at 09:17:18AM -0700, Marc MERLIN wrote:
On Fri, Jul 19, 2002 at 08:47:26AM -0700, Chuq Von Rospach wrote:
My secondary MXes are locked down even tighter for that exact reason,
One of the things I'm wondering is whether you could set up a trap up in the high MX records. You'd have to make sure your real mail system never failed badly enough to wander up there, but could you create problems by putting a tar baby up there?
I don't know if I would. I'm sure some legitimate MTAs and DNS servers would somehow sometimes end up with your highest MX. That said, I have indeed not tried it, it may virtually never happen.
I wouldn't do it myself, but if you make 2 ip addresses on the same system with one higher pref and one lower pref, and ran the tarpit (or at least an information collector) on the the higher pref ip address, you may get a decent sample on whether or not your idea is going to interfere with your regular service. Since both are on the same system, nothing should ever contact the higher of the 2.
-- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.
On 7/19/02 9:57 AM, "Peter C. Norton" <spacey-mailman@lenin.nu> wrote:
I wouldn't do it myself, but if you make 2 ip addresses on the same system with one higher pref and one lower pref, and ran the tarpit
Yeah. I'm actually planning to do that once I finish up upgrading plaidworks.com to MacOS X, so I can do a port scanner sniffer, also.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
No! No! Dead girl, OFF the table! -- Shrek
"Bob Puff@NLE" <bob@nleaudio.com>
Not to get too far OT here but...
I've seen the next generation of spammer software at work recently. Spammer's machine makes direct SMTP connection to my box, gives MY address as the FROM:, TO:, and REPLY-TO:. This bypasses all the open relay testing, and would only leave stuff like SA to detect it.
Actually, you missed "version a" of this, in which a user is picked, and messages are sent to 8 [about] or fewer alphabetically-near addresses on the same domain. I *think* the "or fewer" mostly came from stale addresses being bounced.
So this thing was really clever, right? Not really...there was a supposed Received: header "below" the Subject: header. With a made up host name in the supposedly sending domain, and SMTP not esmtp protocol.
Not hard to catch and freeze by parsing headers, although I froze based on another header instead. (The latter turned out not to be specific to the spam in question [just because it wasn't found in any of the message I have in my last couple of years of history didn't make it unusual, just old, as it turned out]. It recently caught another juicy spammer who was easy to deal with but whom I wouldn't have noticed if I hadn't had to vette the frozen messages.)
Plan B of this series* is the xxx@example.com to xxx@example.com form you're seeing...which sometimes is, it turns out xxx@example.com to yyy@example.com. This form lacks the misplaced phony Received: header.
*I see it as part of the series...the perps may not.
--John
John Baxter jwblist@olympus.net Port Ludlow, WA, USA mailman-developers...where no canned worm is safe.
"JWB" == John W Baxter <jwblist@olympus.net> writes:
JWB> I don't think the ISPs *can* solve the problem in the
JWB> near-to-medium-term future. [Longer term, with the demise of
JWB> SMTP and its "everything open to all except for a few
JWB> bandaids" approach, maybe.]
JWB> At some point, the SpamAssassin/quarantine model breaks
JWB> down...when you quarantine 10 large messages to let one
JWB> smaller message go through, you're somewhere close to that
JWB> point. As it is, we're busily installing four machines to do
JWB> the work that one would do quite well in the absence of
JWB> spammers (and they'll have help from another machine or two
JWB> so that users can see their quarantined mail and rescue their
JWB> false positives). And yes, SpamAssassin is part of that
JWB> picture.Some of the work the python.org postmaster (Greg Ward) is doing involves examining and rejecting messages during the SMTP dialog. The trick is to force them to do more work to deliver their spam, upping the costs of the sending host just enough for it to be not worth it. Unfortunately, I suspect our own costs will go up faster than theirs so we'll likely lose this battle too. But IMO, anything that isn't economics based will fail.
JWB> Plus, I fear the "new breed" spammers (the ones who actually
JWB> think their advertising is useful and welcome and only sent
JWB> to opt-in lists, although they buy the lists from guys who
JWB> [figuratively] sell them from under a trenchcoat at the
JWB> entrance to a dark alley) will cause legislation to be passed
JWB> forbidding filtering at the mail server level. It nearly
JWB> happened last time around.Yup, but on the other side of the coin, they're getting sued and losing for not verifying their opt-in lists. But none of that matters either given the global nature of things.
JWB> Ah, well...we'll see how it goes.can-i-be-a-rock-star-now?-ly y'rs, -Barry
On 7/16/02 4:44 PM, "John W Baxter" <jwblist@olympus.net> wrote:
I don't think the ISPs *can* solve the problem in the near-to-medium-term future. [Longer term, with the demise of SMTP and its "everything open to all except for a few bandaids" approach, maybe.]
Me, I'm just not that worried about this idea, any more than I worry about the 'we simply need to redo e-mail so you pay to send things' -- because any NEW system is going to have to be backwards compatible with the old system for a significant period of time, iether directly or through some kind of gateway system -- so there's a good period of time for the lot of us to find ways of dealing with it. And don't forget, even the big ISPs use off the shelf tools like sendmail, postfix, etc. if they really want to build customized systems, it'll be really tough (and expensive) to do so without the tools they bring in from the open source community, and as big as any of the ISPs are, whatever protocols they create will have to be open at some level, because while MSN is huge and AOL is huge, if AOL can't talk to MSN and MSN can't talk to AOL, the protocol will fail.
And whatever protocol they build, open source can build something that works with it. If they can reverse engineer samba, I'm not worried about e-mail protocols. And given that most of the big boys build their systems (increasingly) on linux and use open source extensively, I think the "big boys will lock us all out" is a strawman. Which doesn't mean I don't think we should not be vigilant, but...
At some point, the SpamAssassin/quarantine model breaks down...
Yeah. When you're on deadline, and the admin is on vacation.
As it is, we're busily installing four machines to do the work that one would do quite well in the absence of spammers (and they'll have help from another machine or two so that users can see their quarantined mail and rescue their false positives). And yes, SpamAssassin is part of that picture.
Yup. That setup is fairly typical for high volume email systems these days. But a number of the big e-mail systems who's admins I talk to are seeing as much as 30% of the email being sent to the system rejected as spam, and the numbers are growing.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after
"JWB" == John W Baxter <jwblist@olympus.net> writes:
JWB> I think the issue is larger than just mailing lists:
JWB> SMTP-based email will be unusable soon. The replacement will
JWB> be something permission based with electronic signatures
JWB> involved, and some TMDA-like way to get started conversing
JWB> with someone.As mentioned before, SpamAssassin has gone a long way to making our python.org and zope.org addresses usable again. In fact, many of us are forwarding our mail /through/ python.org just so we don't have to install SA on our own machines. :)
I'd really like to believe that a PKI based approach will work some day but I just seriously doubt it. It doesn't pass the "my mom can use it" test and I don't think it ever will.
skeptical-ly y'rs, -Barry
On 7/16/02 2:42 PM, "Barry A. Warsaw" <barry@zope.com> wrote:
JWB> be something permission based with electronic signatures JWB> involved, and some TMDA-like way to get started conversing JWB> with someone.
As mentioned before, SpamAssassin has gone a long way to making our python.org and zope.org addresses usable again.
Agreed, for now. But SA is, frankly, a cold war situation of constant escalation. As you noted, Barry, some of you are forwarding through python.org to avoid having to install it, and spam assassin requires monitoring and upgrading. TMDA is sort of a fireaxe instead of a scalpel, but it won't require fairly frequent tweaking to keep ahead of the spammers, either.
I think SA for user accounts and TMDA for public accounts is the proper setup if you can do it, but can you build Mailman to have a requirement for Spam Assassin to be installed? Or should this be something that Mailman takes responsibility for? That's really the question here.
I'd really like to believe that a PKI based approach will work some day but I just seriously doubt it. It doesn't pass the "my mom can use it" test and I don't think it ever will.
Oh, um...
<http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=364>
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
The first rule of holes: If you are in one, stop digging.
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> Agreed, for now. But SA is, frankly, a cold war situation of
CVR> constant escalation.Yep.
CVR> As you noted, Barry, some of you are forwarding through
CVR> python.org to avoid having to install it, and spam assassin
CVR> requires monitoring and upgrading.Indeed, although DeerSoft will probably make it mostly dead simple, at least for Windows users:
CVR> TMDA is sort of a fireaxe instead of a scalpel, but it won't
CVR> require fairly frequent tweaking to keep ahead of the
CVR> spammers, either.True, that's a real problem. Note I already fight that battle with bounce messages, and they are /supposed/ to be playing by the rules. ;)
CVR> I think SA for user accounts and TMDA for public accounts is
CVR> the proper setup if you can do it, but can you build Mailman
CVR> to have a requirement for Spam Assassin to be installed? Or
CVR> should this be something that Mailman takes responsibility
CVR> for? That's really the question here.It's a good question. There are patches on SF to integrate SA and Mailman which I haven't had time to look at, but no, I don't think SA should be a requirement. I /do/ think they ought to play very nicely together.
>> I'd really like to believe that a PKI based approach will work
>> some day but I just seriously doubt it. It doesn't pass the
>> "my mom can use it" test and I don't think it ever will.
CVR> Oh, um...
CVR> <http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=364>Right on target. But of course it doesn't matter anyway because public key systems are hard enough for hardened geeks to use regularly, so there's no hope in hell my mom's ever going to use it
(Aside: have y'all even tried to explain the basics of encryption, signatures, etc. to your mom or dad? I have. They're smart people, but not particularly computer literate. They're even fairly liberal/libertarian. It's hard to get past why they'd even /want/ to use it. Oh well, when we die off and our kids' kids are running the world, maybe it has a chance. ;)
-Barry
J C Lawrence <claw@kanga.nu> writes:
Note that TMDA handling is trivially automated by SPAMmers and that they will so automatically handle and bypass TMDA as soon as it becomes popular enough for them to notice.
Not necessarily.
See http://tmda.net/faq.cgi?req=show&file=faq01.001.htp
-- (http://tmda.net/)
barry@zope.com (Barry A. Warsaw) writes:
Basically you're trying to set up a Turing test, yes?
At this point, it's not necessary. The challenge currently needs to be no more more complex than confirming a mailing list subscription (i.e, "hit reply to confirm").
For reasons discussed in the my FAQ, it might not ever need to be either. In any case, should this change, there is work being done to derive tests than humans can pass, but computers cannot. For example, the CAPTCHA project (http://www.captcha.net/).
I'm a believer in not trying to cross that bridge until we come to it though.
-- (http://tmda.net/)
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> First, a minor announcement. I'm no longer in charge of the
CVR> mailing lists at apple, sort of. We've hired a person
CVR> full-time, and he's been taking over the lists server as his
CVR> full-time responsibility, allowing me to go off and work on
CVR> other projects. I'm still in the loop, just not "it". I'm
CVR> still going to be heavily involved as we move that box to
CVR> Mailman 2.1, and after that, probably fade a bit more into
CVR> the woodwork (I still run my Mailman box at home, however, so
CVR> I'm not going away. JC, quite jeering)Congratulations! I think. ;)
CVR> One thing we're definitely doing is moving to a cloaked
CVR> archive. Since we already distribute all archives out of
CVR> HTTP, not FTP, we're working on a CGI that'll strip all
CVR> e-mail information out of messages on the fly (among other
CVR> things, like header cleanup and some trivial formatting
CVR> fixes). The idea is simple -- we've finally hit the point
CVR> where you can't put an e-mail address up on a public site
CVR> under any cirucmstance safely, so we're having to move to a
CVR> system where we simply don't do that.So these are public archives that need to be scrubbed, right? Until now, Mailman has taken the approach that public archives are feed right off the file system by the http server. We could still do that if we scrubbed the messages before we archived them, although that doesn't help with existing archives unless you re-generate them.
So one question is: does the performance trade-off we made 5 years ago still make sense? Should we just be vetting all archives through a cgi, in which we can do fun stuff like cleanse it of email addresses?
We'd obviously have to get rid of the easy access to the raw mbox file, so another question is whether that's still useful. Occasionally it's damn handy if you're moving a list or gathering statistics on it, but on the other hand, it's a rich source of addresses to mine. Again, if we scrubbed the messages pre-archiving we likely be ok.
Also, what heuristic do you use to search for email addresses, and what do you scrub them with? Do you want to attempt to obscure the address (e.g. "barry--at--python--dot--org") or replace it altogether (e.g. "[hidden email address]"), or maybe just replace it with a truncation (e.g. "[localpart's email address]").
CVR> I think the Mailman stuff needs to think about this, also. It
CVR> impacts the archiving setup and other issues, but the
CVR> harvesters have hit the point where we simply can't risk
CVR> disclosing that info. It creates other problems -- you can't
CVR> see a posting in the archive and send email to that person
CVR> with more questions (or answers), but that seems trivial
CVR> compared to the problems the spammers are causing.It kind of plays into Reply-To: munging doesn't it? If you won't be able to reply to the original author, because we're anonymizing messages, then you might as well munge Reply-To: to go back to the list because that's the only posting address that makes sense. And what if the original poster isn't a member of the list?
Or should Mailman get into the anonymous resender game? There's probably a lot we could do here, but given the political risks of anonymous resenders, do we even want go there?
CVR> A secondary issue here is the problem of disclosing admins
CVR> and admin addresses.Note that in MM2.1 we go about 1/2 way here. We include the obscured email addresses of the list owners as the text in a mailto: tag but we actually use the list-owner@ address as the mailto: target. That might not be enough though. When we actually have a Real Database backend we can keep a roster of email+realname and then just include the realname inside the href:mailto tag.
CVR> I know we've hashed that through once, but we've come to the
CVR> (somewhat reluctant) decision to whitelist all public,
CVR> non-personal email addresses. We're going to be implementing
CVR> TMDA to do this, and will be switching all admin to generic
CVR> addresses that filter through TMDA, as well as things like
CVR> postmaster@ and the like. While I hate making users jump
CVR> through hoops to get through to a real person (for those that
CVR> don't know, TMDA is an overt whitelist. If you're not on the
CVR> whitelist, you get mail back telling you to take some action,
CVR> and until you do, the mail isn't delivered), but the abuse by
CVR> the spammers on admin addresses is now so bad I'm declaring
CVR> defeat and going to the whitelist.Have you looked at SpamAssassin Chuq? It's really done wonders to reduce the amount of spam actually getting through any python.org or zope.org address. I know 'cause I see the daily reports of quarantined messages. Very few false positives too (usually it's email amongst our postmasters talking about spam or SA ;). I feel a lot better about this approach than TMDA'ing essential addresses like postmaster or mailman-owner.
CVR> I'm going to look and see if I can interface TMDA to the
CVR> subscriber databases so that subscribers are by definition
CVR> whitelisted, but we've hit the poiint where we have to do
CVR> this. I'm not happy about it, but the war is lost, I think.Sigh.
CVR> So what he did was open up his address book and send his
CVR> message to everyone in it. And he's running one of these new
CVR> e-mail clients that happily caches addresses it sees in case
CVR> you want them again. So all of the addresses of people
CVR> posting to the mailing lists he subscribed to were in his
CVR> address book cache, so when he grabbed his address book, he
CVR> grabbed all of those addresses, too.Wonderful. I think this has been presaged by Klez which does essentially the same thing w/o human intervention or such good intent. ;)
CVR> But now we're wondering if we have to go to some sort of
CVR> address cloaking ON lists, maybe some kind of address
CVR> remapping through the server for replies, something. And I'm
CVR> gritting my teeth at the developers who created those
CVR> @#$@$#@$#23 caches (which are nice in some ways) for not also
CVR> creating some way to flag addresses as not
CVR> cacheable. Because, IMHO, that'd solve this problem.Yup, but of course it implies that the clients play by the rules, and we know that they don't all, so the question is what we're willing to give up for the security of our online personas. Kinda mirrors today's large questions in the WoT(tm), eh? Maybe people are more willing to give up their rights than their conveniences for some added security.
CVR> Are we hitting a point where mail list servers have to act as
CVR> blind front ends for all of the subscribers, where replies
CVR> are processed by those servers, and the server then takes on
CVR> the job of acting as a troll-exterminator and spam blocker?
CVR> And what does that really mean for things like Mailman?World domination of course. Because we /could/ add that stuff fairly easily if we had the resources to expend on it. Would it still be useable? For some audiences yes, others no. I'm fairly sure the kind of anonymizing we're talking about would never fly in the Python and Zope community, where as it's probably essential in a less cloistered environment like lists.apple.com. Which leads me to believe that we need to make it much easier to install themes or styles of lists, from the paranoid anonymizer to the laissez-faire discussion list.
CVR> Happy Macworld Expo week, all. If you need me, I'll be in the
CVR> war room, beating my head against a wall.Any chance you could make it down to DC for a side trip? We could have a Mailman hacking sprint over a few dozen steamed Maryland blue crabs and some cold ones. :)
-Barry
On 7/16/02 2:37 PM, "Barry A. Warsaw" <barry@zope.com> wrote:
CVR> the woodwork (I still run my Mailman box at home, however, so CVR> I'm not going away. JC, quite jeering)
Congratulations! I think. ;)
Actually, yes. I won't be working 65+ hours a week any more, so I sort of get my life back, and may actually have time to think stuff through and do more than emergency patching... (for more, see <http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=348>). Also means I can actually start some non-Apple hacking again, I hope. And what I'll be doing is lots of fun, although the next six weeks is going to be a crunch. Still doing email, just off building a new custom system for stuff I can't talk about...
CVR> One thing we're definitely doing is moving to a cloaked CVR> archive. Since we already distribute all archives out of
So these are public archives that need to be scrubbed, right? Until now, Mailman has taken the approach that public archives are feed right off the file system by the http server. We could still do that if we scrubbed the messages before we archived them, although that doesn't help with existing archives unless you re-generate them.
Here's why I won't do that. I want to keep ONE set of archives. You can't scrub those archives for two reasons. What if someone writes looking to get in contact with the author of a message? If the archive is scrubbed, that info is gone. And (god forbid), you get into a legal tangle? That's your legal record of what was said on the mail list and who said it. If you scrub it, and someone does something actionable or libelous and you get a court order to provide that data? You're hosed.
On a more likely note -- I can see where you might want the option to show the archives unscrubbed to validated users, and only scrub the public archives. As paranoid as I'm being today, I'd STILL like to find a way to let subscribed users see the archives unscrubbed. Which you could do by setting a cookie that the CGI could accept and change it's behavior.
So I really like leaving the archives unmodified, and doing the scrubbing via CGI. It also allows you do to other things, like header cleanups (and you could potentially let a user set a cookie to define minimal or full headers, say...) and some quickie cleanup against unwrapped text and some other incidental archive glitches.
I come from a newspaper family, so I have a bias towards "you don't unpublish stuff, you don't change it once it's published". But I think there are good reasons to avoid sanitizing the archives, and instead sanitizing the delivery of those archives -- if only because if your policies change, all you need to change is the CGI. And it gives you the ability to set up different sets of abilities per user or per list if you want, too.
So one question is: does the performance trade-off we made 5 years ago still make sense? Should we just be vetting all archives through a cgi, in which we can do fun stuff like cleanse it of email addresses?
One of the big things I dislike about Mhonarc is that archives are a rather low-usage system, but maintaining the Mhonarc index pages is rather intensive use of system resources. Sort of like usenet -- you do a lot of work on everything, in case someone wants anything. I think simply storing the archives and sanitizing on demand is lower overhead. It also means pipermail won't need ANY changes -- you simply feed it out through the CGI instead of directly, and everything magically sanitizes...
We'd obviously have to get rid of the easy access to the raw mbox file, so another question is whether that's still useful.
Honestly? I don't think so. I find them real kludgy. I ended up doing a new archiving system (one file per message) via a perl script. We're about to take our new search engine out of beta with the thing, finally.
Also, what heuristic do you use to search for email addresses, and what do you scrub them with?
Still being worked on. Right now, I'm basically doing a <wordboundary><nonwhitespace>@<nonwhitespaceordot><dot>nonwhitespace><wordbo undary>. I don't know how strongly we'll refine it.
Do you want to attempt to obscure the address (e.g. "barry--at--python--dot--org")
Anything you programmatically obscure will be programmatically de-obscured. This technique is bogus and guaranteed to fail as soon as the spammers care enough. It's pretty clear even the "randomized obscuring" of slashdot is a failed technique, since spambots don't have to decode ALL of those formats, just some of them, and then cycle throug the site enough times....
Sorry, I find this is a false security. Makes the users feel better, accomplishes nothing useful, so in reality, users get lazy and careless. So to some degree, I feel it's worse than nothing. I'm planning on replacing email addresses with something useful like [email address deleted].
CVR> disclosing that info. It creates other problems -- you can't CVR> see a posting in the archive and send email to that person CVR> with more questions (or answers), but that seems trivial CVR> compared to the problems the spammers are causing.
It kind of plays into Reply-To: munging doesn't it? If you won't be able to reply to the original author, because we're anonymizing messages, then you might as well munge Reply-To: to go back to the list because that's the only posting address that makes sense.
Yes (he says, grimacing).
If you sanitize the archives, I don't think it affects the list. There are simply NO mailtos any more in the archives.
If you go the step further and anonymize the postings ON the list, so subscriber email addresses simply are never shown to other subscribers under any circumstances (ugh. Urp. I can't believe I'm saying that. This is so anti-community it hurts), you have no choice and reply-to has to point to the list, since it's the only contact point left.
If you instead turn the list server into a forwarding agent, as in:
Or should Mailman get into the anonymous resender game? There's probably a lot we could do here, but given the political risks of anonymous resenders, do we even want go there?
Is it an anonymous remailer? We're making no pretense of anonymity here. We're acting as a forwarding agent, ala hotmail.com or mac.com. You mail to id13194@python.org, and it ends up in my mailbox. The fact that we're not explicitly denoting the real email address doesn't make us an anonymous remailer -- that'd be a policy issue, actually. I suppose you could take it that step further, but you could also set it up so validated subscribers could get to the real addresses.
The model I'm thinking of is like many forum systems. If you're a guest, you don't get access to email info. If you're a subscriber, you log on, and they magically appear. In the case of mailing lists, since oyu lose control of the e-mail address once it leaves the site again, you handle this by only using the remailer address in mail that leaves the site, but a subscriber could go to the list system and look a user up. That gets us away from the politics of the anonymous stuff.
CVR> A secondary issue here is the problem of disclosing admins CVR> and admin addresses.
Note that in MM2.1 we go about 1/2 way here. We include the obscured email addresses of the list owners as the text in a mailto: tag but we actually use the list-owner@ address as the mailto: target. That might not be enough though. When we actually have a Real Database backend we can keep a roster of email+realname and then just include the realname inside the href:mailto tag.
I think six months ago it was enough. Now, I just don't think it is. Sigh. Grumble.
Have you looked at SpamAssassin Chuq?
See my other message. SA is a good tool, if you have someone around willing to update it, monitor it, and make sure it stays up to date technologically with current releases that are updated to match the spammers changes. Do you want to require SA to be installed as a requirement for Mailman? What about sites where they don't have an admin to keep updating it?
SA is only as good as the latest release blocks spam. So you have to keep updating it. Is that a realistic (and ultimately successful) strategy? I HATE WHITELISTS. But in the case of public addresses, I'm now convinced they're needed, because otherwise, you're committing to an ever-escalating war to stay ahead of the spammers. At best, that's going to cost continuing manpower and energy and be zero sum. You won't win, you simply continue surviving by sticking thumbs in the dike.
Very few false positives too (usually it's email amongst our postmasters talking about spam or SA ;).
All it takes is one. Have you seen these stories?
Some stuff I've run across while digging out from being on vacation...
An interesting take on collaborative anti-spam issues -- that forging email headers to test/validate an open relay is an illegal trespass on a mail server:
<http://www.newarchitectmag.com/documents/s=2442/na0802g/index.html>
Lincoln Stein saying the heck with it and deciding that manual filtering is better than the alternatives:
<http://www.newarchitectmag.com/documents/s=2445/na0802h/index.html>
And in case you didn't see it, cNet's article on why the RBLs are creating false positive problems. It really looks like the blackhole systems have now hit a critical mass where they're being noticed, and not favorably. The folks at SPEWS, if you read what has happened through their stuff and how their attitude leaked all over their responses, hasn't helped their cause much.
<http://news.com.com/2100-1023-943337.html?tag=fd_lede>
Finally, another article, this from TidBits, about the growing problem of BAD filtering and false positives, and how it creates another set of (probably even worse) problems.....
Also:
CVR> @#$@$#@$#23 caches (which are nice in some ways) for not also CVR> creating some way to flag addresses as not CVR> cacheable. Because, IMHO, that'd solve this problem.
Yup, but of course it implies that the clients play by the rules, and we know that they don't all, so the question is what we're willing to give up for the security of our online personas. Kinda mirrors today's large questions in the WoT(tm), eh? Maybe people are more willing to give up their rights than their conveniences for some added security.
Yeah. I see your Sigh and raise you.
World domination of course. Because we /could/ add that stuff fairly easily if we had the resources to expend on it. Would it still be useable? For some audiences yes, others no. I'm fairly sure the kind of anonymizing we're talking about would never fly in the Python and Zope community, where as it's probably essential in a less cloistered environment like lists.apple.com. Which leads me to believe that we need to make it much easier to install themes or styles of lists, from the paranoid anonymizer to the laissez-faire discussion list.
You have nailed it on the head. Which is why I brought it up. Not because this is the way it has to be in the future, but because all this is making Mailman's job a whole lot more complex (we were whining about that at work today, or at least I was and everyone was nodding sympathetically and looking for an open window -- email used to be pretty easy and straight forward. And now.....). But not just because all this crap is getting in the way, but also that fixing this crap is overkill for some environments, and going to be NOT ENOUGH in others.
CVR> Happy Macworld Expo week, all. If you need me, I'll be in the CVR> war room, beating my head against a wall.
Any chance you could make it down to DC for a side trip? We could have a Mailman hacking sprint over a few dozen steamed Maryland blue crabs and some cold ones. :)
Damn, that sounds good, but -- I've had to give up crab and shellfish (I've developed an intermitten sensitivity to it. Sigh!) and I'm staying in cupertino where I'll be manning the war room this week making sure buttons get pushed when they need pushed, and not a minute before....
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
No! No! Dead girl, OFF the table! -- Shrek
On Tuesday 16 July 2002 20:07, Chuq Von Rospach wrote:
The model I'm thinking of is like many forum systems. If you're a guest, you don't get access to email info. If you're a subscriber, you log on, and they magically appear. In the case of mailing lists, since oyu lose control of the e-mail address once it leaves the site again, you handle this by only using the remailer address in mail that leaves the site, but a subscriber could go to the list system and look a user up. That gets us away from the politics of the anonymous stuff.
It wouldn't be a bad idea, further to the above method, to have an option at the subscriber level that always stealth's their address, even if a subscriber logs on. That gives the ultimate protection ability as an opt-in. If you don't opt in, other logged in subscribers see your real email address.
Even though I like replyto munging, I know you don't. That would allow you to not replyto mung unless the user has gone totally stealth.
On Tue, Jul 16, 2002 at 05:07:48PM -0700, Chuq Von Rospach wrote:
in contact with the author of a message? If the archive is scrubbed, that info is gone. And (god forbid), you get into a legal tangle? That's your legal record of what was said on the mail list and who said it. If you scrub it, and someone does something actionable or libelous and you get a court order to provide that data? You're hosed.
Nope.
As long as your policies *do not change after* you receive such an order, you are not legally liable. You're not required even to *keep8 the archives by anything I know about -- you *are* familiar with the term "retention policy", right? :-)
I come from a newspaper family, so I have a bias towards "you don't unpublish stuff, you don't change it once it's published". But I think there are good reasons to avoid sanitizing the archives, and instead sanitizing the delivery of those archives -- if only because if your policies change, all you need to change is the CGI. And it gives you the ability to set up different sets of abilities per user or per list if you want, too.
Concur. Even though it's computationally expensive, bind as late as possible.
We'd obviously have to get rid of the easy access to the raw mbox file, so another question is whether that's still useful.
Honestly? I don't think so. I find them real kludgy. I ended up doing a new archiving system (one file per message) via a perl script. We're about to take our new search engine out of beta with the thing, finally.
I hope you're de heirarchicalizing the directories.
Also, what heuristic do you use to search for email addresses, and what do you scrub them with?
Still being worked on. Right now, I'm basically doing a <wordboundary><nonwhitespace>@<nonwhitespaceordot><dot>nonwhitespace><wordbo undary>. I don't know how strongly we'll refine it.
Some places put spaces in mailbox names -- you'd better deal with quoted LHS's.
It kind of plays into Reply-To: munging doesn't it? If you won't be able to reply to the original author, because we're anonymizing messages, then you might as well munge Reply-To: to go back to the list because that's the only posting address that makes sense.
Yes (he says, grimacing).
You feel my pain. :-)
If you sanitize the archives, I don't think it affects the list. There are simply NO mailtos any more in the archives.
If you go the step further and anonymize the postings ON the list, so subscriber email addresses simply are never shown to other subscribers under any circumstances (ugh. Urp. I can't believe I'm saying that. This is so anti-community it hurts), you have no choice and reply-to has to point to the list, since it's the only contact point left.
Well, no: reply-to should be ADDRESS-REMOVED-FOR-SECURITY, and the pain should be pointed at the list admin.
If you instead turn the list server into a forwarding agent, as in:
Or should Mailman get into the anonymous resender game? There's probably a lot we could do here, but given the political risks of anonymous resenders, do we even want go there?
Is it an anonymous remailer? We're making no pretense of anonymity here. We're acting as a forwarding agent, ala hotmail.com or mac.com. You mail to id13194@python.org, and it ends up in my mailbox. The fact that we're not explicitly denoting the real email address doesn't make us an anonymous remailer -- that'd be a policy issue, actually. I suppose you could take it that step further, but you could also set it up so validated subscribers could get to the real addresses.
That would be a bit helpful, but *does* fundamentally change what the package is doing.
using the remailer address in mail that leaves the site, but a subscriber could go to the list system and look a user up. That gets us away from the politics of the anonymous stuff.
But conversely, if subs can see real addresses in real messages, you're only one step away from the harvesting problem you mentioned earlier.
Have you looked at SpamAssassin Chuq?
See my other message. SA is a good tool, if you have someone around willing to update it, monitor it, and make sure it stays up to date technologically with current releases that are updated to match the spammers changes. Do you want to require SA to be installed as a requirement for Mailman? What about sites where they don't have an admin to keep updating it?
You don't get what you don't pay for.
Chuq, it's obvious to me that that's not a good enough answer for you. but I'm afraid, even though I know you've put at least one long reply to me into trying to explain why not in the past, that I still don't get it.
Maybe it's me.
So many things are just me.
But *why isn't this the recipients' problem*?
Very few false positives too (usually it's email amongst our postmasters talking about spam or SA ;).
All it takes is one. Have you seen these stories?
I can synthesize some false-positive horror stories. But if you've got a couple handy -- with real termination notices -- let 'er rip.
World domination of course. Because we /could/ add that stuff fairly easily if we had the resources to expend on it. Would it still be useable? For some audiences yes, others no. I'm fairly sure the kind of anonymizing we're talking about would never fly in the Python and Zope community, where as it's probably essential in a less cloistered environment like lists.apple.com. Which leads me to believe that we need to make it much easier to install themes or styles of lists, from the paranoid anonymizer to the laissez-faire discussion list.
You have nailed it on the head. Which is why I brought it up. Not because this is the way it has to be in the future, but because all this is making Mailman's job a whole lot more complex (we were whining about that at work today, or at least I was and everyone was nodding sympathetically and looking for an open window -- email used to be pretty easy and straight forward. And now.....). But not just because all this crap is getting in the way, but also that fixing this crap is overkill for some environments, and going to be NOT ENOUGH in others.
Wow. Yeah, those two paragraphs capsulize it pretty well.
Glad *I'm* not the architect.
CVR> Happy Macworld Expo week, all. If you need me, I'll be in the CVR> war room, beating my head against a wall.
Any chance you could make it down to DC for a side trip? We could have a Mailman hacking sprint over a few dozen steamed Maryland blue crabs and some cold ones. :)
Damn, that sounds good, but -- I've had to give up crab and shellfish (I've developed an intermitten sensitivity to it. Sigh!) and I'm staying in cupertino where I'll be manning the war room this week making sure buttons get pushed when they need pushed, and not a minute before....
You go, boy.
Cheers,
jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
On 7/16/02 5:49 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
On Tue, Jul 16, 2002 at 05:07:48PM -0700, Chuq Von Rospach wrote:
in contact with the author of a message? If the archive is scrubbed, that info is gone. And (god forbid), you get into a legal tangle?
the archives by anything I know about -- you *are* familiar with the term "retention policy", right? :-)
True, but let me rephrase with the situation I should have used in the first place. Two of your users get into a fight on the list. One of them finally says some variation of "you are a dead man". Three weeks later, the other guy's house burns down because of arson, and all you have is an archive with no identifying information in it....
archiving system (one file per message) via a perl script. We're about to take our new search engine out of beta with the thing, finally.
I hope you're de heirarchicalizing the directories.
I'm confused. What are you suggesting?
(FWIW, our structure is <listname>/yyyy/mm/dd/)
Some places put spaces in mailbox names -- you'd better deal with quoted LHS's.
I know. That's one of the things we need to evaluate still.
If you go the step further and anonymize the postings ON the list, so subscriber email addresses simply are never shown to other subscribers under any circumstances (ugh. Urp. I can't believe I'm saying that. This is so anti-community it hurts), you have no choice and reply-to has to point to the list, since it's the only contact point left.
Well, no: reply-to should be ADDRESS-REMOVED-FOR-SECURITY, and the pain should be pointed at the list admin.
No, I don't agree. You still, at least in theory, want users to have a conversation. But by cloaking on the address, you are, effectively, forcing that conversation to go through the list under all circumstances. So reply-to should go to the list, not the admin.
that step further, but you could also set it up so validated subscribers could get to the real addresses.
That would be a bit helpful, but *does* fundamentally change what the package is doing.
Yeah. It's a fairly significant hunk o' code, AND it requires, basically, that '*@some.domain' be forwarded to the server for processing. Or at a very minimum, an LDAP lookup for valid addresses, because trying to manage that as an alias file or some static structure would be deadly.
using the remailer address in mail that leaves the site, but a subscriber could go to the list system and look a user up. That gets us away from the politics of the anonymous stuff.
But conversely, if subs can see real addresses in real messages, you're only one step away from the harvesting problem you mentioned earlier.
Yes, but it keeps it out of those !@#$@%@$#@!@#@! automatic caches. And in theory, you could tell if someone started harvesting, because the system could be taught to watch for systematic walks through the database.
Chuq, it's obvious to me that that's not a good enough answer for you. but I'm afraid, even though I know you've put at least one long reply to me into trying to explain why not in the past, that I still don't get it.
Maybe it's me.
No, it's that we're still hashing things out, and a number of things, in general, just aren't clear (or resolved)
But *why isn't this the recipients' problem*?
Or more correctly, why isn't it ONLY the recipient's problem?
Two reasons:
- I (as the list admin to the recipient) am offering a service. I strongly believe that if I'm offering a service, I have an ethical (if not legal) responsibility to make that service as problem free as possible. To me, the alternative is the same as selling toasters that aren't US approved because I feel it's the buyer's responsibilty to make sure they aren't electrocuted. Now, I think it's ALSO the buyer's responsibilty to be aware of the risk of electrocution, but that doesn't remove the responsibility from me to not sell them a cheap, shoddy toaster.
1.5) Having said that as list admin -> recipient, iterate and I feel the same is true of "mail list developer" -> list admin. Because...
- I feel it is a responsibility of the experts to do what they can to take care of the not-so-experts. Since we (the developers) are the experts. We have the ability to build systems to deal with this, and so I feel we should, so that people who aren't as capable can benefit as well. Saying "it's his responsibility" only works as long as "he" can ALSO do what we do and knows what we know, and that's clearly not a true assumption. So saying that is really not assigning responsibility, but ducking it. That doesn't means we ought to solve all of the problems in the universe, but we are the folks most qualified to understand and solve these things -- so we should.
It's easy to say "every man for themselves" when you're at the top of the food chain, because you CAN do it. But I think it avoids the real responsibility by making the false assumption that it's just as simple for others to do it, too. If it was, we wouldn't be at the top of the food chain, wouldn't we? Instead, I see it as a rationalization to avoid having to do the work needed so that others can also use it.
If everyone had the same skill set, Jay, I'd agree with you. But they don't. And the nice thing is, some of those people are at the top of the food chain in other skillsets, and we get to benefit from what they know. And if they were all off trying to learn what we already know, they probably wouldn't have the time or energy to build things in their expertise we can benefit from, so it all evens out at the end.
Imagine if Tim Berners-Lee was too busy writing spamblock software to invent the browser.... I see us leveraging our expertise as a way to make sure some other expert gets to leverage their expertise so that whatever they can invent actually gets invented -- rather than sidetracked by something we could have saved them from but didn't, because we were self-focused.
All it takes is one. Have you seen these stories?
I can synthesize some false-positive horror stories. But if you've got a couple handy -- with real termination notices -- let 'er rip.
I can't give any definite examples to protect the people involved, but I know of a couple of people who've had their careers significantly impacted because of this stuff. Maybe not fatal, but third degree burns.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
He doesn't have ulcers, but he's a carrier.
On Tue, Jul 16, 2002 at 07:57:44PM -0700, Chuq Von Rospach wrote:
On 7/16/02 5:49 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
On Tue, Jul 16, 2002 at 05:07:48PM -0700, Chuq Von Rospach wrote:
in contact with the author of a message? If the archive is scrubbed, that info is gone. And (god forbid), you get into a legal tangle?
the archives by anything I know about -- you *are* familiar with the term "retention policy", right? :-)
True, but let me rephrase with the situation I should have used in the first place. Two of your users get into a fight on the list. One of them finally says some variation of "you are a dead man". Three weeks later, the other guy's house burns down because of arson, and all you have is an archive with no identifying information in it....
Well, ok... but in a case like that, your mailer logs would likely have the appropriate information. But still, as rare as such a circumstance is, I don't see that you have any moral obligation to be *that* prepared.
archiving system (one file per message) via a perl script. We're about to take our new search engine out of beta with the thing, finally.
I hope you're de heirarchicalizing the directories.
I'm confused. What are you suggesting?
(FWIW, our structure is <listname>/yyyy/mm/dd/)
That answers my question: I *knew* you knew better than to throw 30k files in one directory...
Some places put spaces in mailbox names -- you'd better deal with quoted LHS's.
I know. That's one of the things we need to evaluate still.
Mutt's highlighting regexes are pretty decent, but I don't know that *any* RE can match both quoted and non-quoted mailbox names reliably.
There's an argument going on somewhere else right now -- I thought it was bugtraq, but I seem to have misplaced the message -- about whether email addresses can have an RHS that terminates in a .
The poster says no way, I say that 2821 and 1034/5 say yes.
Well, no: reply-to should be ADDRESS-REMOVED-FOR-SECURITY, and the pain should be pointed at the list admin.
No, I don't agree. You still, at least in theory, want users to have a conversation. But by cloaking on the address, you are, effectively, forcing that conversation to go through the list under all circumstances. So reply-to should go to the list, not the admin.
No, I was merely trying to avoid people getting in the habit of replying to lists; I disagree with munging even here. It sets a bad example. But I'm a purist, and don't have to catch the bullets, so what do I know?
that step further, but you could also set it up so validated subscribers could get to the real addresses.
That would be a bit helpful, but *does* fundamentally change what the package is doing.
Yeah. It's a fairly significant hunk o' code, AND it requires, basically, that '*@some.domain' be forwarded to the server for processing. Or at a very minimum, an LDAP lookup for valid addresses, because trying to manage that as an alias file or some static structure would be deadly.
I might have gotten list (ok, I was trying to type ' l o s t ' there, but my hands refuse to cooperate; hell with it, it's a good pun) here...
using the remailer address in mail that leaves the site, but a subscriber could go to the list system and look a user up. That gets us away from the politics of the anonymous stuff.
But conversely, if subs can see real addresses in real messages, you're only one step away from the harvesting problem you mentioned earlier.
Yes, but it keeps it out of those !@#$@%@$#@!@#@! automatic caches. And in theory, you could tell if someone started harvesting, because the system could be taught to watch for systematic walks through the database.
And you could actually verp the addresses, if you had enough horsepower, making 'backtracing', per se, unnecessary -- you'd *know* who sent the mail.
Debugging, of course, would be murder, and admin-dependent; you could no longer do it from outside.
Chuq, it's obvious to me that that's not a good enough answer for you. but I'm afraid, even though I know you've put at least one long reply to me into trying to explain why not in the past, that I still don't get it.
Maybe it's me.
No, it's that we're still hashing things out, and a number of things, in general, just aren't clear (or resolved)
Ok. I really *did* think it was just me. Glad to hear you don't. (You have, IIRC, in the past. ;-)
But *why isn't this the recipients' problem*?
Or more correctly, why isn't it ONLY the recipient's problem?
Point.
Two reasons:
- I (as the list admin to the recipient) am offering a service. I strongly believe that if I'm offering a service, I have an ethical (if not legal) responsibility to make that service as problem free as possible. To me, the alternative is the same as selling toasters that aren't UL approved because I feel it's the buyer's responsibilty to make sure they aren't electrocuted.
Hmmm... the difference in degree *is* a difference in sorts, IMHO (OC spray isn't regulated nearly as severly as guns; you can't kill people with it)... but go on:
Now, I think it's ALSO the buyer's responsibilty to be aware of the risk of electrocution, but that doesn't remove the responsibility from me to not sell them a cheap, shoddy toaster.
Stipulated. But I don't believe that the toaster *is* cheap and shoddy -- ie: that it's *your* responsibility -- merely because people break into your house, and jam oversized bagels into your toaster repeatedly until it won't hold toast anymore.
1.5)
Why I love geeks. ;-)
Having said that as list admin -> recipient, iterate and I feel thesame is true of "mail list developer" -> list admin. Because...
- I feel it is a responsibility of the experts to do what they can to take care of the not-so-experts. Since we (the developers) are the experts. We have the ability to build systems to deal with this, and so I feel we should, so that people who aren't as capable can benefit as well. Saying "it's his responsibility" only works as long as "he" can ALSO do what we do and knows what we know, and that's clearly not a true assumption. So saying that is really not assigning responsibility, but ducking it. That doesn't means we ought to solve all of the problems in the universe, but we are the folks most qualified to understand and solve these things -- so we should.
Except that the spam isn't the *problem*. The *spammers* are.
Even when they get unreasonably strident, and scream for all the wrong reasons -- and they so -- I still back the Second Amendment absolutists, because history has proven that they *put that amendment in there for a reason*.
The circumstances are much the same here.
If we relieve the pain on the recipients for free, then they will *never* have an incentive to stop the problem at it's source. And I don't believe that anyone can inflict that pain on the spammers like an aroused citizenry.
It is largely because of RMS' intransigience on many points related to Free Software that we have most of it, and most particularly Linux -- I really don't believe it would have happened at all except for the developer-protection provided by the GPL.
Sometimes a cigar *is* just a cigar.
Sometimes, you've got to let junior take the fall.
It's easy to say "every man for themselves" when you're at the top of the food chain, because you CAN do it. But I think it avoids the real responsibility by making the false assumption that it's just as simple for others to do it, too. If it was, we wouldn't be at the top of the food chain, wouldn't we? Instead, I see it as a rationalization to avoid having to do the work needed so that others can also use it.
Not at all. It's not a question of ease. Undertaking responsibility is not easy. Probably the worst thing is taking a stand that so strongly resembles merely a mediocre excuse for laziness. But, to coin a phrase, I Am Not Making This Up.
Someone has to fix the problem. It has been proven to my satisfaction that the technologists can't: it's not a technology-fix problem (so few 'problems' are). Someone has to get *pissed*.
That'd be the people with the mailboxes, Bob.
If everyone had the same skill set, Jay, I'd agree with you. But they don't. And the nice thing is, some of those people are at the top of the food chain in other skillsets, and we get to benefit from what they know. And if they were all off trying to learn what we already know, they probably wouldn't have the time or energy to build things in their expertise we can benefit from, so it all evens out at the end.
I understand what you mean... but I still think you're shooting at the wrong target.
Imagine if Tim Berners-Lee was too busy writing spamblock software to invent the browser.... I see us leveraging our expertise as a way to make sure some other expert gets to leverage their expertise so that whatever they can invent actually gets invented -- rather than sidetracked by something we could have saved them from but didn't, because we were self-focused.
Fine.
But this isn't procmail, nor SpamAssassin; they're at the other end of the hall; third and fifth doors on the right, respectively.
This is a mailing list program.
Put in hooks for such things, fine. Recommend them, great. Even automatically install them. But, please: mechanism, not policy.
It's difficult to implement, but I think it's essential.
All it takes is one. Have you seen these stories?
I can synthesize some false-positive horror stories. But if you've got a couple handy -- with real termination notices -- let 'er rip.
I can't give any definite examples to protect the people involved, but I know of a couple of people who've had their careers significantly impacted because of this stuff. Maybe not fatal, but third degree burns.
The topic being false-positive-ly blocked "spam", aren't those evidence for the prosecution, not the defense?
Letting spam through likely only gets you yelled at; accidentally blocking important stuff gets you burned.
We are on the critical path, folks. I know you know that, but the explicit reminder isn't going to get me fired. Fail-safe isn't just for aerospace anymore.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
On 7/16/02 9:22 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
says some variation of "you are a dead man". Three weeks later, the other guy's house burns down because of arson, and all you have is an archive with no identifying information in it....
Well, ok... but in a case like that, your mailer logs would likely have the appropriate information. But still, as rare as such a circumstance is, I don't see that you have any moral obligation to be *that* prepared.
How many people keep their logs three weeks? How many people long ago stopped keeping detailed SMTP logs because of their size? And rare as the circumstance is, if YOUR house was burned down, would you still care that it was rare? (it's real easy to say "don't care, it's someone else's house...")
Stipulated. But I don't believe that the toaster *is* cheap and shoddy -- ie: that it's *your* responsibility -- merely because people break into your house, and jam oversized bagels into your toaster repeatedly until it won't hold toast anymore.
Take a look at the court system. You're so far in the minority it's not funny (really not funny). Have you ever read the instruction manual for a toaster? The warning pages in the instruction manual, that say things like "do not use toaster in shower"? Because fi they DON'T say that, they get sued because someone does?
Except that the spam isn't the *problem*. The *spammers* are.
Sorry. That's like saying "bullets aren't a problem, guns are". If you get shot, you don't waste time arguing semantics like this. Unless, I guess, you're a libertarian. But frankly, most of the libertarians I know who HAVE been shot (instead of arguing about what they'd do if, theoretically, they were shot) stop arguing semantics, too.
Even when they get unreasonably strident, and scream for all the wrong reasons -- and they so -- I still back the Second Amendment absolutists, because history has proven that they *put that amendment in there for a reason*.
That would be a fun argument, but I'll spare the list. Pass. (but if you look at the historical record of the debates over the amendment, it's a lot more ambiguous what the founding fathers THOUGHT, vs. how it's been interpreted. But, pass...)
It is largely because of RMS' intransigience on many points related to Free Software that we have most of it, and most particularly Linux -- I really don't believe it would have happened at all except for the developer-protection provided by the GPL.
And off we go into left field, to blame something completely tangential to the issue at hand.
Oh, never mind, pass.
Sometimes a cigar *is* just a cigar.
That's what monica said, too.
Sometimes, you've got to let junior take the fall.
Why? How very libertarian of you. May you never find someone calling you junior... (it's easy to say "let them eat cake" when you aren't starving with them. At least until the wagon arrives....)
Not at all. It's not a question of ease. Undertaking responsibility is not easy.
No, ducking responsibility is easy. Undertaking responsbility, however, is how things get done.
Someone has to fix the problem. It has been proven to my satisfaction that the technologists can't: it's not a technology-fix problem (so few 'problems' are). Someone has to get *pissed*.
That'd be the people with the mailboxes, Bob.
Wrong. It's the people with the skillset. Lots of people have mailboxes. Few people have the skillsets. But those people, it seems, are willing to let others rot, because it's easier for them personally. Well, some of them.
Look, if I wanted easy, I wouldn't even be on this list. I'd just download tarballs and do what I felt like. I'd like to think we're all on this list because we're better than that.
Fine.
But this isn't procmail, nor SpamAssassin; they're at the other end of the hall; third and fifth doors on the right, respectively.
This is a mailing list program.
This is a tool that users attach trust to, and that trust is that we won't abuse their mailbox and will send them what we tell them we'll send them. If they stop trusting the tool, they'll stop using it. So we have a responsibility (if not to those users, to the TOOL) to do what we can to protect that trust a user attaches to the program when they agree to subscribe to a mail list through it.
Letting spam through likely only gets you yelled at; accidentally blocking important stuff gets you burned.
No, actually, both get you yelled at and/or burned, depending on who gets upset about what. At some level, it's a no-win situation....
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Yes, I am an agent of Satan, but my duties are largely ceremonial.
On Tue, Jul 16, 2002 at 10:33:20PM -0700, Chuq Von Rospach wrote:
On 7/16/02 9:22 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
Well, ok... but in a case like that, your mailer logs would likely have the appropriate information. But still, as rare as such a circumstance is, I don't see that you have any moral obligation to be *that* prepared.
How many people keep their logs three weeks? How many people long ago stopped keeping detailed SMTP logs because of their size? And rare as the circumstance is, if YOUR house was burned down, would you still care that it was rare? (it's real easy to say "don't care, it's someone else's house...")
No, but I wouldn't hold the list op responsible for not keeping the info, if not keeping the info was their policy all along. I might *yell at them*, cause I think it's a stupid policy, but that's a llama of a different color...
Stipulated. But I don't believe that the toaster *is* cheap and shoddy -- ie: that it's *your* responsibility -- merely because people break into your house, and jam oversized bagels into your toaster repeatedly until it won't hold toast anymore.
Take a look at the court system. You're so far in the minority it's not funny (really not funny). Have you ever read the instruction manual for a toaster? The warning pages in the instruction manual, that say things like "do not use toaster in shower"? Because if they DON'T say that, they get sued because someone does?
Case law? Yes, there are silly disclaimers, yes some of them correspond directly to cases. Hair dryer in shower, yes. *Toaster*? Naw; if that has a shower disclaimer, it's merely ass-covering.
Except that the spam isn't the *problem*. The *spammers* are.
Sorry. That's like saying "bullets aren't a problem, guns are". If you get shot, you don't waste time arguing semantics like this. Unless, I guess, you're a libertarian. But frankly, most of the libertarians I know who HAVE been shot (instead of arguing about what they'd do if, theoretically, they were shot) stop arguing semantics, too.
No, neither bullets *nor* guns are the problem: *CRIMINALS ARE*.
I sometimes question why I have to keep pointing that out.
I call your attention, on the side topic, to Kennesaw, Georgia, the town that instituted the city ordinance some years ago *requiring* all heads to household to keep firearms:
http://www.mcsm.org/kennesaw.html
I *really* think this is pertinent, I'm not just trying to change the subject. How many libertarians do you know who have been shot? How many of them were shooters, themselves?
Even when they get unreasonably strident, and scream for all the wrong reasons -- and they do -- I still back the Second Amendment absolutists, because history has proven that they *put that amendment in there for a reason*.
That would be a fun argument, but I'll spare the list. Pass. (but if you look at the historical record of the debates over the amendment, it's a lot more ambiguous what the founding fathers THOUGHT, vs. how it's been interpreted. But, pass...)
"for the common defense" was loudly shouted down as clouding the point; that's good enough for me. If you're interested in bandying this, we can do it off list; maybe I'll learn something. :-)
It is largely because of RMS' intransigience on many points related to Free Software that we have most of it, and most particularly Linux -- I really don't believe it would have happened at all except for the developer-protection provided by the GPL.
And off we go into left field, to blame something completely tangential to the issue at hand.
Oh, never mind, pass.
Sometimes a cigar *is* just a cigar.
That's what monica said, too.
Sometimes, you've got to let junior take the fall.
Why? How very libertarian of you. May you never find someone calling you junior... (it's easy to say "let them eat cake" when you aren't starving with them. At least until the wagon arrives....)
Not at all. It's not a question of ease. Undertaking responsibility is not easy.
No, ducking responsibility is easy. Undertaking responsbility, however, is how things get done.
Someone has to fix the problem. It has been proven to my satisfaction that the technologists can't: it's not a technology-fix problem (so few 'problems' are). Someone has to get *pissed*.
That'd be the people with the mailboxes, Bob.
Wrong. It's the people with the skillset. Lots of people have mailboxes. Few people have the skillsets. But those people, it seems, are willing to let others rot, because it's easier for them personally. Well, some of them.
You may choose to think that this is my real motivation if you're so inclined. If I think that people who don't want to be swamped in spam ought to learn how to use the already available tools to avoid it, and you think that makes me elitist, so be it; I've been called elitist before.
Look, if I wanted easy, I wouldn't even be on this list. I'd just download tarballs and do what I felt like. I'd like to think we're all on this list because we're better than that.
Well, that sounds like a fairly broad ad hominem... but I think you're better than that. ;-)
Fine.
But this isn't procmail, nor SpamAssassin; they're at the other end of the hall; third and fifth doors on the right, respectively.
This is a mailing list program.
This is a tool that users attach trust to, and that trust is that we won't abuse their mailbox and will send them what we tell them we'll send them. If they stop trusting the tool, they'll stop using it. So we have a responsibility (if not to those users, to the TOOL) to do what we can to protect that trust a user attaches to the program when they agree to subscribe to a mail list through it.
Letting spam through likely only gets you yelled at; accidentally blocking important stuff gets you burned.
No, actually, both get you yelled at and/or burned, depending on who gets upset about what. At some level, it's a no-win situation....
Yeah; great, ain't it?
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
On 7/17/02 8:39 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:
No, but I wouldn't hold the list op responsible for not keeping the info,
YOU wouldn't, but that's not the typical response. It's unsafe to take "my response" and use it to generalize to "all users", unless you really know you're thinking like the average/typical user.
Take a look at the court system. You're so far in the minority it's not funny (really not funny). Have you ever read the instruction manual for a toaster? The warning pages in the instruction manual, that say things like "do not use toaster in shower"? Because if they DON'T say that, they get sued because someone does?
Case law? Yes, there are silly disclaimers, yes some of them correspond directly to cases. Hair dryer in shower, yes. *Toaster*? Naw; if that has a shower disclaimer, it's merely ass-covering.
You may see it as ass-covering. Have you talked to your lawyers recently about these issues? I have. Not fun, either.
Except that the spam isn't the *problem*. The *spammers* are.
Sorry. That's like saying "bullets aren't a problem, guns are". If you get shot, you don't waste time arguing semantics like this. Unless, I guess, you're a libertarian. But frankly, most of the libertarians I know who HAVE been shot (instead of arguing about what they'd do if, theoretically, they were shot) stop arguing semantics, too.
No, neither bullets *nor* guns are the problem: *CRIMINALS ARE*.
Except that most people shot in their own home are shot by their own gun by someone they know, not a criminal. Or, at least, they're not a criminal until the bullet hits. You're strawmanning again, jay.
This is, in fact, a great example in the real world of the situation I had this weekend in the email world. The poor idiot who spammed my users out of his address book wasn't a criminal -- until the minute he made that mistake in judgement and sent that e-mail. So while it's fun to run around screaming about the criminals being the problem, the most common problems we face are otherwise reasonable people who make mistakes or have lapses in judgement, not the guy in the alley with the gun and the blackjack. But it's a lot easier to talk about criminals and build a rhetoric and avoid having to deal with the tough situation of finding ways to protect people from their lapses, where there was no conscious intent to do something.
I sometimes question why I have to keep pointing that out.
Because you're having trouble convincing us you're right. Because you aren't. Because you're building a strawman that fits your philosophy but not the reality.
interpreted. But, pass...)
"for the common defense" was loudly shouted down as clouding the point; that's good enough for me. If you're interested in bandying this, we can do it off list; maybe I'll learn something. :-)
Nope. Pass. I'm already too close to a philosophical argument that'll drive this list bonkers. I'm not crossing the line... I hope.
You may choose to think that this is my real motivation if you're so inclined.
Thank you. Because if it looks like a duck and smells like a duck, it rhymes with Niagara. Oh, wait....
Well, that sounds like a fairly broad ad hominem... but I think you're better than that. ;-)
Yeah. Usually my ad hominens are more narrowly targeted. I'll try harder next time.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Someday, we'll look back on this, laugh nervously and change the subject.
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> This is, in fact, a great example in the real world of the
CVR> situation I had this weekend in the email world. The poor
CVR> idiot who spammed my users out of his address book wasn't a
CVR> criminal -- until the minute he made that mistake in
CVR> judgement and sent that e-mail. So while it's fun to run
CVR> around screaming about the criminals being the problem, the
CVR> most common problems we face are otherwise reasonable people
CVR> who make mistakes or have lapses in judgement, not the guy in
CVR> the alley with the gun and the blackjack. But it's a lot
CVR> easier to talk about criminals and build a rhetoric and avoid
CVR> having to deal with the tough situation of finding ways to
CVR> protect people from their lapses, where there was no
CVR> conscious intent to do something.Ah, now here's our angle. We're actually fighting cyberterrorists. I can almost tastest the Department of Homeland Security grants.
CVR> Nope. Pass. I'm already too close to a philosophical argument
CVR> that'll drive this list bonkers. I'm not crossing the
CVR> line... I hope.Thanks. While I love a fiesty political debate as much as the next guy (really!), this list is definitely off-topic for it.
-Barry
"JRA" == Jay R Ashworth <jra@baylink.com> writes:
JRA> Mutt's highlighting regexes are pretty decent, but I don't
JRA> know that *any* RE can match both quoted and non-quoted
JRA> mailbox names reliably.You have to invoke the 80/20 rule or you'll either go insane, or duplicate mail-extr.el's syntax driven state machine in your programming language of choice.
JRA> There's an argument going on somewhere else right now -- I
JRA> thought it was bugtraq, but I seem to have misplaced the
JRA> message -- about whether email addresses can have an RHS that
JRA> terminates in a .
JRA> The poster says no way, I say that 2821 and 1034/5 say yes.I'm not sure. 2822 would be the definitive RFC wouldn't it?
-------------------- snip snip -------------------- addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / obs-local-part = word *("." word) word = atom / quoted-string atom = [CFWS] 1*atext [CFWS] -------------------- snip snip --------------------
It would seem that the local-part can't end in a `.'.
JRA> Someone has to fix the problem. It has been proven to my
JRA> satisfaction that the technologists can't: it's not a
JRA> technology-fix problem (so few 'problems' are). Someone has
JRA> to get *pissed*.In a different context, the same question: do you think the corporate fraud reforms now being debated in congress will solve the problem? People /are/ pissed and are demanding both technological and non-technological fixes. But maybe it's just 3am and I'm starting to hallucinate. ;)
I can't give any definite examples to protect the people involved, but I know of a couple of people who've had their careers significantly impacted because of this stuff. Maybe not fatal, but third degree burns.
JRA> The topic being false-positive-ly blocked "spam", aren't
JRA> those evidence for the prosecution, not the defense?False positives don't scare me, but that's because we've got at least 5 volunteer postmasters screening the reports and rescuing probably 1 message a week, if that. What happens when the true-positives start making a stink because they demand that their spam get through?
JRA> Letting spam through likely only gets you yelled at;
JRA> accidentally blocking important stuff gets you burned.
JRA> We are on the critical path, folks. I know you know that,
JRA> but the explicit reminder isn't going to get me fired.
JRA> Fail-safe isn't just for aerospace anymore.In a way I agree, but by the same token, email is such a flakey system throughout that I think people have fairly low expectations that a message they send will get delivered, read, and answered. If you positively must get an answer to a question and in a hurry, email's a lousy way to ensure that.
-Barry
On Wed, Jul 17, 2002 at 03:09:28AM -0400, Barry A. Warsaw wrote:
JRA> There's an argument going on somewhere else right now -- I JRA> thought it was bugtraq, but I seem to have misplaced the JRA> message -- about whether email addresses can have an RHS that JRA> terminates in a . JRA> The poster says no way, I say that 2821 and 1034/5 say yes.I'm not sure. 2822 would be the definitive RFC wouldn't it?
I hoped someone would bite. :-)
2822 3.4.1 says that the *LHS* cannot have a trailing dot without quoting it... but in the next graf, it seems to punt the interpretation of "domain" to 1034.
-------------------- snip snip -------------------- addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / obs-local-part = word *("." word) word = atom / quoted-string atom = [CFWS] 1*atext [CFWS] -------------------- snip snip --------------------
It would seem that the local-part can't end in a `.'.
[ looks closer ]
... due to the interpretation of dot-atom-text.
You're right, that *is* what the standard says, and I'm surprised they left it that way in the rewrite; that is *not* the way it should have been done. There are good reasons why you might want to terminate a domain name, even in email -- though mostly diagnostic ones, admittedly.
JRA> Someone has to fix the problem. It has been proven to my JRA> satisfaction that the technologists can't: it's not a JRA> technology-fix problem (so few 'problems' are). Someone has JRA> to get *pissed*.In a different context, the same question: do you think the corporate fraud reforms now being debated in congress will solve the problem? People /are/ pissed and are demanding both technological and non-technological fixes. But maybe it's just 3am and I'm starting to hallucinate. ;)
No, I think that contemplating prison time, even sweeping the golf traps at Eglin AFB, will adjust the threat estimate of the corporate execs making the judgement calls.
No one's going to try to hijack an American plane ever again, either. :-}
I can't give any definite examples to protect the people involved, but I know of a couple of people who've had their careers significantly impacted because of this stuff. Maybe not fatal, but third degree burns.
JRA> The topic being false-positive-ly blocked "spam", aren't JRA> those evidence for the prosecution, not the defense?False positives don't scare me, but that's because we've got at least 5 volunteer postmasters screening the reports and rescuing probably 1 message a week, if that. What happens when the true-positives start making a stink because they demand that their spam get through?
Commercial speech is not protected by the first amendment, and the theft-of-service people are likely to win the civil suits, IMHO (IANAL :-)
JRA> Letting spam through likely only gets you yelled at; JRA> accidentally blocking important stuff gets you burned. JRA> We are on the critical path, folks. I know you know that, JRA> but the explicit reminder isn't going to get me fired. JRA> Fail-safe isn't just for aerospace anymore.In a way I agree, but by the same token, email is such a flakey system throughout that I think people have fairly low expectations that a message they send will get delivered, read, and answered.
I don't think so, and I surmise that Chuq might not either...
If youpositively must get an answer to a question and in a hurry, email's a lousy way to ensure that.
Stipulate on that point, but still...
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
On Wed, Jul 17, 2002 at 03:09:28AM -0400, Barry A. Warsaw wrote:
JRA> I hoped someone would bite. :-):)
JRA> 2822 3.4.1 says that the *LHS* cannot have a trailing dot
JRA> without quoting it... but in the next graf, it seems to punt
JRA> the interpretation of "domain" to 1034.Which circular references back to RFC 822. :)
But anyway I thought we were talking about the localpart.
JRA> You're right, that *is* what the standard says, and I'm
JRA> surprised they left it that way in the rewrite; that is *not*
JRA> the way it should have been done. There are good reasons why
JRA> you might want to terminate a domain name, even in email ----------------------------------------------------^ Did you leave out "with a dot" ? JRA> though mostly diagnostic ones, admittedly.
Hmm, not a use case I've ever encountered. "localhost.localdomain" is about as wacky as it gets.
-Barry
On Wed, Jul 17, 2002 at 05:26:11PM -0400, Barry A. Warsaw wrote:
JRA> 2822 3.4.1 says that the *LHS* cannot have a trailing dot JRA> without quoting it... but in the next graf, it seems to punt JRA> the interpretation of "domain" to 1034.Which circular references back to RFC 822. :)
But anyway I thought we were talking about the localpart.
No, I was talking about the domain part.
The standard is pretty clear that the LHS can have anything in it you want, as long as you quote it.
JRA> You're right, that *is* what the standard says, and I'm JRA> surprised they left it that way in the rewrite; that is *not* JRA> the way it should have been done. There are good reasons why JRA> you might want to terminate a domain name, even in email ----------------------------------------------------^ Did you leave out "with a dot" ?
No; domain names that end in a dot are referred to in jargon as "terminated" or "rooted". At least, the jargon I'm used to...
JRA> though mostly diagnostic ones, admittedly.Hmm, not a use case I've ever encountered. "localhost.localdomain" is about as wacky as it gets.
Well, diagnosing local DNS configuration, mostly. A name that does *not* end in a dot is supposed to be an invitation to apply the search list from /etc/resolv.conf.
With people having things registered like com.com and edu.com, it can get a bit wacky.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
"JRA" == Jay R Ashworth <jra@baylink.com> writes:
JRA> No, I was talking about the domain part.Ok.
JRA> The standard is pretty clear that the LHS can have anything
JRA> in it you want, as long as you quote it.Yeah, but then it wouldn't /technically/ end in a dot, would it? :) Okay, okay, I'm being pedantic.
>> Hmm, not a use case I've ever encountered.
>> "localhost.localdomain" is about as wacky as it gets.
JRA> Well, diagnosing local DNS configuration, mostly. A name
JRA> that does *not* end in a dot is supposed to be an invitation
JRA> to apply the search list from /etc/resolv.conf.
JRA> With people having things registered like com.com and
JRA> edu.com, it can get a bit wacky.Ah, ok. -Barry
On Thu, Jul 18, 2002 at 02:19:19PM -0400, Barry A. Warsaw wrote:
"JRA" == Jay R Ashworth <jra@baylink.com> writes: JRA> No, I was talking about the domain part.
Ok.
JRA> The standard is pretty clear that the LHS can have anything JRA> in it you want, as long as you quote it.Yeah, but then it wouldn't /technically/ end in a dot, would it? :) Okay, okay, I'm being pedantic.
Usually. In this case, you're actually incorrect, alas. The quotation marks are not semantically part of the address. So it *does* end in a dot. (Yes, I know you were being a smart ass.)
>> Hmm, not a use case I've ever encountered. >> "localhost.localdomain" is about as wacky as it gets. JRA> Well, diagnosing local DNS configuration, mostly. A name JRA> that does *not* end in a dot is supposed to be an invitation JRA> to apply the search list from /etc/resolv.conf. JRA> With people having things registered like com.com and JRA> edu.com, it can get a bit wacky.Ah, ok.
Actually, a "bit" might be an understatement...
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> 1) I (as the list admin to the recipient) am offering a
CVR> service. I strongly believe that if I'm offering a service, I
CVR> have an ethical (if not legal) responsibility to make that
CVR> service as problem free as possible.Wow, I guess you don't read many EULAs do ya? :)
your-problem-son-is-ya-got-morals-ly y'rs, -Barry
P.S. Someday soon you/we may indeed have that legal responsibility. Although obviously a worthy goal, I'm actually a little fearful of what that'll mean for free software.
On 7/16/02 11:39 PM, "Barry A. Warsaw" <barry@zope.com> wrote:
Wow, I guess you don't read many EULAs do ya? :)
your-problem-son-is-ya-got-morals-ly y'rs,
I can sleep at night, too. But then, I believe in doing what I think is right, not what I can get away with as legal. If that bothers you, sue me...
(heh)
P.S. Someday soon you/we may indeed have that legal responsibility. Although obviously a worthy goal, I'm actually a little fearful of what that'll mean for free software.
Sorry, I just don't think they'l suceed at nuking free software. Too much big business depends on it now. Vigilance is good, but when push comes to shove, the ones that are trying to screw it up won't succeed.
Besides, fi the US outlaws it, like, oh, stem cell research, it'll just slide overseas out of the US jurisdiction, and the US will find that over time, it'll be ata competitive disadvantage because of it...
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
The first rule of holes: If you are in one, stop digging.
On Tue, Jul 16, 2002 at 11:46:12PM -0700, Chuq Von Rospach wrote:
Sorry, I just don't think they'l suceed at nuking free software. Too much big business depends on it now. Vigilance is good, but when push comes to shove, the ones that are trying to screw it up won't succeed.
Besides, fi the US outlaws it, like, oh, stem cell research, it'll just slide overseas out of the US jurisdiction, and the US will find that over time, it'll be ata competitive disadvantage because of it...
You haven't been following the SSSCA/CBDPTA traffic, have you.
It will be illegal, but more importantly, it simply won't *run* -- you can't store data on the hard drive if you don't have the encryption keys to talk to it.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
On 7/17/02 8:47 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:
You haven't been following the SSSCA/CBDPTA traffic, have you.
It will be illegal, but more importantly, it simply won't *run* -- you can't store data on the hard drive if you don't have the encryption keys to talk to it.
Yes, I have, actually.
And you'll notice, maybe, what company I work for.
They have to get that onto our hard disks first. The lemmings might accept it (but given how quickly they're upgrading to Windows XP, I think maybe you underestimate their ability to realize when they're being screwed), but not all of the world are lemmings.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms).
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
>> Wow, I guess you don't read many EULAs do ya? :)
>> your-problem-son-is-ya-got-morals-ly y'rs,
CVR> I can sleep at night, too. But then, I believe in doing what
CVR> I think is right, not what I can get away with as legal. If
CVR> that bothers you, sue me...
CVR> (heh)Now we understand why neither of us are CEOs of large US corporations, or high ranking US goverment officials. :)
>> P.S. Someday soon you/we may indeed have that legal
>> responsibility. Although obviously a worthy goal, I'm actually
>> a little fearful of what that'll mean for free software.
CVR> Sorry, I just don't think they'l suceed at nuking free
CVR> software. Too much big business depends on it now. Vigilance
CVR> is good, but when push comes to shove, the ones that are
CVR> trying to screw it up won't succeed.You're definitely more optimistic than I am. When Hollywood, the RIAA, and Microsoft team up against it, and the h/w manufacturers capitulate or risk being tarred as un-Americans aiding cyberterrorism I think we have an up-Hill (sic) battle.
can-we-kill-this-thread-now?-ly y'rs, -Barry
On 7/17/02 1:08 PM, "Barry A. Warsaw" <barry@zope.com> wrote:
You're definitely more optimistic than I am. When Hollywood, the RIAA, and Microsoft team up against it, and the h/w manufacturers capitulate or risk being tarred as un-Americans aiding cyberterrorism I think we have an up-Hill (sic) battle.
But there are a whole lotta other companies banding together to build stuff using open standards and open software. Apple today announced new work with sony erriccson and cingular on GPRS and bluetooth, for instance (kewl stuff), and is openly supporting open standards instead of trying to lock people into proprietary ones.
Just because some companies are trying to wall off the internet doesn't mean they will. Remember, AOL tried that for years, and finally had to connect in and join the net, too. The net is going to prove pretty hard to kill.
can-we-kill-this-thread-now?-ly y'rs,
Sure.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after
On Wed, Jul 17, 2002 at 02:03:09PM -0700, Chuq Von Rospach wrote:
On 7/17/02 1:08 PM, "Barry A. Warsaw" <barry@zope.com> wrote:
You're definitely more optimistic than I am. When Hollywood, the RIAA, and Microsoft team up against it, and the h/w manufacturers capitulate or risk being tarred as un-Americans aiding cyberterrorism I think we have an up-Hill (sic) battle.
But there are a whole lotta other companies banding together to build stuff using open standards and open software. Apple today announced new work with sony erriccson and cingular on GPRS and bluetooth, for instance (kewl stuff), and is openly supporting open standards instead of trying to lock people into proprietary ones.
Just because some companies are trying to wall off the internet doesn't mean they will. Remember, AOL tried that for years, and finally had to connect in and join the net, too. The net is going to prove pretty hard to kill.
You obviously have not been following the activities of Senator Hollings, D-Disney, whose SSSCA indeed wants to make the very *design* of Linux illegal.
Google for SSSCA. Check it out.
*Apple* will likely be on the winning side.
Linux wont, at least not in the bill's current shape.
Please, nobody tell Hollings about CS First Boston and the NYSE, not to mention a large chunk of the backbone. I wanna see what happens when everyone just shuts their Linux boxes down because they've been declared illegal.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
- On 2002.07.18, in <20020718102426.48111@scfn.thpl.lib.fl.us>,
- "Jay R. Ashworth" <jra@baylink.com> wrote:
You obviously have not been following the activities of Senator Hollings, D-Disney, whose SSSCA indeed wants to make the very *design* of Linux illegal.
How does this conflict with the design of Linux (or, presumably, any other operating system)? Why is it not possible to integrate DRM support into Linux?
Please, nobody tell Hollings about CS First Boston and the NYSE, not to mention a large chunk of the backbone. I wanna see what happens when everyone just shuts their Linux boxes down because they've been declared illegal.
Existing systems are grandfathered. It's not clear (to me) whether this applies only to hardware devices, or also to software; or whether a device wishing to be grandfathered needs to be sponsored by some legal entity.
Not that I support the SSSCA; I just think it pays better to fight on fair terms.
-- -D. Fresh fruit enriches everyone. Takes the thirst ENSA, NSIT out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. dgc@uchicago.edu We all know that. It's why everyone loves fruit.
"DC" == David Champion <dgc@uchicago.edu> writes:
DC> Not that I support the SSSCA; I just think it pays better to
DC> fight on fair terms.But not here, please. I know we've all got very strong feelings about these issues, but we need to keep this list focussed. Plus I don't have time to weed through all these messages. ;)
list-mom-ish-ly y'rs, -Barry
On Thu, Jul 18, 2002 at 12:34:37PM -0500, David Champion wrote:
- On 2002.07.18, in <20020718102426.48111@scfn.thpl.lib.fl.us>,
- "Jay R. Ashworth" <jra@baylink.com> wrote:
You obviously have not been following the activities of Senator Hollings, D-Disney, whose SSSCA indeed wants to make the very *design* of Linux illegal.
How does this conflict with the design of Linux (or, presumably, any other operating system)? Why is it not possible to integrate DRM support into Linux?
Because the open design of Linux makes it impossible to *hide* the things which the law would required be hidden.
I didn't make this stuff up; look here:
http://www.linuxplanet.com/linuxplanet/opinions/3813/1/ http://www.troubleshooters.com/tpromag/200111/200111.htm#_SSSCAsBitterHarves... http://old.lwn.net/2001/1025/ http://www.sonic.net/~rknop/rant.html#sssca
and a whole lotta buncha stuff here:
http://dmoz.org/Society/Issues/Intellectual_Property/Copyrights/Consumer_Bro...
one of the pieces in which is exceptionally good:
http://www.networkcomputing.com/buzzcut/bc24sep01.html
Please, nobody tell Hollings about CS First Boston and the NYSE, not to mention a large chunk of the backbone. I wanna see what happens when everyone just shuts their Linux boxes down because they've been declared illegal.
Existing systems are grandfathered. It's not clear (to me) whether this applies only to hardware devices, or also to software; or whether a device wishing to be grandfathered needs to be sponsored by some legal entity.
The final outcome will be that no one will manufacture non-SSSCA compliant peripherals like, oh, *hard drives*... and since Linux will not be able to talk to the encrypted ones, it won't *matter* that it's considered a "circumvention device", it just won't be able to run at all.
Not that I support the SSSCA; I just think it pays better to fight on fair terms.
So do I.
In consequence of which I'm not sure what you mean by that.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
At 20:49 -0400 7/16/2002, Jay R. Ashworth wrote:
But *why isn't this the recipients' problem*?
Because the recipient gives up, and takes her ISP payments elsewhere, or really gives up and takes them nowhere (which I'm tempted to do myself when I retire).
--John
John Baxter jwblist@olympus.net Port Ludlow, WA, USA
On Tue, Jul 16, 2002 at 09:25:44PM -0700, John W Baxter wrote:
At 20:49 -0400 7/16/2002, Jay R. Ashworth wrote:
But *why isn't this the recipients' problem*?
Because the recipient gives up, and takes her ISP payments elsewhere, or really gives up and takes them nowhere (which I'm tempted to do myself when I retire).
The final expansion of that is "The Internet is Disney World; everything is safe; nothing requires care."
It ain't Afghanistan, either, but, really...
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
But *why isn't this the recipients' problem*?
Because the recipient gives up, and takes her ISP payments elsewhere, or really gives up and takes them nowhere (which I'm tempted to do myself when I retire).
The final expansion of that is "The Internet is Disney World; everything is safe; nothing requires care."
Disagree. The final expansion of that is "the internet is the shopping mall. You shouldn't have to worry about drive by shootings, but you may run into the occcasional pickpocket..."
(actually, pickpockets can be a significant problem in disney parks, but I didn't say that....)
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Very funny, Scotty. Now beam my clothes down here, will you?
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> Actually, yes. I won't be working 65+ hours a week any more,
CVR> so I sort of get my life back, and may actually have time to
CVR> think stuff through and do more than emergency
CVR> patching... (for more, see
CVR> <http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=348>). Also
CVR> means I can actually start some non-Apple hacking again, I
CVR> hope. And what I'll be doing is lots of fun, although the
CVR> next six weeks is going to be a crunch. Still doing email,
CVR> just off building a new custom system for stuff I can't talk
CVR> about...Very interesting, and congrats on getting your life back. Also, my apologies for not responding earlier, but I think you understand probably as well as anybody. :)
CVR> One thing we're definitely doing is moving to a cloaked CVR> archive. Since we already distribute all archives out of
So these are public archives that need to be scrubbed, right? Until now, Mailman has taken the approach that public archives are feed right off the file system by the http server. We could still do that if we scrubbed the messages before we archived them, although that doesn't help with existing archives unless you re-generate them.
CVR> Here's why I won't do that. I want to keep ONE set of
CVR> archives. You can't scrub those archives for two
CVR> reasons. What if someone writes looking to get in contact
CVR> with the author of a message? If the archive is scrubbed,
CVR> that info is gone. And (god forbid), you get into a legal
CVR> tangle? That's your legal record of what was said on the mail
CVR> list and who said it. If you scrub it, and someone does
CVR> something actionable or libelous and you get a court order to
CVR> provide that data? You're hosed.Excellent points all, I completely agree.
CVR> On a more likely note -- I can see where you might want the
CVR> option to show the archives unscrubbed to validated users,
CVR> and only scrub the public archives. As paranoid as I'm being
CVR> today, I'd STILL like to find a way to let subscribed users
CVR> see the archives unscrubbed. Which you could do by setting a
CVR> cookie that the CGI could accept and change it's behavior.Yup, all possible if we give up the notion of vending the public archives from disk. We pay in cpu, but oh well, that's cheap these days, isn't it?
CVR> So I really like leaving the archives unmodified, and doing
CVR> the scrubbing via CGI. It also allows you do to other things,
CVR> like header cleanups (and you could potentially let a user
CVR> set a cookie to define minimal or full headers, say...) and
CVR> some quickie cleanup against unwrapped text and some other
CVR> incidental archive glitches.
CVR> I come from a newspaper family, so I have a bias towards "you
CVR> don't unpublish stuff, you don't change it once it's
CVR> published". But I think there are good reasons to avoid
CVR> sanitizing the archives, and instead sanitizing the delivery
CVR> of those archives -- if only because if your policies change,
CVR> all you need to change is the CGI. And it gives you the
CVR> ability to set up different sets of abilities per user or per
CVR> list if you want, too.Again, excellent points.
So one question is: does the performance trade-off we made 5 years ago still make sense? Should we just be vetting all archives through a cgi, in which we can do fun stuff like cleanse it of email addresses?
CVR> One of the big things I dislike about Mhonarc is that
CVR> archives are a rather low-usage system, but maintaining the
CVR> Mhonarc index pages is rather intensive use of system
CVR> resources. Sort of like usenet -- you do a lot of work on
CVR> everything, in case someone wants anything. I think simply
CVR> storing the archives and sanitizing on demand is lower
CVR> overhead. It also means pipermail won't need ANY changes --
CVR> you simply feed it out through the CGI instead of directly,
CVR> and everything magically sanitizes...Yup. Wanna help write the script?
We'd obviously have to get rid of the easy access to the raw mbox file, so another question is whether that's still useful.
CVR> Honestly? I don't think so. I find them real kludgy. I ended
CVR> up doing a new archiving system (one file per message) via a
CVR> perl script. We're about to take our new search engine out of
CVR> beta with the thing, finally.I find the mboxes really handy for gathering statistics, but maybe because Python has some really nice tools to troll through them (e.g. we use the python-list mbox to stress ZODB). And it's also handy if you move lists, but I think that's about it. I'm sure "regular users" wouldn't care if we hid the mboxes. BTW, that's all true even if you go to a one-file-per-message layout a la mh.
Also, what heuristic do you use to search for email addresses, and what do you scrub them with?
CVR> Still being worked on. Right now, I'm basically doing a
CVR> <wordboundary><nonwhitespace>@<nonwhitespaceordot><dot>nonwhitespace><wordbo
CVR> undary>. I don't know how strongly we'll refine it.Cool.
Do you want to attempt to obscure the address (e.g. "barry--at--python--dot--org")
CVR> Anything you programmatically obscure will be
CVR> programmatically de-obscured. This technique is bogus and
CVR> guaranteed to fail as soon as the spammers care enough. It's
CVR> pretty clear even the "randomized obscuring" of slashdot is a
CVR> failed technique, since spambots don't have to decode ALL of
CVR> those formats, just some of them, and then cycle throug the
CVR> site enough times....
CVR> Sorry, I find this is a false security. Makes the users feel
CVR> better, accomplishes nothing useful, so in reality, users get
CVR> lazy and careless. So to some degree, I feel it's worse than
CVR> nothing. I'm planning on replacing email addresses with
CVR> something useful like [email address deleted].Agreed.
CVR> disclosing that info. It creates other problems -- you can't CVR> see a posting in the archive and send email to that person CVR> with more questions (or answers), but that seems trivial CVR> compared to the problems the spammers are causing.
It kind of plays into Reply-To: munging doesn't it? If you won't be able to reply to the original author, because we're anonymizing messages, then you might as well munge Reply-To: to go back to the list because that's the only posting address that makes sense.
CVR> Yes (he says, grimacing).:)
CVR> If you sanitize the archives, I don't think it affects the
CVR> list. There are simply NO mailtos any more in the archives.
CVR> If you go the step further and anonymize the postings ON the
CVR> list, so subscriber email addresses simply are never shown to
CVR> other subscribers under any circumstances (ugh. Urp. I can't
CVR> believe I'm saying that. This is so anti-community it hurts),
CVR> you have no choice and reply-to has to point to the list,
CVR> since it's the only contact point left.Yup.
CVR> If you instead turn the list server into a forwarding agent,
CVR> as in:Or should Mailman get into the anonymous resender game? There's probably a lot we could do here, but given the political risks of anonymous resenders, do we even want go there?
CVR> Is it an anonymous remailer? We're making no pretense of
CVR> anonymity here. We're acting as a forwarding agent, ala
CVR> hotmail.com or mac.com. You mail to id13194@python.org, and
CVR> it ends up in my mailbox. The fact that we're not explicitly
CVR> denoting the real email address doesn't make us an anonymous
CVR> remailer -- that'd be a policy issue, actually. I suppose you
CVR> could take it that step further, but you could also set it up
CVR> so validated subscribers could get to the real addresses.
CVR> The model I'm thinking of is like many forum systems. If
CVR> you're a guest, you don't get access to email info. If you're
CVR> a subscriber, you log on, and they magically appear. In the
CVR> case of mailing lists, since oyu lose control of the e-mail
CVR> address once it leaves the site again, you handle this by
CVR> only using the remailer address in mail that leaves the site,
CVR> but a subscriber could go to the list system and look a user
CVR> up. That gets us away from the politics of the anonymous
CVR> stuff.Hmm, maybe you're right. You've got to keep those random forwarding addresses alive for a long (configurable) time so that replies will continue to work.
CVR> You have nailed it on the head. Which is why I brought it
CVR> up. Not because this is the way it has to be in the future,
CVR> but because all this is making Mailman's job a whole lot more
CVR> complex (we were whining about that at work today, or at
CVR> least I was and everyone was nodding sympathetically and
CVR> looking for an open window -- email used to be pretty easy
CVR> and straight forward. And now.....). But not just because all
CVR> this crap is getting in the way, but also that fixing this
CVR> crap is overkill for some environments, and going to be NOT
CVR> ENOUGH in others.Exactly. Here's the trick: for those who it is not enough, get them to pay enough for it that it could sustain a business. That way, you keep the overkill crowd happy with the free stuff, which the super paranoid help subsidize.
CVR> Damn, that sounds good, but -- I've had to give up crab and
CVR> shellfish (I've developed an intermitten sensitivity to
CVR> it. Sigh!) and I'm staying in cupertino where I'll be manning
CVR> the war room this week making sure buttons get pushed when
CVR> they need pushed, and not a minute before....Ah too bad (about both!). The offer of some cold ones (of a liquid of your choice) stands if you ever make it to DC. :)
-Barry
On Tue, 16 Jul 2002 21:34:16 -0400 Barry A Warsaw <barry@zope.com> wrote:
Hmm, maybe you're right. You've got to keep those random forwarding addresses alive for a long (configurable) time so that replies will continue to work.
Really?
How about a dated address which works transparently for a week then reverts to a TMDA-like filter for another fortnight, and then dies?
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
Hmm, maybe you're right. You've got to keep those random forwarding addresses alive for a long (configurable) time so that replies will continue to work.
Really?
How about a dated address which works transparently for a week then reverts to a TMDA-like filter for another fortnight, and then dies?
What happens when someone sees an address in the archive six months from now and needs to contact that author?
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Yes, I am an agent of Satan, but my duties are largely ceremonial.
Chuq Von Rospach <chuqui@plaidworks.com> writes:
How about a dated address which works transparently for a week then reverts to a TMDA-like filter for another fortnight, and then dies?
What happens when someone sees an address in the archive six months from now and needs to contact that author?
When you send e-mail to an expired 'dated' address such as the one in my Reply-To header, TMDA will just prompt the sender for confirmation. This is the default behavior, but you can also configure it to drop, deliver or bounce mail to an expired dated address.
-- (http://tmda.net/)
On Tue, 16 Jul 2002 17:37:45 -0400 Barry A Warsaw <barry@zope.com> wrote:
We'd obviously have to get rid of the easy access to the raw mbox file, so another question is whether that's still useful. Occasionally it's damn handy if you're moving a list or gathering statistics on it, but on the other hand, it's a rich source of addresses to mine.
I don't supply mboxes (or any other raw form of my archives). Providing mboxes or some other off-line form of the archives is the most common archive-related request I receive.
Also, what heuristic do you use to search for email addresses, and what do you scrub them with? Do you want to attempt to obscure the address (e.g. "barry--at--python--dot--org") or replace it altogether (e.g. "[hidden email address]"), or maybe just replace it with a truncation (e.g. "[localpart's email address]").
Long term I think dated addresses and/or TMDA-style filtering is the address.
My main complaint against TMDA is that it doesn't email an alert message to me ala, "Bubba tried to email you and I'm holding his message pending confirmation." I'd like to know about held messages, or at least be able to trivially know so that I can pro-actively act to white-list and let mail thru without the other side having to jump thru rude hoops.
It kind of plays into Reply-To: munging doesn't it? If you won't be able to reply to the original author, because we're anonymizing messages, then you might as well munge Reply-To: to go back to the list because that's the only posting address that makes sense. And what if the original poster isn't a member of the list?
Address mapping...
Or should Mailman get into the anonymous resender game? There's probably a lot we could do here, but given the political risks of anonymous resenders, do we even want go there?
Date limited address maps.
Any chance you could make it down to DC for a side trip? We could have a Mailman hacking sprint over a few dozen steamed Maryland blue crabs and some cold ones. :)
You might just drag me out to the other coast with offers like that.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
"JCL" == J C Lawrence <claw@kanga.nu> writes:
JCL> I don't supply mboxes (or any other raw form of my archives).
JCL> Providing mboxes or some other off-line form of the archives
JCL> is the most common archive-related request I receive.I'd like to better understand the motivation for those requests. In my cases I think it's because Pipermail archives don't give you two important things: posting replies via the web, and the ability to forward archive messages to an email address.
>> Any chance you could make it down to DC for a side trip? We
>> could have a Mailman hacking sprint over a few dozen steamed
>> Maryland blue crabs and some cold ones. :)
JCL> You might just drag me out to the other coast with offers
JCL> like that.August and September are prime crab-pickin' months y'know, and even though they're expensive this year, I'm not adversed to a quick morning hop down to the Eastern Shore for a bushel of jumbos. :)
paper-towels-are-for-wimps-and-old-bay-can-really-grease-a-laptop's- keyboard-not-to-mention-the-wild-goose-ly y'rs, -Barry
On Wed, 17 Jul 2002 03:28:31 -0400 Barry A Warsaw <barry@zope.com> wrote:
"JCL" == J C Lawrence <claw@kanga.nu> writes:
JCL> I don't supply mboxes (or any other raw form of my archives). JCL> Providing mboxes or some other off-line form of the archives is the JCL> most common archive-related request I receive.
I'd like to better understand the motivation for those requests. In my cases I think it's because Pipermail archives don't give you two important things: posting replies via the web, and the ability to forward archive messages to an email address.
Note: I don't use pipermail and my archives do support posting replies to the list via the web. (Details are in the FAQ) I don't currently support sending the original of an archives messages to a specified address.
The most common (almost 100%) reasoning given for wanting an off-line for is easy of searching and reference.
Any chance you could make it down to DC for a side trip? We could have a Mailman hacking sprint over a few dozen steamed Maryland blue crabs and some cold ones. :)
JCL> You might just drag me out to the other coast with offers like JCL> that.
August and September are prime crab-pickin' months y'know, and even though they're expensive this year, I'm not adversed to a quick morning hop down to the Eastern Shore for a bushel of jumbos. :)
Hehn. I'm originally from the Balitmore area. Me and my gut know munchin' crabs quite well.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
On 7/17/02 12:28 AM, "Barry A. Warsaw" <barry@zope.com> wrote:
"JCL" == J C Lawrence <claw@kanga.nu> writes:
JCL> I don't supply mboxes (or any other raw form of my archives). JCL> Providing mboxes or some other off-line form of the archives JCL> is the most common archive-related request I receive.
I'd like to better understand the motivation for those requests.
I get these requests, too. Some kind of "easy way to download the entire archives" -- from people who want a local copy for local searching (grep, etc). Unfortunately, since that also makes it trivial to harvest off of, I tell these folks I won't do that.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Someday, we'll look back on this, laugh nervously and change the subject.
J C Lawrence <claw@kanga.nu> writes:
My main complaint against TMDA is that it doesn't email an alert message to me ala, "Bubba tried to email you and I'm holding his message pending confirmation."
Not true.
See http://tmda.net/faq.cgi?req=show&file=faq01.006.htp
I'd like to know about held messages, or at least be able to trivially know so that I can pro-actively act to white-list and let mail thru without the other side having to jump thru rude hoops.
Somewhat related:
http://tmda.net/faq.cgi?req=show&file=faq01.005.htp
-- (http://tmda.net/)
On Tue, Jul 16, 2002 at 10:58:00AM -0700, Chuq Von Rospach wrote:
One thing we're definitely doing is moving to a cloaked archive. Since we already distribute all archives out of HTTP, not FTP, we're working on a CGI that'll strip all e-mail information out of messages on the fly (among other things, like header cleanup and some trivial formatting fixes). The idea is simple -- we've finally hit the point where you can't put an e-mail address up on a public site under any cirucmstance safely, so we're having to move to a system where we simply don't do that.
I'm voting in favor of the lynch mobs you mention later.
No, I mean *really*.
Two or three spammers getting shot; solve the problem right quick.
:-)
I'm going to look and see if I can interface TMDA to the subscriber databases so that subscribers are by definition whitelisted, but we've hit the point where we have to do this. I'm not happy about it, but the war is lost, I think.
And speaking of privacy, harvesting and spamming, a new and disturbing thing happened this weekend that I want to bring up -- one for which I have lots of questions, but no real answers. A bunch of users on some of our mail lists were spammed, and it became very clear very quickly that addresses were harvested off of at least one of our mail lists.
As you might guess, a lynch mob formed, and I lit the first virtual torch and we all sharpened the pitchforks. Fortunately, the person who did it came forward to me and admitted guilt, and explained what happened.
And what happened is pretty damn disturbing. See, he had one of those "I must tell the masses!" moments, where he finally felt it was time to send out a call to arms on a subject he felt strongly about.
So what he did was open up his address book and send his message to everyone in it. And he's running one of these new e-mail clients that happily caches addresses it sees in case you want them again. So all of the addresses of people posting to the mailing lists he subscribed to were in his address book cache, so when he grabbed his address book, he grabbed all of those addresses, too.
So we have a clear violation of our anti-harvesting rules -- yet he didn't overtly harvest. He just grabbed what was in his address book at the time.
This creates a major privacy quagmire. How do you set up rules for something like that? Where does ownership and protection end? (I'm talking ethically, not technically. I think we all realize that once someone posts email to a list, you've given up control to anyone who doesn't feel obligated to follow the rules). This wasn't a case of overtly violating the rules, but of a piece of technology creating a situation where it wasn't understood there were rules being violated.
And this is a *perfect* case that supports what has been my assertion all along -- you non-Libertarians out there, cover your ears and sing -- *it's the recipient's problem*. This case is exactly the illustration I want: I couldn't have written one better from scratch.
It's obvious that the answer is: setting up rules *would* *not* *have* *helped* *here*. Anyone who can demonstrate how it might have is welcome to post. If you send a message, it *has* to have a From address, and, to not violate the standards, that From address has to be valid. We all *want* that to be the case, right?
So what are you going to do?
Outlaw Outlook?
:-)
I just don't know how to deal with the issues this address caching causes.
The answer is that there is no answer. This might be the catalyst -- there had to be one eventually -- that inspires people to upgrade to Mail User Agents with sufficient flexibility to deal with problems like this.
Automatically verifying PGP sigs as a whitelisting technique is merely one approach that springs to mind. There are many more.
Ultimately, we're going to have to rethink our "no harvesting" rules, and likely also write disclaimers explaining what our limits are. We've actually considered switching our lists to obscured addresses, turned that down as being worse than the disease (for now). But now we're wondering if we have to go to some sort of address cloaking ON lists, maybe some kind of address remapping through the server for replies, something. And I'm gritting my teeth at the developers who created those @#$@$#@$#23 caches (which are nice in some ways) for not also creating some way to flag addresses as not cacheable. Because, IMHO, that'd solve this problem.
Yeah, but the Outhouse and OE teams aren't ever going there, and they're your problem.
At some point, if you're going to *have* a mailnbox, you *have* to take responsibility for it.
I stand on the non-enabler platform I've stood on before, as unpleasant as it is. In the end, I'm pretty sure there won't *be* any other options...
I'm curious what people think about this latest thing. The good news is he wasn't trying to harvest us. The bad news is, he wasn't trying to harvest us. And the b-tch of it is, I really don't have a comfortable feeling for how to deal with this new situation yet... But I think it's an issue we have to come to grips with.
See above. ;-)
Are we hitting a point where mail list servers have to act as blind front ends for all of the subscribers, where replies are processed by those servers, and the server then takes on the job of acting as a troll-exterminator and spam blocker? And what does that really mean for things like Mailman?
See less-above.
I've had the same mailbox for 7 years; and *some* mailbox for just about 20. Until I was intemperate enough to put that email address into a poorly chosen slot, I got maybe a couple spams a day... and that address is on 5 or 6 domains, half a dozen web pages, and *ALL OVER* Usenet.
And I *still* only got about half a dozen a day.
Now, it's 25-50.
People are known to say "it's not my fault", when, damnit, it *is* their fault. I'd say we need to make damned sure the problem is what we *think* it is before we "fix" that.
Do you have documentary evidence, Chuq, that web harversters are the *only* way that *a majority* of the spam-complainers addresses could have gotten on those lists? Have you created test-accounts? Not 1 or 2; a couple dozen, in different places?
Happy Macworld Expo week, all. If you need me, I'll be in the war room, beating my head against a wall.
You've got a war room? Cool.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
On 7/16/02 3:55 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
I'm voting in favor of the lynch mobs you mention later.
And this is a *perfect* case that supports what has been my assertion all along -- you non-Libertarians out there, cover your ears and sing -- *it's the recipient's problem*. This case is exactly the illustration I want: I couldn't have written one better from scratch.
But without rules, you can't teach the recipient what's right (with a cattle prod, if necessary), and without rules, the lynch mob has no binding authority.
It's obvious that the answer is: setting up rules *would* *not* *have* *helped* *here*.
Nope. But those rules are what allows you to go and make an example of the poor schmuck, in hopes that it'll keep the next person from making the same mistake. Wtihout the rules, there is no map you can use to teach people how to stay out of the tiger pits.
So what are you going to do?
Outlaw Outlook?
Don't blame outlook here. Lots of mail clients do this 'temporary caching'.
The answer is that there is no answer.
The answer is there IS an answer. Just not a complete or fully satisfying one.
The answer is multi-faceted:
rules that explicitly and unambiguously call out what is and isn't acceptable.
education systems to help users understand the situation and learn how to deal with it appropriately.
information that explains (and legally limits your liability for) the limits of what you can and can't do given all this technnology, so subscribers understand what you're doing and what you can't do anything about but (1) and (2) above.
a cattle prod for when all of the above fails.
patience of a saint, reaction times of a ranger.
Automatically verifying PGP sigs as a whitelisting technique is merely one approach that springs to mind. There are many more.
Sorry, doesn't really solve the problem. I posted a url to a note I wrote on this to barry a few minutes ago.
Yeah, but the Outhouse and OE teams aren't ever going there, and they're your problem.
Hint: this wasn't a windows box, and it wasn't a microsoft product. IT AIN'T MICROSOFT. Lots of clients do this now.
At some point, if you're going to *have* a mailnbox, you *have* to take responsibility for it.
Yes, but if you're going to distribute email, that doesn't remove your obligation to do what you can to protect the user from abuses in that distribution. BOTH sites and obligations and responsibilities.
Do you have documentary evidence, Chuq, that web harversters are the *only* way that *a majority* of the spam-complainers addresses could have gotten on those lists? Have you created test-accounts? Not 1 or 2; a couple dozen, in different places?
The person who did this has come clean to me. I know exactly what he did. It's about the only reason I've let him live. He hasn't always been, well, sending me christmas cards, but he's been fully cooperative.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
No! No! Dead girl, OFF the table! -- Shrek
On Tue, Jul 16, 2002 at 05:21:17PM -0700, Chuq Von Rospach wrote:
On 7/16/02 3:55 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
I'm voting in favor of the lynch mobs you mention later.
And this is a *perfect* case that supports what has been my assertion all along -- you non-Libertarians out there, cover your ears and sing -- *it's the recipient's problem*. This case is exactly the illustration I want: I couldn't have written one better from scratch.
But without rules, you can't teach the recipient what's right (with a cattle prod, if necessary), and without rules, the lynch mob has no binding authority.
Where, by "rules", here, we mean "rules about what it acceptable mail"?
Why, that's up to the recipients.
To quote Jubal Harshaw: "Who's name is on that envelope, Nurse? ... Oh: not yours."
It's obvious that the answer is: setting up rules *would* *not* *have* *helped* *here*.
Nope. But those rules are what allows you to go and make an example of the poor schmuck, in hopes that it'll keep the next person from making the same mistake. Wtihout the rules, there is no map you can use to teach people how to stay out of the tiger pits.
That sentence seems to assume that the majority of the people *falling in* the tarpits are people doing it by accident. I don' think that and I don't think *you* think that.
When mail is outlawed, only outlaws will send mail.
So what are you going to do?
Outlaw Outlook?
Don't blame outlook here. Lots of mail clients do this 'temporary caching'.
Stipulated, and NS6 does it too, though I think that Moz may not.
It *is* configurable, at least, in Netscape. I've never had to turn it off, cause none of my clients are that dumb. But Outhouse *did* originate the idea, so far as I'm aware.
The answer is that there is no answer.
The answer is there IS an answer. Just not a complete or fully satisfying one.
The answer is multi-faceted:
rules that explicitly and unambiguously call out what is and isn't acceptable.
education systems to help users understand the situation and learn how to deal with it appropriately.
information that explains (and legally limits your liability for) the limits of what you can and can't do given all this technnology, so subscribers understand what you're doing and what you can't do anything about but (1) and (2) above.
a cattle prod for when all of the above fails.
patience of a saint, reaction times of a ranger.
You forgot to capitalize that. :-)
Automatically verifying PGP sigs as a whitelisting technique is merely one approach that springs to mind. There are many more.
Sorry, doesn't really solve the problem. I posted a url to a note I wrote on this to barry a few minutes ago.
By which I meant, "sigs of people in your address book." No, this doesn't solve the "stupid user" problem... but you don't *solve* that with technology.
You solve it with a LART.
Yeah, but the Outhouse and OE teams aren't ever going there, and they're your problem.
Hint: this wasn't a windows box, and it wasn't a microsoft product. IT AIN'T MICROSOFT. Lots of clients do this now.
Stipulated, but they're 80-90% of the market. I think even skewing for "non-Windoze users send more mail, you would still be about 70%, intuitively.
At some point, if you're going to *have* a mailbox, you *have* to take responsibility for it.
Yes, but if you're going to distribute email, that doesn't remove your obligation to do what you can to protect the user from abuses in that distribution. BOTH sites and obligations and responsibilities.
Chasing spammers is one thing.
Chasing people who directly harvest your listmanagement machine in person seems quite another.
*That* you can't do on a case by case basis? Are you getting harvested every 5 minutes?
Do you have documentary evidence, Chuq, that web harversters are the *only* way that *a majority* of the spam-complainers addresses could have gotten on those lists? Have you created test-accounts? Not 1 or 2; a couple dozen, in different places?
The person who did this has come clean to me. I know exactly what he did. It's about the only reason I've let him live. He hasn't always been, well, sending me christmas cards, but he's been fully cooperative.
No, I mean in other cases. You're using webharvesting, it seems, as your major motivation here; it doesn't seem to me -- please don't take this wrong -- that there's evidence that it's really a big enough problem to solve (for people who don't send 40M pieces of email an hour).
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
On 7/16/02 5:57 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
But without rules, you can't teach the recipient what's right (with a cattle prod, if necessary), and without rules, the lynch mob has no binding authority.
Where, by "rules", here, we mean "rules about what it acceptable mail"?
Well, we're talking past each other a little bit, but at the same time, not. Because I think there's still a responsibility on the list admin, because when someone signs up for a list, they're delegating some responsibility over who can access their mailbox to the owner of the list, and the agreement between the two are the rules set up about acceptable content. So you can't duck some responsibility here.
Oh, by the way, there's few ways guaranteed to PISS ME OFF more than someone who signs up for a mailing list, and then starts bouncing selected pieces of the mail because of filtering systems. Which usually happens because their admin installs stupid filters... (I don't care if you throw them away, but I hate showing up in the morning to 50 bounce messages because of some flakey content filter...)
Right now, for instance, one of the lists at apple is having a discussion about coding problems. And the user starting it served up a code fragment that included:
int xxx = 0
[...]You can imagine the chaos that ensues among the STUPID IS FILTER IDIOTS who do overly simplistic filtering and assume it actually does something useful.
But I'm not bitter.
(and I'll be curious to see just how many bounces that I or barry see from THAT simple notation.....)
That sentence seems to assume that the majority of the people *falling in* the tarpits are people doing it by accident. I don' think that and I don't think *you* think that.
Yes, I do. Since I (for the most part, most of the time) have the felons locked out of the system pretty well, most of the people who cause problems on my systems aren't trying to f--k with the system, they're people who are oblivious, confused, or misguided. Even the spammer over the weekend meant no harm, which doesn't mean harm wasn't caused. It was a classiv case of "my cause is so important it justifies doing this" -- which, he found out the hard way, a few hundred people disagreed with him over.
By which I meant, "sigs of people in your address book." No, this doesn't solve the "stupid user" problem... but you don't *solve* that with technology.
You solve it with a LART.
Sometimes, the best solution is a public flogging, to teach everyone else to be more careful next time. But if you overdo it, people tune you out, too.
Stipulated, but they're 80-90% of the market. I think even skewing for "non-Windoze users send more mail, you would still be about 70%, intuitively.
We're working on that (a quiet voice whispers: "but a f---ing mac already! It has unix inside for all you geeks, too!")
Chasing people who directly harvest your listmanagement machine in person seems quite another.
*That* you can't do on a case by case basis? Are you getting harvested every 5 minutes?
You want to find out? Create a honeypot. Put some email addresses on it. Attach it to your home page. See how quickly you start getting e-mail to those addresses.
You'll usually find the answer is "days". Once in a while, it's "hours".
No, I mean in other cases. You're using webharvesting, it seems, as your major motivation here; it doesn't seem to me -- please don't take this wrong -- that there's evidence that it's really a big enough problem to solve (for people who don't send 40M pieces of email an hour).
I don't think you're looking close enough. Run a few honeypot tests and see how often people sneak a peek at YOUR system. On mine, it's a few days.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Yes, I am an agent of Satan, but my duties are largely ceremonial.
On Tue, Jul 16, 2002 at 08:11:43PM -0700, Chuq Von Rospach wrote:
On 7/16/02 5:57 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
But without rules, you can't teach the recipient what's right (with a cattle prod, if necessary), and without rules, the lynch mob has no binding authority.
Where, by "rules", here, we mean "rules about what is acceptable mail"?
Well, we're talking past each other a little bit, but at the same time, not.
I'm so glad you've cleared that up, Chuq. ;-)
Because I think there's still a responsibility on the list admin, because when someone signs up for a list, they're delegating some responsibility over who can access their mailbox to the owner of the list, and the agreement between the two are the rules set up about acceptable content. So you can't duck some responsibility here.
You can document your policies, and the person who wants to sign up can decide whether they can deal.
Oh, by the way, there's few ways guaranteed to PISS ME OFF more than someone who signs up for a mailing list, and then starts bouncing selected pieces of the mail because of filtering systems. Which usually happens because their admin installs stupid filters... (I don't care if you throw them away, but I hate showing up in the morning to 50 bounce messages because of some flakey content filter...)
That's why I never *bounce*. I either drop, or file.
Right now, for instance, one of the lists at apple is having a discussion about coding problems. And the user starting it served up a code fragment that included:
int xxx = 0 [...]You can imagine the chaos that ensues among the STUPID IS FILTER IDIOTS who do overly simplistic filtering and assume it actually does something useful.
:-)
But I'm not bitter.
Naw. Not at all.
(and I'll be curious to see just how many bounces that I or barry see from THAT simple notation.....)
Yeah, RISKS gets this all the time.
That sentence seems to assume that the majority of the people *falling in* the tarpits are people doing it by accident. I don't think that and I don't think *you* think that.
Yes, I do. Since I (for the most part, most of the time) have the felons locked out of the system pretty well, most of the people who cause problems on my systems aren't trying to f--k with the system, they're people who are oblivious, confused, or misguided. Even the spammer over the weekend meant no harm, which doesn't mean harm wasn't caused. It was a classiv case of "my cause is so important it justifies doing this" -- which, he found out the hard way, a few hundred people disagreed with him over.
Yeah. I keep forgetting that not everyone has spent 17 years on Usenet.
But that brings us almost immediately around to "why use email to do a Usenet's job"... which *LOTS* of mailing lists are doing, frankly.
In these days where the majority of newsreaders *do* understand multiple servers, that may no longer be warranted.
By which I meant, "sigs of people in your address book." No, this doesn't solve the "stupid user" problem... but you don't *solve* that with technology.
You solve it with a LART.
Sometimes, the best solution is a public flogging, to teach everyone else to be more careful next time. But if you overdo it, people tune you out, too.
You've jumped ship before. So have I.
They'll learn, eventually.
Stipulated, but they're 80-90% of the market. I think even skewing for "non-Windoze users send more mail, you would still be about 70%, intuitively.
We're working on that (a quiet voice whispers: "but a f---ing mac already! It has unix inside for all you geeks, too!")
<roar>
Chasing people who directly harvest your listmanagement machine in person seems quite another.
*That* you can't do on a case by case basis? Are you getting harvested every 5 minutes?
You want to find out? Create a honeypot. Put some email addresses on it. Attach it to your home page. See how quickly you start getting e-mail to those addresses.
You'll usually find the answer is "days". Once in a while, it's "hours".
My sister runs a page that's always in the top 3 on Google in her keyword, on a user-named account on Mind-link. Been there over 6 years now. She's had a pseudo-bogus address in her POP3 domain buried in a mailto: on there for over a year.
*One* piece of spam.
She's not exactly a low profile target.
You, OTOH, are. How well "hidden" were your honeypot machines? "plaidworks.com" is likely not a low-profile domain, neither.
You put your honeypots in *Jellystone*, you get more bears...
No, I mean in other cases. You're using webharvesting, it seems, as your major motivation here; it doesn't seem to me -- please don't take this wrong -- that there's evidence that it's really a big enough problem to solve (for people who don't send 40M pieces of email an hour).
I don't think you're looking close enough. Run a few honeypot tests and see how often people sneak a peek at YOUR system. On mine, it's a few days.
Yaeh, but see above.
Barry? You've been cowering in the corner there, letting us imitate Spenser and Hawk working up to it; comments? :-)
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
On 7/16/02 9:49 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
You can document your policies, and the person who wants to sign up can decide whether they can deal.
I don't think that's always good enough. You have to do what you can to back the policies up. Unless, of course, your policy is "you're screwed if you post to my list, and good luck stopping the spammers". Which is, effectively, what "make the owner of the mailbox handle it" does as a policy. Although I doubt you'd phrase it quite that way...
But I'm not bitter.
Naw. Not at all.
What has me pissed off is that I thought we did a pretty good job of fixing the weaknesses of Mailman in 2.1, and figured maybe we'd have some time to sit back and think through some really nice conceptual breakthrough type stuff. And now, we're slogging in the trenches again looking for ways to keep the bullets out of the latrine long enough to get anything accomplished....
Heh. Wanna guarantee messages get bounced all over the place? Just use the "V" word in an email. You know which one I mean. You'll set off alarms all over the universe. It's more fun than running through a parking lot seeing which cars have movement detectors on the alarms. Not that, um, I do that, you know.
Yeah. I keep forgetting that not everyone has spent 17 years on Usenet.
Newbie.
But that brings us almost immediately around to "why use email to do a Usenet's job"... which *LOTS* of mailing lists are doing, frankly.
Because usenet is so broke none of us even think of fixing it any more?
I love to say "if all you have his a hammer, everything is a nail". In this case, email is our hammer, and mail lists aren't always appropriate for hammering, but have you seen what those idiots did to our screwdriver? I ain't picking that up, not without tongs and a blowtorch.
Sometimes, the best solution is a public flogging, to teach everyone else to be more careful next time. But if you overdo it, people tune you out, too.
You've jumped ship before. So have I.
Hell, I turned jumping ship into an art form. In my heyday, usenet people set their clocks by it. Well, maybe their calendars.
I finally grew up, too, and learned to both manage my stress levels and accept my responsibilities.
They'll learn, eventually.
Not that I've noticed.
We're working on that (a quiet voice whispers: "but a f---ing mac already! It has unix inside for all you geeks, too!")
<roar>
Heh. A unix box with a pretty damn good gui, in a lap top so you can carry it anywhere, for about a grand. Effing wow.
Oh, never mind..... (giggle)
My sister runs a page that's always in the top 3 on Google in her keyword, on a user-named account on Mind-link. Been there over 6 years now. She's had a pseudo-bogus address in her POP3 domain buried in a mailto: on there for over a year.
*One* piece of spam.
I am amazed.
She's not exactly a low profile target.
You, OTOH, are. How well "hidden" were your honeypot machines? "plaidworks.com" is likely not a low-profile domain, neither.
You flatter me. I think.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after
On Jul 16, 2002 at 22:44, Chuq Von Rospach wrote:
On 7/16/02 9:49 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
the policies up. Unless, of course, your policy is "you're screwed if you post to my list, and good luck stopping the spammers". Which is, effectively, what "make the owner of the mailbox handle it" does as a policy. Although I doubt you'd phrase it quite that way...
I wouldn't, but that would be my policy, yes. OTOH, no one pays me to run mailing lists.
Again, it's the same thing: have the mechanism (I'm not even sure *which* mechanism(s) you're talking about now), let $foo decide the policy, where $foo iterates over the list of users.
Of course, that causes one person's miscalculation to be another person's (times n) headache. Networks are like that.
But I'm not bitter. Naw. Not at all.
I see no "bitter" here.
Heh. Wanna guarantee messages get bounced all over the place? Just use the "V" word in an email. You know which one I mean. You'll set off alarms all
"virus"? Something else? VD? What?
over the universe. It's more fun than running through a parking lot seeing
Oooh, cool!
I love to say "if all you have his a hammer, everything is a nail". In this case, email is our hammer, and mail lists aren't always appropriate for hammering, but have you seen what those idiots did to our screwdriver? I ain't picking that up, not without tongs and a blowtorch.
But now they want to borrow the hammer, too.
(Insert Picard's speech about drawing the line here.)
My sister runs a page that's always in the top 3 on Google in her *One* piece of spam. I am amazed.
So am I. I mean, *one*?
-- Satya. <URL:http://satya.virtualave.net/> Could you continue your petty bickering ? I find it most intriguing.
On 7/16/02 11:56 PM, "Satya" <satyap@satya.virtualave.net> wrote:
Heh. Wanna guarantee messages get bounced all over the place? Just use the "V" word in an email. You know which one I mean. You'll set off alarms all
"virus"? Something else? VD? What?
Rhymes with "niagara" as in the falls.
My sister runs a page that's always in the top 3 on Google in her *One* piece of spam. I am amazed.
So am I. I mean, *one*?
Must have been a mistake. Usually, once you get one, you need to pull out the waders.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
He doesn't have ulcers, but he's a carrier.
On Jul 17, 2002 at 00:02, Chuq Von Rospach wrote:
On 7/16/02 11:56 PM, "Satya" <satyap@satya.virtualave.net> wrote:
"virus"? Something else? VD? What?
Rhymes with "niagara" as in the falls.
Ah, Viagra. Oops.
Yes, I'm baiting.
-- Satya. <URL:http://satya.virtualave.net/> But I thought you did the backups!
On Tue, Jul 16, 2002 at 11:56:16PM -0700, Satya wrote:
On Jul 16, 2002 at 22:44, Chuq Von Rospach wrote:
On 7/16/02 9:49 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
the policies up. Unless, of course, your policy is "you're screwed if you post to my list, and good luck stopping the spammers". Which is, effectively, what "make the owner of the mailbox handle it" does as a policy. Although I doubt you'd phrase it quite that way...
Note that the attribs are slightly hosed there; that's Chuq.
I wouldn't, but that would be my policy, yes. OTOH, no one pays me to run mailing lists.
Again, it's the same thing: have the mechanism (I'm not even sure *which* mechanism(s) you're talking about now), let $foo decide the policy, where $foo iterates over the list of users.
The mechanism is "permit the hooking in of a method for preventing spam from reaching the list", I think.
Of course, that causes one person's miscalculation to be another person's (times n) headache. Networks are like that.
Yep.
Heh. Wanna guarantee messages get bounced all over the place? Just use the "V" word in an email. You know which one I mean. You'll set off alarms all
"virus"? Something else? VD? What?
Vger.
(Insert Picard's speech about drawing the line here.)
That was *precisely* what was running through my mind; only saw that movie 5 days ago.
My sister runs a page that's always in the top 3 on Google in her *One* piece of spam. I am amazed.
So am I. I mean, *one*?
One.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
"JRA" == Jay R Ashworth <jra@baylink.com> writes:
JRA> The mechanism is "permit the hooking in of a method for
JRA> preventing spam from reaching the list", I think.Already exists, of course. SpamDetect is a lame-ass placeholder, but of course, the system is already architected for folks to add their own handler modules to do better.
-Barry
On Tue, Jul 16, 2002 at 10:44:41PM -0700, Chuq Von Rospach wrote:
On 7/16/02 9:49 PM, "Jay R. Ashworth" <jra@baylink.com> wrote:
You can document your policies, and the person who wants to sign up can decide whether they can deal.
I don't think that's always good enough. You have to do what you can to back the policies up. Unless, of course, your policy is "you're screwed if you post to my list, and good luck stopping the spammers". Which is, effectively, what "make the owner of the mailbox handle it" does as a policy. Although I doubt you'd phrase it quite that way...
I was on 14 mailing list for 6 years; I saw no appreciable amount of spam *at all*...
Heh. Wanna guarantee messages get bounced all over the place? Just use the "V" word in an email. You know which one I mean. You'll set off alarms all over the universe. It's more fun than running through a parking lot seeing which cars have movement detectors on the alarms. Not that, um, I do that, you know.
<grin>
Yeah. I keep forgetting that not everyone has spent 17 years on Usenet.
Newbie.
I can still remember the month that I ceased to be able to read *the entire feed*. I'm not *that* much of a newbie; though, admittedly, B2.9 is about the oldest news system I had to deal with.
But that brings us almost immediately around to "why use email to do a Usenet's job"... which *LOTS* of mailing lists are doing, frankly.
Because usenet is so broke none of us even think of fixing it any more?
People tell me that all the time. I use slrn... and I don't see it, much.
I love to say "if all you have his a hammer, everything is a nail". In this case, email is our hammer, and mail lists aren't always appropriate for hammering, but have you seen what those idiots did to our screwdriver? I ain't picking that up, not without tongs and a blowtorch.
Perhaps I'm lucky, perhaps I'm blind...
You've jumped ship before. So have I.
Hell, I turned jumping ship into an art form.
I know; I saw the website. :-)
In my heyday, usenet peopleset their clocks by it. Well, maybe their calendars.
:-)
I finally grew up, too, and learned to both manage my stress levels and accept my responsibilities.
I construed jumping ship *as* doing those things.
They'll learn, eventually.
Not that I've noticed.
Well, stupidity is supposed to be expensive. And painful.
We're working on that (a quiet voice whispers: "but a f---ing mac already! It has unix inside for all you geeks, too!")
<roar>
Heh. A unix box with a pretty damn good gui, in a lap top so you can carry it anywhere, for about a grand. Effing wow.
:-)
My sister runs a page that's always in the top 3 on Google in her keyword, on a user-named account on Mind-link. Been there over 6 years now. She's had a pseudo-bogus address in her POP3 domain buried in a mailto: on there for over a year.
*One* piece of spam.
I am amazed.
I have just +hacked the mailto that is in *my* weblog as the comment address. We'll see what happens. I'm not all that important, but...
She's not exactly a low profile target.
You, OTOH, are. How well "hidden" were your honeypot machines? "plaidworks.com" is likely not a low-profile domain, neither.
You flatter me. I think.
Maybe.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
On 7/17/02 8:46 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:
Perhaps I'm lucky, perhaps I'm blind...
Your new nickname is Stevie Wonder!
I finally grew up, too, and learned to both manage my stress levels and accept my responsibilities.
I construed jumping ship *as* doing those things.
Well, yeah. How about "manage my stress and accept my responsibilites is a more constructive manner...."
Well, stupidity is supposed to be expensive. And painful.
(opens mouth. Declines straight line. Closes mouth)
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms).
On Wed, Jul 17, 2002 at 03:21:15AM -0400, Barry A. Warsaw wrote:
"JRA" == Jay R Ashworth <jra@baylink.com> writes: JRA> Barry? You've been cowering in the corner there, letting us JRA> imitate Spenser and Hawk working up to it; comments? :-)
What's my budget and where's my staff? :)
Your staff is me and Chuqui; *what* kind of beer did you say that was on offer? ;-)
Cheers, -- jr 'am I allowed to use the diminutive?' a
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> Oh, by the way, there's few ways guaranteed to PISS ME OFF
CVR> more than someone who signs up for a mailing list, and then
CVR> starts bouncing selected pieces of the mail because of
CVR> filtering systems. Which usually happens because their admin
CVR> installs stupid filters... (I don't care if you throw them
CVR> away, but I hate showing up in the morning to 50 bounce
CVR> messages because of some flakey content filter...)Bouncing them to the actual errors address is one thing, but bouncing them to the author of the email is the worst offense. OTOH, I have no problem with Mailman being aggressive in disabling such offenders.
CVR> Right now, for instance, one of the lists at apple is having
CVR> a discussion about coding problems. And the user starting it
CVR> served up a code fragment that included:
| int xxx = 0
| [...]
CVR> You can imagine the chaos that ensues among the STUPID IS
CVR> FILTER IDIOTS who do overly simplistic filtering and assume
CVR> it actually does something useful.
CVR> But I'm not bitter.
CVR> (and I'll be curious to see just how many bounces that I or
CVR> barry see from THAT simple notation.....)I'm actually quite surprised that we don't see more of those, especially on the python-checkins list, given Guido's prediliction for comment markers (uppercase tres-equis). OTOH, I seem to remember our Windows dude got a lot of those shunted off into his spam folder before he taught it to ignore those.
>> Stipulated, but they're 80-90% of the market. I think even
>> skewing for "non-Windoze users send more mail, you would still
>> be about 70%, intuitively.
CVR> We're working on that (a quiet voice whispers: "but a f---ing
CVR> mac already! It has unix inside for all you geeks, too!")OT: Chuq will be so proud of me. I'm Windows free (tm) and my two Linux boxes sit right next to my two G4 towers. OSX rules and if Cubase ever /finally/ releases SX for MacOSX I won't go back (yes, I know Apple just bought Emagic -- two weeks after I flipped a coin and took the plunge off the other side. ;).
-Barry
On 7/16/02 11:49 PM, "Barry A. Warsaw" <barry@zope.com> wrote:
CVR> starts bouncing selected pieces of the mail because of CVR> filtering systems. Which usually happens because their admin CVR> installs stupid filters...
Bouncing them to the actual errors address is one thing, but bouncing them to the author of the email is the worst offense. OTOH, I have no problem with Mailman being aggressive in disabling such offenders.
For the most part, they seem to end up going to the -admin address. And when the admin gets tired of throwing them away, we tell them to send a message to the subscribers saying "get your filters fixed or we'll remove you". Mostly, they end up getting unsubscribed, since the filters are usually under control of IS people who are too busy saving the universe to realize they're impacting company business with false positives...
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after
Jay R. Ashworth wrote:
So what are you going to do?
Outlaw Outlook?
:-)
Don't laugh--one of the filters we provide our users is "it says it came from Outlook" and "it has an attachment". Users can choose that if both of those conditions are met, the message is bounced back to the sender with an explanation that they don't accept Outlook mail that contains attachments!
John Baxter wrote:
Plus, I fear the "new breed" spammers (the ones who actually think their advertising is useful and welcome and only sent to opt-in lists, although they buy the lists from guys who [figuratively] sell them from under a trenchcoat at the entrance to a dark alley) will cause legislation to be passed forbidding filtering at the mail server level. It nearly happened last time around.
I don't understand why people can't look at history. Get the government involved in spam legislation, and eventually businesses will convince the government to require us to receive spam.
Jerry
jerry@sandiego.edu http://www.sandiego.edu/~jerry/ Serra 188B/x8773
The more restrictions there are, the poorer the people become. The greater the government's power, the more chaotic the nation would become. The more the ruler imposes laws and prohibitions on his people, the more frequently evil deeds would occur. --The Silence of the Wise: The Sayings of Lao Zi
On Tuesday, July 16, 2002, at 01:58 PM, Chuq Von Rospach wrote:
One thing we're definitely doing is moving to a cloaked archive. Since we already distribute all archives out of HTTP, not FTP, we're working on a CGI that'll strip all e-mail information out of messages on the fly (among other things, like header cleanup and some trivial formatting fixes). The idea is simple -- we've finally hit the point where you can't put an e-mail address up on a public site under any cirucmstance safely, so we're having to move to a system where we simply don't do that.
I think the Mailman stuff needs to think about this, also. It impacts the archiving setup and other issues, but the harvesters have hit the point where we simply can't risk disclosing that info. It creates other problems -- you can't see a posting in the archive and send email to that person with more questions (or answers), but that seems trivial compared to the problems the spammers are causing.
I've had requests from customers for this as well. I'm fairly impartial as to whether it's done when the archive is displayed or when it's generated, but they a) want public archives, and b) don't want harvest-able addreses in them. Something like [address removed] would be fine, as long as the Real Name portion was (optionally?) preserved.
Would probably also be a good idea for some private lists, to prevent more advanced harvesters (ie subscribe to list, grab all the addresses from the archives, unsubscribe - that can't be too hard to automate).
I'm unsure about whether the obscurer should scan the body and nuke addresses there too - could be a PITA for technical lists (especially those discussing email issues!), but could be valuable for lists which REALLY want to protect subscribers.
A secondary issue here is the problem of disclosing admins and admin addresses. I know we've hashed that through once, but we've come to the (somewhat reluctant) decision to whitelist all public, non-personal email addresses. We're going to be implementing TMDA to do this, and will be switching all admin to generic addresses that filter through TMDA, as well as things like postmaster@ and the like. While I hate making users jump through hoops to get through to a real person (for those that don't know, TMDA is an overt whitelist. If you're not on the whitelist, you get mail back telling you to take some action, and until you do, the mail isn't delivered), but the abuse by the spammers on admin addresses is now so bad I'm declaring defeat and going to the whitelist.
As mentioned by Barry, SpamAssassin good.
So what he did was open up his address book and send his message to everyone in it. And he's running one of these new e-mail clients that happily caches addresses it sees in case you want them again. So all of the addresses of people posting to the mailing lists he subscribed to were in his address book cache, so when he grabbed his address book, he grabbed all of those addresses, too.
The perils of Ease of Use. I have a crapload of people in my OS X Address Book that Mail.app's been happily storing away for a rainy day. Luckily for them, I'm not likely to be excited enough about anything to add them all to an email. :)
Bryan
-- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bryanf Samurai Consulting Inc.
"BF" == Bryan Fullerton <bryanf@samurai.com> writes:
BF> The perils of Ease of Use. I have a crapload of people in my
BF> OS X Address Book that Mail.app's been happily storing away
BF> for a rainy day. Luckily for them, I'm not likely to be
BF> excited enough about anything to add them all to an email. :)Just wait until I finish my solo album. Of course, you can all send me $15 now to hold your slot and get removed from my address book. :)
-Barry
On Tuesday 16 July 2002 13:58, Chuq Von Rospach wrote:
It's a thoughtful post, and includes many of the things I've been contemplating myself, but I just had one thing to add about the list management software becoming the arbiter of replies.
Are we hitting a point where mail list servers have to act as blind front ends for all of the subscribers, where replies are processed by those servers, and the server then takes on the job of acting as a troll-exterminator and spam blocker? And what does that really mean for things like Mailman?
What would keep a spammer from using the reply mechanism to shuttle replies back as if they were individual replies?
I think that something like this would also need spam assassin and maybe even heuristics to help out.
On 7/16/02 5:11 PM, "Phil Barnett" <philb@philb.us> wrote:
What would keep a spammer from using the reply mechanism to shuttle replies back as if they were individual replies?
It wouldn't. But as soon as that happens, that either gets blacklisted, or the reply address invalidated and the subscriber issued a replacement. The advantage being that if one subscriber gets harvested, ALL of them likely are, so the server can act as a protective chokepoint here.
It's not so much we can stop it cold, but we can limit the exposure and protect users from the results of being harvested. It gives us better control and centralized power to protect users who struggle at protecting themselves.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Stress is when you wake up screaming and you realize you haven't fallen asleep yet.
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> It's not so much we can stop it cold, but we can limit the
CVR> exposure and protect users from the results of being
CVR> harvested. It gives us better control and centralized power
CVR> to protect users who struggle at protecting themselves.And a centralized point of attack, either technologically or legally.
-Barry
Chuq Von Rospach <chuqui@plaidworks.com> writes:
We're going to be implementing TMDA to do this, and will be switching all admin to generic addresses that filter through TMDA, as well as things like postmaster@ and the like.
Glad to hear this. AFAIK, TMDA isn't currently in use at any huge sites, so this should be a good test.
I'm going to look and see if I can interface TMDA to the subscriber databases so that subscribers are by definition whitelisted
The docs cover the details, but yes TMDA can do this. For example, the filter for the tmda-workers mailing list includes the following lines:
# allow subscribers through from-mailman -attr=members ~mailman/lists/tmda-workers ok
# ditto for digest subscribers from-mailman -attr=digest_members ~mailman/lists/tmda-workers ok
-- (http://tmda.net/)
participants (15)
-
barry＠zope.com -
Bob Puff＠NLE -
Bryan Fullerton -
Chuq Von Rospach -
Chuq Von Rospach
-
David Champion -
J C Lawrence -
Jason R. Mastaler -
Jay R. Ashworth -
Jerry Stratton -
John W Baxter -
Marc MERLIN -
Peter C. Norton -
Phil Barnett -
Satya