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, <[EMAIL PROTECTED]> "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/>. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp