At 5:32 PM -0500 12/9/00, Vince Sabio wrote:

Short of S/MIME and similar measures that most of us would consider to be extreme (right now, anyway; probably won't be considered extreme measures for much longer), there is little that the owner of a large,

I've been mulling this over all day, and I have a couple of ideas on it. I'm sure they're not original, but they might open up concepts for MLM authors to consider.

my first premise: this has to be "solved" at the MLM level. The real answer is authenticated e-mail addresses, and that implies S/MIME and all of the logistical overhead and development that implies. In practice, for many places, that's simply not an option until SOMEONE figures out how to get AOL to support it, because without AOL, a significant chunk of the audience can't do it, making it worthless (and while individual list admins can tell AOL to take a flying leap, the typical one won't, and many of us can't. So any MLM that comes up with a solution that effectively locks out AOL is a MLM that dies in the marketplace...)

my second premise: that we put the onus of managing this first on the MLM software, second on the list admin, and third on the end user. The higher the bar you place between your user base and the list, the fewer will bother jumping over it. And the harder you make it for an admin to be admin, the more likely they are to turn the bloody stuff off, or choose a different MLM. We have to remember we're talking about 'solving' what we see might be an emerging problem, which means we aren't going to have admins beating down our doors screaming FIX THIS. Instead, we have to fix it and keep it from ever BEING that kind of problem, which means the barriers for entry and use have to be kept minimal. either that, or we wait until it does fall apart, and pray we can put it back together quickly. not my idea of fun.

I've come up with two ideas that seem promising.

First is not new. It's moving the validation from the point of subscription to the posting time (actually, do both). This involves assigning a user an access password, which is attached to the message they want posted. This can be strongly automated, which is good. It only solves the forbge subscriber address part, which means it's not a complete solution, but at least it deals with the most pernicious aspects of all of this, a harvester posting via forged addresses of legitimate subscribers. Passwords can be pulled off a web site, similar to what users do now when they forget a password as most sites with registration, and have it e-mailed to the subscribed address. It's tehn atached via the subject line, first line of the body, x-header, I don't care. the MLM has to be paranoid about stripping these passwords without overswtripping legitimate content, to protect it. At that point, we can at least get back to knowing the user posting the message has access to the e-mail address's mailbox, which is about as secure as we can get with e-mail. They aren't just sucking addresses at random and re-using them. Passowrds, if you want, can time out, and if you really want, the admin can set their length, from one-time to permanent, depending on their paranoia.

Second idea puts the onus on the list admin. There is one other identifying piece of info we know about the poster that can't be forged. it is the IP address of the machine that relays the mail to your MLM machine. All of the OTHER received lines can be forged, but the one your server adds to tell you who it got the mail from -- the direct connection -- can't be (or you have bigger problems). In this scheme, then, messages from a user are held for approval, and the list admin has to teach the MLM which IP addresses to acccept mail from with that "From" address. Now, a given "From" address may relay in from more than one address, but the list of those addresses is finite -- so we can build an authentication list for EACH user fairly easily, over time. The admin will be pretty busy early on, but the main work is done by the MLM itself, and the end-user in almost all cases doesn't have ot worry about it. And we can base this on a human teaching a machine "right" and "wrong", using a piece of known-valid data. There are opportunities for automation here, of course, such as automatically validating AOL users where the SMTP relay is an AOL machine, that can help the admin minimize their pain, but you run some risk of opening up some holes.

It seems like both approaches will work, both can be done TODAY, without waiting for significant technological advances, client enhancements, maturation of technologies or building of new infrastructures, and they layer ontop of what we already are doing in reasonably non-invasive ways. I think the SMTP-relay authorization (to some degree, a list-specific variation of the SMTP-after-POP email setup...) has some interesting possibilities, and I wonder if there are other pieces of data that we "know" about a user once we get the email that we can use to validate without worrying about their corruption or forging. And yes, I know about TCP spoofing, but frankly, I think if spammers get that sophisticated intheir attacks, it's unlikely anything reasonable will stop them. but I'm willing to try, and I think we solve the cases we can solve, and continue to move forward from there...

busy discussion list can do to protect his list from an attack such as this. Sure, you could moderate the list, but many of my lists see 50 to 100 posts/day, and the max I've ever had posted to a single list in one day was more than 450. That's a lot of moderation.

Moderation is a tool, but not a solution. I'd have to hire staff to do nothing but moderate my big machine. That's the wrong way to look at this. I'd rather hire staff to find ways to FIX it so we don't have to put human filters in the way. the SMTP-relay IP address is nice, because while there's some pain while you're teaching your server, and it adds SOME continuing overhead to the admin's load due to new users, moving users and network changes within other people's networks -- the primary load is managed by the server, not the admin. And it doesn't impact the end-user or require new user skills or client technologies (or training users to apply passwords ot messages, or... ) -- it's purely server based.

Like Chuq, I shudder at the thought of someone forging subscriber addresses to spam mailing lists.

it's a scary thought. brr.

-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)

We're visiting the relatives. Cover us.

At 8:36 PM -0500 12/9/00, John A. Martin wrote:

CVR> received lines can be forged, but the one your server adds to
CVR> tell you who it got the mail from -- the direct connection --
CVR> can't be (or you have bigger problems).

Would you unconditionally accept postings received at your list host from a backup MX?

I'd say it's up to the list admin. that's the advantage of allowing the admin to approve given IP addresses as approved addresses for that email. it can be dealt with on a case by case basis. And if you run into a case where an approved IP is abused, you remvoe it from the approval list and manually moderate those messages.

-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)

We're visiting the relatives. Cover us.