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

[Brad Knowles]

At 9:06 AM +0200 2006-08-31, Bretton Vine wrote:

>  Well a lot has been generated in this discussion already, now it's just a
>  case of summarising it and having someone edit. I like writing, and would
>  happily contribute but I can drag on a bit so need a good editor :-P

Yeah, I have that problem too.  That's why what was supposed to be a 
one-off article on spam-fighting for the LOPSA.org website has turned 
into a six-part series.  I put in everything I could think of, and it 
was just too damn bloody long to make a single post.

>  There wasn't a very solid connection between the source, the documentation
>  and patches. Lots of information, but no index (metaphorically). Lots of
>  pointers and usefool tools for searching, but no real "start here to do it
>  differently to the default" approach.

The problem is that we have our suggested method for handling virtual 
domains, but we cannot possibly know all the different other methods 
that might be out there that people might want to use, and how they 
might want to apply (or mis-apply) those methods to Mailman.  So, 
it's kind of hard for us to develop a guide to answer all those 
possible questions.

We can tell you how it is done in the current code, and we can give 
you pointers to alternative methods, but I don't see how we can 
realistically be expected to go beyond that.

>  I understand Mailman is superior to Majordomo in this respect, or is this
>  configuration dependant?

I think that Mailman is at least somewhat more resistant to mail 
loops, but all bets are off when messages are passing through 
gateways from Internet e-mail to proprietary internal e-mail systems, 
and then possibly going back out again.  Most gateway systems like 
that will strip off all the "ugly" additional header information that 
we need in order to be able to do our job of trying to avoid loops, 
etc....

>  No disagreement. But safeguards are merely insurance when you have proper
>  education in how to use tools no? As opposed to a necessity due to gaps in
>  the knowledge chain.
>  (i.e. the safety line is not intended to be used as a hand rail)

No, the safety line is not intended to be used as a hand rail, but if 
you're installing something without any prior specific knowledge of 
the groups that will be using it, but you might have a reasonable 
expectation that some of them might use whatever you install as a 
handrail regardless of whether or not you intended for them to do 
that, then what do you choose to install?

Do you install a safety line and hope that all the users are going to 
be smart enough to not attempt to use it as a handrail?  Or do you go 
ahead and install a handrail under the assumption that some users are 
going to be stupid/ignorant enough to use it as a handrail 
regardless, despite all possible warning signs that you might put up?

If you know you have some users that would prefer not to have a 
safety line or handrail at all, and others who would need the 
handrail, what do you install?


IMO, the only sane choice is to go ahead and install a handrail by 
default, but make it easy for the people operating the ride to easily 
switch out for a safety line or nothing at all, depending on their 
increased knowledge of their userbase.

>  Actually, if you're in an environment with lots of people interaction,
>  showing them a short-cut is like a good dead of the day, and in terms of
>  user-interface spreads nicely. Trouble is all the arcane knowledge is locked
>  up in the heads of people who spend more time in front of a pc than 
>people :-)

No "good dead" ever goes unpunished.  ;)

>  Ok, sounds fair. I'm a customer. I want to understand why things are done a
>  certain way. I want to know why they're no done differently, and I'll be
>  stubborn and even try it myself until it stops working.

Which gets us back to the answer that the default is safer this way, 
and if you want to change it then you are given the option of doing 
so.

If you want to further beat your head against that brick wall, you're 
welcome to do so.  Just keep in mind that insanity is defined as 
doing the same action repeatedly while expecting different results.

>                                                           I'm not about to
>  embark on learning Python just to understand Mailman (although it would be a
>  useful exercise in a broader sense) but I do wish documentation had the same
>  level of diligence and peer-review that the code gets (not specifically
>  mailman -- software in general)

In this case, there's not much to improve with regards to the 
documentation.  There's just not much to document.

There are lots of other areas where the documentation is known to be 
horribly weak, nonexistent, or wrong, and we would welcome any 
assistance from anyone who wants to help us fix that.  But this is 
not one of those areas.

>  I can point my users to documentation and URLs but I can't make them read :-)

No, but you should be able to read, and if they are not able to do so 
then you should be able to read it to them.

-- 
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/>.