[Mailman-Developers] FYI -- mailback validations no longer safe?

[Chuq Von Rospach]

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.