[Mailman-Users] query re "message has implicit destination" (devils advocate!)

[Brad Knowles]

At 2:07 AM +0200 2006-08-31, Bretton Vine wrote:

>  (locally) it's been referred to as a "be strict in what you send, relaxed in
>  what you receive" approach but not everyone adheres to (or is aware of) this
>  way of looking at things and it seems antiquated to some.

It's called the Postel Principle, and some of us are old enough to 
remember when the term was first coined.  While there are cases where 
it is not always appropriate to apply the Postel Principle, there are 
still plenty of us around that firmly believe that using "safe 
defaults" is a better way to go.

>  I *know* the developers develop according to their needs, and needs change
>  with time and input. And the openness of the GNU approach allows anyone to
>  modify at will (provided they have the skill), and heck no-one likes
>  documenting stuff but someone has to do it.

The methods of open source development pre-date Richard Stallman and 
his GNU followers.  Some of us remember those days.

>  But many people will choose a Mailman solution on the basis of cost and
>  relative availability of help and support. Plus Mailman has largely
>  dominated what was previously a majordomo or listserv orientated world.

I think that Mailman has become the leading open-source mailing list 
management system for the small to moderate size lists, but we still 
have some issues with larger lists that preclude us from taking the 
complete title away from programs such as Listserv.

That said, there are multiple choices in this field and I think 
that's a good thing, because Mailman will not be a perfect fit for 
everyone, and probably won't even be a good fit for a significant 
number.  There's always room for improvement, and our biggest problem 
is that we've identified many different areas where we already 
recognize the room/desire/need for improvement and yet we still have 
a limited amount of time available to fix those things.

>  Just because a 'default option' seems sensible and obvious to implement from
>  a developer perspective doesn't mean you can avoid having to explain it.

That may be true, but in this case the answer is pretty simple -- 
it's safer that way.  No further explanation is required, or likely 
to be provided.

>  No matter whether you're a core developer, patch developer, documentation
>  person, or verbal user, people are going to use your product. It's either
>  going to be good, or outright crap. And even when it's the best solution
>  available, and all the right decisions have been made in implementation
>  design, users may choose something else because it's *more shiny*.

That's perfectly fine by me.  We don't require that everyone use our 
software.  Indeed, I would say that we probably don't want everyone 
to try to use our software.  We're relatively happy with the user 
community we've got, and we know that there are a lot of ways that we 
think that this software needs improvement.

We don't need (or want) to be all things to everyone.

>  And sometimes users may become irate at your implementation of a solution on
>  their behalf and decide they can do it themselves, only to repeat all the
>  same mistakes you made and end up at the same end result -- feeling like
>  fools but too embarrassed to return and ask for your help.

That's fine, too.  If they want to go off by themselves and learn 
their lessons the hard way, then that at least gets them out of our 
hair.

If they choose to come back and share their experiences with us, I'm 
happy to listen to what they've learned to see if there is anything 
we can take from their experience, so that the entire community can 
benefit.

>  In a commercial environment this is quite costly to both parties so avoiding
>  that situation leads to more successful/stable product iterations (not to
>  mention $$$)

We're not a commercial environment, and we've actually had pretty bad 
experiences with people/companies that are in commercial environments 
taking our software and making unapproved modifications to it, or 
providing the software to their customers but *not* providing 
adequate support to those customers.

I just recently wrote a FAQ entry on this subject -- see FAQ 1.32.

>  Ok, granted, no-one's specifically 'selling' anything here. That doesn't
>  negate responsibility for the default options though.

No, we're not selling anything here, but we are still obligated to 
create safe defaults for the options within our software.  Failure to 
create safe defaults would be negligent behaviour, and potentially 
legally actionable.

>                                                        It's insufficient to
>  give people an "option" to change something. Some need to know why/how/what.

Balance the need to know against the issue of legal actionability. 
Trust me, the latter will win every time.  Especially when the answer 
is as simple as "because it's safer that way".

>  I have lots of experience with non-list savoy people, from list-owners to
>  list-users. Few of them are inclined to actually /look/ for an answer. It's
>  much easier to ask someone else. And in many cases a sheep-like mentality
>  occurs where people do things a certain way because "that's just the way
>  it's done" or "things _may_ go wrong if we do it differently".

As one of the principal people in the community who has gone through 
the FAQ entries and tried to clean them up and correct them as much 
as possible, I also have plenty of experience with people who are not 
list-savvy.  I know all too well that the default action for most 
people is to ask others, as opposed to actually going to look for 
answers in the FAQ or in the archives.

A little searching through the archives looking at my typical 
responses to most posts would clearly demonstrate that.

>  Think of a lowest-common-denominator list user. What would you recommend as
>  an OS interface to them? osx or windows or linux or even dos?

None of the above.  I would recommend a rock.  Well, a pebble, since 
a rock would be large enough that they could throw it at something or 
hit something with it, and cause a fair amount of damage.  At least a 
pebble would be small enough to be less likely to cause damage if 
abused.

>                                                              Now apply the
>  same basic principle to a web-based list-administrative interface.

For the lowest common denominator?  None.  Even the simplest possible 
web interface would be too complex for them.

>                                        Seriously, what's the worst that can
>  happen -- someone learning from mistakes, something we do naturally?

Entire sites being blown off the 'net, because they're not able to 
keep up with the e-mail flood?  Entire businesses going bankrupt 
because they weren't able to do their regular work because of the 
e-mail flood?

Remember that you're talking to the guy who was personally blamed for 
taking down all Internet e-mail across the entire world when AOL went 
dark for nineteen hours in August of 1997, and I know for a fact that 
a number of businesses went bankrupt because of that outage and the 
resulting aftermath, and I personally received more than a few death 
threats as a result.

So, you're asking me what the worst possible case would be?

>                                                  But at the same time you
>  have a market that wants a one-size-fits-all solution. Catch-22.

Yup.  We do the best we can, and that's all we can do.

>  A mailing lists key function is to act as a list. Not as a spam filter. Sure
>  it's a useful extra, perhaps even pretty-bells-and-whistles useful. But does
>  it actually contribute anything to the core function, or add any value that
>  can not be achieved from within the mail system itself?

A mailing list is not useful if it is used as an amplifier for spam, 
so that more spam goes out than real messages.

>  If not, why is the default set to "on"?

You're asking me whether or not we should have all the software 
defaults set to their safest mode, when Windows machines default to 
being insecure and have an average life expectancy of about five 
minutes if left unsecured on the 'net?  Where you can start 
installing a machine and have the machine already be compromised and 
subverted to be part of a bot-net before you even complete the 
installation and download all the OS patches?

Excuse me?

>  Another school of thought evident in many .conf files I've seen is something
>  like the following:
>
>  # Uncomment the following line to enable $functionality. This setting is
>  # disabled by default because it is important you understand why it exists
>  # and actually turn it on purposefully (which is what we suggest you do)
>  # See http://..... for full explanation
>  #
>  # Functionality = 1

I don't see how this is any different from what we're already doing today.

Please elaborate.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  Founding Individual Sponsor of LOPSA.  See <http://www.lopsa.org/>.