[Mailman-Users] Re: subscription confirmations (was Re: [Mailman-Users] [ANNOUNCE] Mailman 2.1 alpha 2)
Chuq Von Rospach
chuqui at plaidworks.com
Sun Jul 15 05:49:34 CEST 2001
On 7/14/01 4:32 PM, "Gerald Oskoboiny" <gerald at impressive.net> wrote:
> Regarding "I think they're wrong", I respect your opinion, but
> the HTTP spec is the result of a decade of work on and experience
> with HTTP by full-time web protocol geeks...
But web geeks are not necessarily user-interface or user-experience geeks.
You can perfectly correctly build a nice system that's technically correct,
but not right for the users.
> What if I have a smart system on my desktop PC that is configured
> to prefetch any URLs it sees in my incoming email,
Given the number of viruses, spam with URLs and other garbage out there, I'd
say you're foolish (bordering on stupid), but that's beside the point. It is
an interesting issue, one I can't toss out easily; but I'm not convinced,
either. I think it's something that needs to be hashed over, perhaps
prototyped both ways so we can see the best way to tweak it.
Barry, what do you think about this instance? As the net moves more towards
wireless, PDA, mobile-phone, stuff, could we be setting ourselves up for a
later problem by ignoring this pre-cache issue Gerald's raised?
Gerald, does W3 have sample pages for "right" and "wrong" that can be looked
at, or are we going to have to develop some? The more I think about this,
the more I think it's case where we ought to see if we can develop a
prototype that follows the standards that we like, rather than toss it out
at first glance. But if we can't come up with a system that we agree is
'easy enough', then we should go to what we're currently thinking.
> That would allow anyone in the world to sign me up for any
> mailman-backed mailing list, whether or not I even see the email
> confirmation requests. And that would be Mailman's fault, for
> misusing HTTP GETs.
In disagree with this -- since as you say, any number of places already
misuse GET, that usage is fairly common. A user who sets themselves up for
it should know (or be warned by their mail client) that it has the
possibility to trigger events. I'd say it's more a client issue than a
And, thinking about it, since GET *can* do this, it's probably wrong for W3
to push for it not to be used that way, because if things like your
pre-caching system come into common use, the dark side of the net will take
advantage of it, the way early virus writers took advantage of mail clients
with auto-exec of .EXE's being on by default. So aren't you setting yourself
up for problems by having a technology that can, even if you deprecate it,
because it sets a user expectation that's going to be broken by those
wanting to take advantage of it? I've got a bad feeling about this -- your
example seems to set yourself up for abuse by those looking for ways ot
abuse you, and that's a bigger issue than Mailman using it -- because if all
of the 'white side' programs cooperate, it just encourages creation of
things (like the pre-caching) that the dark side will take adavantage of.
As long as GET is capable of being used this way, I'd be very careful about
creating stuff that depends on "we don't want it used this way, so it won't
be" -- it seems to open up avenues for attack.
Which is not a reason for mailman to ignore the standard -- but a bigger
issue about whether this standard creates a perception that could come back
and bite people. If people start creating services (like that pre-cache)
that get tripped up by this, even if the white hats follow your advice,
you're still at risk from the black hats. Isn't it better to acknowledge the
capability and not create services that depend on "well behaved" systems?
>Of course, I only do
> that because I don't have that prefetching thing set up... yet.)
At this point, I'd never turn on pre-fectching, since it's safety depends
entirely no voluntary cooperation, and you aren't in a position to police
until after the fact. That's a Bad Thing in a big way.
> btw, part of the reason I care about this is that I work for W3C
> and am currently evaluating mailman for use on lists.w3.org (to
> replace smartlist) and we're pretty fussy about complying with
> our own specs, for obvious reasons.
As you should be.
> But I'd be making this
> argument whether or not that were the case, since it's clearly
> the Right Thing to do imho...
And the more I think about it, the more it's an interesting point -- but on
more than one level. Has W3c considered the implications of defining a
standard that depends on voluntary acceptance here? Because the service you
propose is unsafe unless you can guarantee everyone you talk to is
compliant, and we know how likely that's going to be. That, to me, is a much
bigger issue than whether or not Mailman complies, and in fact, I could make
an argument that the standard isnt' acceptable if it's going to be a basis
for services that can cause harm but requires voluntary acceptance on the
server side. By the time you figure out the server isn't complying, they've
burnt down the barn and run off with the horse. That's bad.
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui at plaidworks.com> = <me at chuqui.com> = <chuq at apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.
Someday, we'll look back on this, laugh
nervously and change the subject.
More information about the Mailman-Users