[Mailman-Users] query re "message has implicit destination" (devils advocate!)
brad at stop.mail-abuse.org
Thu Aug 31 03:01:41 CEST 2006
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
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
> 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
> 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
> 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
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?
> 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.
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/>.
More information about the Mailman-Users