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