[Mailman-Developers] Re: subscription confirmations

Chuq Von Rospach chuqui@plaidworks.com
Tue, 17 Jul 2001 17:27:52 -0700


On 7/16/01 11:35 PM, "Gerald Oskoboiny" <gerald@impressive.net> wrote:

> I think the HTTP spec is fairly clear about most of this:

Gerald - I hope this is taken in a team-building way, since it's what I
intend it to be.=20

> 9.1.1 Safe Methods
>=20
>   Implementors should be aware that the software represents the user in
[... Etc ...]

This section is written like most good Unix man pages. It speaks volumes to
someone who already knows the answer, and is pretty much opaque to someone
who doesn't.=20

If I were coming to it cold, researching the protocol, I'd leave it again
without any real idea that there are significant problems that I ought to b=
e
aware of. And even if I have some idea there are problems to worry about, I
wouldn't have a clue what to worry about. Even after our discussion already=
,
I find this very illuminating. Now, I've been doing internet stuff for 20
years, and HTTP/Web stuff since 1995, and even with my background, I find
this doesn't really say anything to me about any of the issues I should be
warned about here. It's very nice, but it speaks to the choir who already
knows what it speaks of. To an outsider, it not only doesn't illuminate, it
doesn't do a thing to tell me why the choir is a good thing to join, either=
.
So if I'm doing my research, I read it through, and go off and do whatever =
I
was planning on doing in the first place, without ever really knowing that =
I
just tripped over an iceberg.

> but once all that's been said, it's really up to the implementations
> to do the right thing.

And the implementors are given basically no guidance on how, or even why.
And very little what. Which makes it really hard for the implementor to get
it right, and even harder for them to care -- what with deadlines and bosse=
s
and other things actively in their faces, this stuff just isn't going to ge=
t
a lot of visibility with the people you need to be evangelizing.

> If it happens once in a while with an obscure site here and there,
> that's much less of a problem than if some popular software like
> Mailman is doing the wrong thing

I'm sorry, but I consider this ducking the issue again. You're completely
ignoring the white hat/black hat issue,and hiding behind "obscure" and "not
a significant issue" and other rationalizations, while still trying to prov=
e
that Mailman is none of those, and therefore ought to consider this a crisi=
s
issue.=20

But since I've tried three times now to get you to deal with this
double-standard and gotten nowhere, I'll drop it. No sense beating a dead
horse. You clearly don=B9t' want to deal with the issue, so I'll stop pushing=
.
But I'm disappointed, to be honest about it.

> I don't expect all the incorrect implementations in the world to
> suddenly get fixed overnight, but I'm trying to get the ones I
> know about fixed.

Which ignores the larger issue of the standard encouraging implementations
of tools that run into these problems, without dealing with the problems
themselves, and leaving it up to the implementor to figure out how to "do
the right thing" to avoid whatever those bogeymen are, which can't,
basically, be known ahead of time. This all comes across to me as the
prerson who decided that Microsoft's e-mail client would -- by default --
execute included .EXE files, because what's the worst that could happen?

> I agree this kind of thing needs to be done, but I think it can
> usually be done quite well by third parties,

Which is a great way to duck responsibility, not get it done, and be able t=
o
blame someone else when something bad happens because this stuff didn't
exist.

> A bad implementation of a spec can always cause security problems.

But the problem here is that gET itself is the security problem, as the
functionality currently exists, and you're trying to 'fix' the problem by
creating a standard that says "don't do that".

THAT doesn't work. Because even if it does work with all us whitehats, the
blackhats are simply going to look at it with even more glee, since it's
even less expected of the end user when those side effects click in.

But enough. You and I simply don't see eye to eye here, and clearly won't,
and I'll shut up now. You want to focus on the micro issue of Mailman, whil=
e
I see that as a non-issue compared to the macro issues you are ignoring. An=
d
it looks like impasse.



--=20
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> =3D <me@chuqui.com> =3D <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

I recommend the handyman's secret weapon: duct tape.