Re: [Mailman-Users] query re "message has implicit destination"
![](https://secure.gravatar.com/avatar/358f04f5f993066da926a0892f774c83.jpg?s=120&d=mm&r=g)
Oops... forgot to send my reply to the list too. Sorry about that Bretton, I did not mean for you to receive it twice.
Bretton Vine wrote:
<snip>
<snip>
I think that the answer is quite simply that it was a design decision made based upon what the designers thought would be desirable for most users. This is because quite often spammers use the BCC: mechanism to try to avoid being pegged by certain anti-spam measures that look at the number of destination addresses to help identify bulk-mail attempts. Personally, I believe it to be a reasonable default.
Of course, there is absolutely nothing stopping you from turning the setting off. You probably would want some pretty aggressive anti-spam filtering and possibly graylisting enabled on your incoming queue of your MTA if you do that.
To override the default setting for NEW lists, you can add the following to your mm_cfg.py file:
DEFAULT_REQUIRE_EXPLICIT_DESTINATION = No
This will not change anything on the existing lists, you will have to change them individually or en mass with a withlist script.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Dragon said the following on 2006/08/30 10:03 PM:
Oops... forgot to send my reply to the list too. Sorry about that Bretton, I did not mean for you to receive it twice.
Not a problem, and thanks for the reply ;-) However it doesn't solve my problem of determining why a TO: list@vdomain; CC: third@party resulted in "message has implicit destination error". I can't seem to reproduce the incident myself for some reason.
(no criticism intended to developers, but I have to ask:) Was this requested by users; were users involved in this decision; or was it a case of developers deciding for users what they thought was best given the environment of email/lists from the developer perspective?
I repeat, no criticism intended, I just need to be able to give a complete answer and am anticipating the questions I'll be asked. :-)
Personally, I believe it to be a reasonable default.
I don't disagree. However the documentation is clear that BCC'ing a list will result in administrative oversight (if setting is'on'). But not very clear as to why a TO:list;CC:3rd-party would result in the same by a post from a list member who is authorised to post.
In terms of the logs, the error is /exactly/ the same whether it's
TO: list CC: someone
or
TO: list BCC: someone
or
TO: someone BCC: list
Yes, I'm being pedantic -- but an explanation of the principle doesn't always answer what happens in practice. I know answers can't be sucked out of thin-air, but perhaps this has come up before? (or not and I need to look deeper)
We've found relatively little spam making it to any lists as it is. By just how much a margin will turning the setting off impact on posts from non-members reaching the list is non-member posting is already disallowed? Is it just theoretical, negligible or will have it have major impact?
In terms of our logs, the "message has implicit destination" occurs maybe once for every 50 or so "post by non-member/unapproved-address to member-only list" so if you look at it from a higher level service provider approach it doesn't seem like it would make much of a difference, and therefore is unnecessary to leave the setting enabled.
I don't quite agree, but it seems to be a point of view without a strong counter-argument.
regards
| Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
Every portrait that is painted with feeling is a portrait of the artist, not of the sitter. - Oscar Wilde
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 11:22 PM +0200 2006-08-30, Bretton Vine wrote:
The developers *are* the original users. They wrote Mailman for themselves and their own needs, and were willing to share that with others. What has happened since is that a variety of other features have been added over time, based on their own requirements and desires as well as input from others.
But all of the core developers are also heavy users of Mailman, both on python.org and on other mailing list servers -- including some of the largest known Mailman-hosted mailing lists servers.
I'm not convinced that your case is what you think it is. I have not heard enough details about the problem to know for sure.
The answer is "it depends".
This week, changing this setting may make no visible difference, but next week you might get bombarded with spam being sent to the list which does not include the list address as a named recipient in either the "To:" or "Cc:" headers.
Every site is different. Every list is different. Every month is different. Every week is different. Every day is different.
Pick out which of these different issues apply to your different situation, and then figure out which different answer applies to your case.
At some sites, you're not going to see this kind of spam very often. At other sites, you see boatloads of it on an hourly basis. It all depends.
We prefer to have this option default to "on", because it is safer that way, and people can always choose to set their choice to be more permissive. The reverse would be much worse for sites that have these kinds of problems, especially if those sites tend to be administered by less Mailman-savvy personnel, since a great deal of damage could be done in a very short period of time.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/08/31 12:09 AM: <snip useful comments>
(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.
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.
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.
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. This is a frustration I personally have as I'm often the person documenting things smarter people do on the network I look after.
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*.
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.
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 $$$)
Ok, granted, no-one's specifically 'selling' anything here. That doesn't negate responsibility for the default options though. It's insufficient to give people an "option" to change something. Some need to know why/how/what.
</wipes froth from mouth>
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".
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? Now apply the same basic principle to a web-based list-administrative interface. Throw in some experienced majordomo users for good measure, along with some people that are unaware of anything other than a browser called IE exists and give them full control of their own lists. Seriously, what's the worst that can happen -- someone learning from mistakes, something we do naturally?
In my experience, presenting the end user with all the options early on (with clear explanations) leads to a more rapid and confident learning curve than giving them permanent training wheels and no explanation. Takes a bit more effort, but the rewards are well worth it. But at the same time you have a market that wants a one-size-fits-all solution. Catch-22.
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? If not, why is the default set to "on"?
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
regards
| Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
aibohphobia, n., The fear of palindromes.
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 2:07 AM +0200 2006-08-31, Bretton Vine wrote:
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.
The methods of open source development pre-date Richard Stallman and his GNU followers. Some of us remember those days.
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.
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.
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.
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".
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 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?
I don't see how this is any different from what we're already doing today.
Please elaborate.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/08/31 03:01 AM:
The methods of open source development pre-date Richard Stallman and his GNU followers. Some of us remember those days.
And quite a few are still around to teach us who take the net etc for granted which is a good thing.
So far my experience has been wonderful with the product, good and bad with the documentation, and rather difficult in terms of user-error, namely mine.
Then that's the answer I have. My job is to keep things running, and if they break fix them fast or provide reasons/solutions. However it's hard sometimes defending a choice in platform when some or all of the following are insufficient:
- because everyone's using it
- because it's free [speech or beer]
- I don't know! It worked yesterday
No offence intended, but this is a rather closed-off point of view. It's completely valid yes, but leaves no room for organic growth. A view of "we have enough users, we do this for our own reasons, we know we can improve this and that but there's no urgency" actually shrinks a community in the end.
I'm not saying there's an obligation to use or prove your software (and time/effort interacting with the user base) just that any project can become bigger than the sum of its parts and developers should be aware of that.
I'll leave the philosophical analysis of that aside for now.
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.
Doesn't seem quite efficient to have people duplicating labour for no reason other than stubbornness.
Nor are we specifically a commercial list environment. The nature of our income-generating business is such that lists have proven to be extremely useful over the years and form the basis of in-house communication and communication for the participating associations we manage.
However my point is that Mailman will still be used commercially. Which creates expectations. You can't manage the expectations of others so it's a difficult road to travel.
I understand. But look at it from a point-of-view of say a prior majordomo installation where the safe defaults are different defaults. Look at it from the point-of-view of someone who knows the prior defaults and may be confused by the change. Yes the new defaults are safe, but why? (obvious answer: changing environment and needs)
Aye, and balance a hierarchy of dependencies between organisations and information dispersal (and pace thereof) and legal accountability becomes a concern.
Change may be necessary, but not everyone wants it. In my current situation we've discovered that the need to disperse information quickly and accurately is more important than the possibility of a flood of spam. I sold my employer a migration path in a particular direction and this filtered down to clients but has had some unintended consequences along the way.
I think a fair analogy would be (as if speaking to a client):
I'm sorry, we can't assist you as normal, we're busy upgrading our systems and did not anticipate this issue, please call again soon
Obviously there are situations you just can't do this in.
For the lowest common denominator? None. Even the simplest possible web interface would be too complex for them.
Boy, that's harsh. ISOC-ZA had an open-day last year, setup some computers and an internet link in an under-privileged area. Invited the local community (young and old) to come see what the Internet was all about. Many using computers for the first time. And they practically had to pull the people away from PCs so others could get a chance too.
Didn't take long for someone presented with a browser and search engine to get the swing of things. (And yet the irony is that there are middle-class workers who have been using computers at work for some years who still 'just don't get it')
I've knocked out our system quite a few times (by accident or oversight) and yes there's often hell to pay and some sleepless nights -- but we've yet to find a user who takes the system down because they have a web-interface or email-interface to the system so they can manage their own list.
It's like the parent who refuses to let their child near a pc in case they break it (but secretly because they wouldn't know how to fix it if they did) compared to the parent who gives a child an old keyboard to bang away on in the early years. The latter somehow never seem to actually break things beyond the point of being able to fix them. The former end up as luddites.
See Subject: (devils advocate) ;-)
In alternate reality one, the safe defaults are automatically decided for the user. In alternate reality two they are suggested but the user has to enable them. Which reality informs the user more?
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
Tyler: Hitting bottom is not a weekend retreat, it's not a damn seminar. Stop trying to control everything and just let go. Let go! - Fight Club
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 4:56 AM +0200 2006-08-31, Bretton Vine wrote:
So far my experience has been wonderful with the product, good and bad with the documentation, and rather difficult in terms of user-error, namely mine.
I am of the opinion that all software sucks, but some sucks less than others. IMO, Mailman sucks less than any other MLM I've seen.
Of course, amongst most open-source projects, documentation is a serious weak spot. Those who are developers write code, not documentation. And if they do write documentation, you frequently wish that they hadn't. Those who are operational-types (like me) don't write code, and usually don't write documentation, and if they do write documentation you frequently wish that they hadn't.
The good documentation writers rarely seem to cross paths with any open source project I've seen.
It's a known serious weak spot within the Mailman project, and we'd love to be able to resolve this issue, but that means we need to get some people onboard that are good at writing documentation. Any suggestions you may have in this area would be gratefully accepted.
I can't say where things will end up. I don't think I can even make much of a guess. I can tell you that we're getting a large enough influx of users that it is difficult for us to keep up without doing anything more to actively draw in more users.
In that kind of high-growth environment, it's hard to justify doing anything that would actively draw in more users and would likely hamper other development efforts that we consider to be more important than maximum growth of the userbase in the shortest possible time.
My preference would be to have a more sustainable growth pattern over a longer period of time, based on a higher quality product that we've been able to develop and field, then let the growth take care of itself.
But that's just my personal view, and is not necessarily shared by anyone else.
I think that the developers are well aware of this issue, especially since multiple other groups have taken the Mailman code and made unapproved changes to it, and then fielded that to their users -- but without providing adequate support for their modified versions and thus leaving us holding the bag they created.
Sometimes you can't stop them, no matter what you do. IMO, when you discover that the kind of situation you've got with a particular person, then the best thing to do is to recommend that they go ahead and do whatever they want on their own systems and to report back to you regarding their success.
Otherwise, you're mud wrestling with a pig, which only gets you dirty and sweaty and annoys the pig.
However my point is that Mailman will still be used commercially.
True. Like it or not, there's nothing we can do to stop them.
Which
creates expectations.
Also true.
You can't manage the expectations of others so it's a
difficult road to travel.
Indeed. We do the best we can through what documentation is available (including the FAQ), but there's little we can do beyond that.
Majordomo is different from Mailman, and I would not be surprised if certain features were present in one package and not in the other, or if certain defaults were set one way in one package and the opposite way in the other.
But if people don't understand that different software is frequently different, I'm not sure that there's much I can do to help them, and I'm not sure that there's much that anyone else can do to help them, either.
Do you want a complete and total moron to have his finger on the nuclear button, and capable of blowing up the entire planet many times over?
Oh, waitaminnit, we already have that situation....
The number of things that a list moderator or list admin can do through the web are limited, and the danger is reduced. But if/when we make all site administration functions available through the web, the danger will be quite a bit higher.
Even list admins can subscribe a bunch of other addresses to their lists, and create loops with their subscriptions. It only takes one loop that causes every message coming in to the list to be duplicated and then re-sent back to the same list (and duplicated again, ad nauseum), to bring down the whole system.
If you've got a large system (e.g., something that can generate millions of mail messages per day), it's easy enough to make a mistake that could take down a lot of other systems around the world and not just your own.
These are powerful tools we're talking about here, and it's easy to do things to wind up accidentally shooting yourself in the foot -- or maybe accidentally shooting your neighbor in the head.
With powerful tools, you also need powerful safeguards.
Right, but precisely who is our "user", or perhaps I should say "customer"?
I submit that *our* customer is the site admin, and this is precisely the kind of thing we offer to them. The customer(s) of the site admin would be the list admin(s), and the customer(s) of the list admin(s) would be the list moderator(s) and the list recipient(s).
So, it's up to the site admin(s) to look through the defaults we've provided to them and decide which ones they want to change for their customers, and it's up to the list admin(s) to look through the defaults they're given by the site admin(s) and decide which ones that they want to change for their customers.
I submit we've done our job for our customers, and it's up to them to do their job for their customers, and so on.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/08/31 05:36 AM:
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
Sounds like a good plan. In a world of build-it, grow-it, sell-it in 24 hours it's useful to have the voice of reason prevail.
Yes, my initial experience (relating to virtual domains on a single installation) using third party patches took a lot of time to reach the conclusion that was already summarised as:
"it's possible, but better to have multiple separate installations instead"
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. In turn I had to settle on an installation method, write my own HOWTO specific to our system and then tweak it over time to remove what was unnecessary and add in what I missed conceptually first time around. A useful exercise, but time-consuming.
Indeed. We do the best we can through what documentation is available (including the FAQ), but there's little we can do beyond that.
I disagree, I've found this discussion quite informative and sure others have as well. What I mean is you can 'do more' than just code or write up some documentation. Merely engaging the user base one-on-one adds something more to the experience of learning.
After all, for most people it's more like this:
user <--> support desk <--> engineer <--> developer
with lots of fancy but useless communication methods in between. I think most people are eager to learn, just afraid of looking stupid by raising a hand for a question (especially a frequently asked one)
I know. And embarrassing when you're the last to find out <chuckles> I understand Mailman is superior to Majordomo in this respect, or is this configuration dependant?
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)
Thanks, you've just illustrated a point I often try to make. Ultimately the proverbial 'you' drives the computer. You're responsible for what it does and doesn't do. Mistakes happen, but so too does random knowledge ... you know like you pick up a new short-cut you didn't know by watching someone else do it fist.
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 :-)
I submit we've done our job for our customers, and it's up to them to do their job for their customers, and so on.
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. 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)
I can point my users to documentation and URLs but I can't make them read :-)
| Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
If you're not failing every now and again, it's a sign you're not doing anything very innovative. - W. Allen
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 9:06 AM +0200 2006-08-31, Bretton Vine wrote:
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.
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, 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.
No "good dead" ever goes unpunished. ;)
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.
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@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/>.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Brad Knowles writes:
IMHO, it's the *same way to go.* AIUI (I seem to be missing a post or two) Mailman accepted the mail, Mailman did not drop it on the floor, Mailman *could* have sent it---but the Postel Principle doesn't imply that it should have done so. We have good reason (by default, which default doesn't apply to Bretton's shop, it seems) to believe that that post should be looked at (strictly ;-) by a human before sending.
Steve
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 8/30/06 6:01 PM, "Brad Knowles" <brad@stop.mail-abuse.org> wrote:
The methods of open source development pre-date Richard Stallman and his GNU followers. Some of us remember those days.
For example, SHARE from the 1950s. At one point, MITs 704 (or 709 or 7090 by then) data center posted a notice which, paraphrased from memory, said "We have SOS (SHARE Operating System) and will attempt to run it on request. We won't be responsible for failures of SOS."
By the way, the explanation of the option in the administrator interface seems reasonably clear to me (as a Mailman "customer" not developer). However, I doubt that there are many new list administrators who look there when setting up a list.
And, unfortunately, were I preparing a list of options for a "You really ought to look at these options and check that they are set appropriately" paragraph, I probably wouldn't include this one. There are so many which are more important for such a thing.
--John
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
John W. Baxter said the following on 2006/08/31 06:58 PM:
Perhaps a list of "you /really/ should set these settings to X" would be useful to people short on time :-) Of course you could just bundle the product that way in the first place but where's the fun in that?
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"I think that's how Chicago got started. A bunch of people in New York said, 'Gee, I'm enjoying the crime and the poverty, but it just isn't cold enough. Let's go west.'" - Richard Jeni
![](https://secure.gravatar.com/avatar/358f04f5f993066da926a0892f774c83.jpg?s=120&d=mm&r=g)
Bretton Vine sent the message below at 10:08 8/31/2006:
That is what the Defaults.py file is for.
The defaults as shipped were chosen by the developers. We should assume that they were chosen for good, logical reasons that apply to the majority of installations.
But if you don't like the defaults or have a reason to choose a different setting, you can change them at your own risk either through configuring each list or by overriding the setting in mm_cfg.py
Open source projects are never going to have documentation to the standard you want. Unless you or somebody else is willing to take on that large project, continuing to harp on the subject is only going to serve to annoy people.
The fact that this software is made available to the community free of charge is a gift to the community. The fact that people like Brad and Mark and others are willing to expend large amounts of their time responding to queries here should be taken as what it is, another gift to the community. I think they have gone above and beyond the call of duty in this discussion and I am amazed at the restraint they have shown.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Dragon said the following on 2006/08/31 07:44 PM:
I'm not criticising, and I'm more than willing to put in some effort. What useful settings apply? The default 'legacy' antispam measures are merely an example (for example).
That's the trouble with email - tone is lost, along with intention ;-)
I think they have gone above and beyond the call of duty in this discussion and I am amazed at the restraint they have shown.
The teacher learns more from the student than the student learns from the teacher. It would be wise not to forget that. <big grin>
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"It is important that students bring a certain ragamuffin, barefoot, irreverence to their studies; they are not here to worship what is known, but to question it." - Jacob Chanowski
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Dragon said the following on 2006/08/31 07:44 PM:
(on a more serious note)
I view it differently. I have had great feedback and I highly doubt either of the parties mentioned viewed a response as a "restraining, difficult exercise". I /really/ use lists to their full advantage and with some in particular have never felt my input or response was an exercise in patience or restraint. It's a labour of love. You do it because it's what you do.
That's not to say I don't appreciate a response (some time after the fact) with another avenue to explore (thanks Mark) but compare the difference between "you're harping on about nothing" to "have you tried this?". The latter (in hindsight) is blindingly obvious -- and yet no-one else let their sub-conscious ponder the problem a while longer.
Lists are communities. And community isn't about 'gifts' from the elders or sticking to sensible rules. It's about invigorating the elders so they feel like children in a toy-store again. (and no I'm not being ageist or condescending or merely rebellious here)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"This is a test designed to provoke an emotional response: The water supply IS tainted"
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 8:25 PM +0200 2006-08-31, Bretton Vine wrote:
Maybe I'm getting better at this process than I have been in the past, but I most definitely held back quite a bit in my responses. I did allow myself to get a bit testy, but that's about it.
It took me a while to realize that you were more playing devil's advocate (on behalf of your boss) as opposed to actually believing in some of the things you were saying.
And yes, a great deal of context is lost in e-mail. Remember that about 90% of all human communication is not verbalized, and of the remainder about 90% is more in the tone of how you respond as opposed to the actual words that are chosen. Pretty much all of that is lost in e-mail, leaving only the words -- and about 1% of what would normally be conveyed in a natural human conversation.
A lot of my responses were defensive in nature, responding to the way I felt that our entire community was being attacked, and I took that pretty personally.
As such, there really wasn't any time available for me to ponder the question in any more depth. If I'd had that time, I might have been able to find a better way to convey what it was I was trying to get across.
Now, I may have managed to moderate my response quite a bit, but that doesn't change the fundamental nature of the situation as it occurred.
It should be about enabling people to contribute something and allow them to feel useful, in whatever way that they find that they are best able to do. We don't always succeed in that goal, however. But as we work towards that goal, we should find that when everyone helps everyone else, we all benefit from the combined strength, and the result is much greater than the sum of its parts.
The big problem comes when a new person comes in, or a new situation occurs, and one or more members of the community feels like they are being attacked, and how they respond. The result can either strengthen the enlarged community, or be extremely destructive.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/f861849565e5eb3313e869f4f3fb77d0.jpg?s=120&d=mm&r=g)
--On August 31, 2006 7:08:22 PM +0200 Bretton Vine <bretton@hivemind.net> wrote:
To which I reply:
Could we maybe leave this poor dead horse to rest in peace?
Apparently, many of the posters to this list believe (with some justification, imho) that it should take explicit action to undo safe defaults, rather than requiring explicit action to set safe values. You disagree. You've made that abundantly clear. Fine. We believe that you disagree.
But based on my (rather more than I care to contemplate) years in this business, I think you're wrong.
-- Steve Burling <mailto:srb@umich.edu> University of Michigan, ICPSR Voice: +1 734 615.3779 330 Packard Street FAX: +1 734 647.8700 Ann Arbor, MI 48104-2910
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Steve Burling said the following on 2006/08/31 07:55 PM:
Could we maybe leave this poor dead horse to rest in peace?
Only if I get a last word in edgewise :-)
Then you've misunderstood me. I don't disagree, and since turning the setting off have seen an immediate *and* significant increase in the amount of spam getting to open lists which answers a question I raised earlier.
The point I was illustrating is that if you have to justify the rationale behind a default setting to a third-party-decision-maker -- what is the most appropriate and concise response?
But based on my (rather more than I care to contemplate) years in this business, I think you're wrong.
I may well be. However I dispute the reasoning that things are done a certain way 'just because that's the way they're done'. This thread has resulted in far more knowledge than I need convey on to my boss/clients, but it has been immensely useful too. Both in terms of my learning, and proposing alternate perspectives. Just because I present a point-of-view doesn't mean I agree with it. Nor does it invalidate it.
I've heard arguments from developers critical of third parties modifying the software in a particular way and then failing to support it accordingly. I've heard arguments that the developers know what's best. I've questioned whether these approaches are based on developer-need, user-input or pure reasoning. I don't believe I've done anything a curious individual could be faulted for, nor do I see any evidence that people willing to take a moment's pause for a reasoned response reacting uncomfortably or being unwilling to share their experience or philosophy-of-approach.
In closing, I needed a simple answer. I couldn't find one myself, so I asked. In return I learned far more than I requested, and developed an immediate respect for those who understood where I was coming from. In time perhaps those who endured irritation will understand. :-)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"All progress is based upon a universal innate desire on the part of every organism to live beyond its income." — Samuel Butler (1835-1902),British writer.
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 8:44 PM +0200 2006-08-31, Bretton Vine wrote:
This is the key point that was not coming across to me, at least not until much later in the exchange. Speaking only for myself, I seriously misunderstood what you were asking and why, which greatly colored my responses.
I'm still not certain that we've given you the best answer to this question, but I'm hoping that you'll be able to synthesize something that you will then be able to contribute back to the community, and we will hopefully be able to avoid these kinds of problems in the future -- at least with respect to this one particular issue.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/09/01 01:24 AM:
My apologies, I could have been clearer. I did try and fork the thread with the inclusion of (devils advocate!) in the subject line.
I may not have what I was looking specifically, but I do have a clearer of how to approach things in future.
I've had to edit context significantly for various reasons (brevity being one) but it comes down this. We've had a solution in place for 10 years that just works but doesn't offer us the functionality we need or clients want any more. I've been on mailman run lists for ~6 years and found the setup to be more useful and when the time came for a new server had to make a number of decisions based on skills available, difference in volumes of legitimate mail and spam today (compared to setup of ageing server from 96) and new things to be learnt using a different OS and architecture.
A mistake appears to be the perception (prior to installation and initial use phase) that Mailman was Majordomo with a web-gui and archives. It's not. It's a different product and approach entirely. This realisation is hammered home in the implementation of Mailman -- but not easily visible when researching alternative solutions to the previous way we did things.
Such a mistaken perception is echoed both up to management and down to users in selling the solution. You get approval, go ahead and implement and then there this "oops" moment and realisation you didn't have all the knowledge to begin with, and sold management and users a solution you just couldn't (at the time) anticipate certain problems with. So it's your head on the block and you either have to wing it or come up with an explanation that satisfies both users and management without too much trouble in the process.
Just as an example, some list-owners have pending administrative request queues numbering in the hundreds already. No amount of prodding or pushing or assisting helps them just to complete a small and easy daily task. Feedback is "my prior list didn't bother me with stuff" or "Oh, I used to just ignore that stuff anyway". Horse --> water situation.
Additionally in terms of the historical setup, things with majordomo were already highly customised to our needs, and when I came in I assumed/took-for-granted this was the default (old system has even worse documentation than anything else I've seen <chuckles>) and also assumed thing would be echoed in the Mailman setup. My mistake, but during the "ask around for suggestions" phase most of the feedback I got was Mailman orientated, like the move is just a casual change in clothes. It's not :-)
Now despite my mixed positive/negative reactions to documentation and feedback from the list, and growing growing appreciation of why certain things were done a certain way, neither users or management have the time to sift through the same volume of information to reach a satisfactory conclusion. Instead you get a very offensive response due to resistance to change, or new variables.
You see the following doesn't cut it in that situation:
- but we can change it
- we can modify the source if we need to
- that's the way the developers chose to do it
- the documentation was lacking
In an environment where someone has to take responsibility for a situation, even if it's not their fault as such, providing the best answer to users or management can go two ways. Shift the blame, or fix the problem -- even if it means undoing the best practices suggested and letting users/management realise for themselves why it's a bad idea. But in some environments you just can't afford to do this.
So far I've discovered that yes, most of the safe defaults are the best desired functionality. And that on a Debian/Exim setup it's best to install from source, and if using virtual domains to install a separate installation of mailman per domain. The additional overhead on the box isn't that much for ~20 domains. It might be for more than that though. I've also found the documentation to be scattered but where there is info that can be referenced, it's generally pretty good.
Once we have a stable system that meets the needs of users and management I'll be happy to share the setup of how we've done it in our particular way along with some rationale behind the different decisions based both on what I've learnt on this list, and from user/management feedback.
Obviously every installation is in a different environment, and as has been mentioned Mailman isn't a one-stop-solution-for-all-situations solution. There is also a lot of public misconception about Mailman in general -- things you only realise when you're actually implementing it on a box or run into trouble. I doubt anyone is to blame for this -- there are simply too many variables involved.
I'd suggest to anyone looking at Mailman as a solution search the docs/FAQ/list-archives, *and* join the list and ask a few questions before actually implementing. It's a lot easier to anticipate certain things that way. :-)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"Gods are fragile things; they may be killed by a whiff of science or a dose of common sense." - Chapman Cohen
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bretton Vine wrote:
FYI, in case you missed it, beginning with 2.1.6 there is a max_days_to_hold list setting and the corresponding DEFAULT_MAX_DAYS_TO_HOLD mm_cfg.py setting.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 8/30/06 6:01 PM, "Brad Knowles" <brad@stop.mail-abuse.org> wrote:
"unapproved" may be a bit strong. Perhaps "un-vetted" would be closer?
But the idea is right on. When I see a thread about running Mailman on CPanel or Plesk or Mac OS X Server, I ignore the thread (and I run Mac OS X on my desktop).
I just recently wrote a FAQ entry on this subject -- see FAQ 1.32.
Quite nicely done!
--John
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 10:06 AM -0700 2006-08-31, John W. Baxter quoted "Brad Knowles" <brad@stop.mail-abuse.org>:
Actually, I think either "unapproved" or "unauthorized" are the most appropriate terms. After all, the code is released under the GPL, and anyone who is making modifications to that code and then making their modified version available to their customers (or otherwise benefiting from those modifications) are supposed to contribute the source to their changes back to the community. But CPanel has not done this, neither has Plesk, nor Apple.
Now, in a way, Apple gives back to the project more than they probably realize, but that's not the same thing.
So, while we don't make that big a deal of this issue, I think I'm actually being reasonably lenient on these companies.
I just recently wrote a FAQ entry on this subject -- see FAQ 1.32.
Quite nicely done!
Thanks!
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Brad Knowles writes:
Excuse me? The GPL *explicitly* approves and authorizes (not to mention implicitly encourages) modification and redistribution without conditions other than providing source. That's exactly what "license" means.
Has anybody at Mailman asked CPanel, Plesk, or Apple for source and been refused? Or one of their customers, and been refused because they were under NDA? If we haven't asked, how can we bitch?
C'mon, Brad, you know what the GPL actually says. They're supposed to give the source to their customers. That's all it says.
It is quite possible to write a license that says you *must* give your modifications back to some entity. You could argue that the reason the GPL doesn't do that is that "the community" is the only appropriate beneficiary, but it's impossible to legally define "the community" in a satisfactory way. But I don't think that's what Richard Stallman has in mind when he declares licenses containing such clauses "unfree". Nor do they satisfy the DFSG or the OSD. I believe it's that the whole idea of demanding payment of any kind is unfree.
So, while we don't make that big a deal of this issue, I think I'm actually being reasonably lenient on these companies.
I would say we're not trying to accomplish by jawbone what we refuse to put in the license. And that's very important to me. It's one of the things I like best about this community. Of course you're certainly welcome to consider that you're being lenient; I'm simply explaining that I very much appreciate your lenience, but I rationalize it differently.
Once again, has anybody simply *asked* these companies for their code, and maybe for some contribution of labor toward integrating it? If so, how recently? I realize that we probably "dislike" some of their changes, so they wouldn't make it into the mainline (at least not as defaults), but it could exist on more or less deprecated branches. Surely there are CPanel- or Plesk-using ISPs who would like to have Mailman project support available to their customers; we should be able to get moral, if not financial, support from them.
Sincere regards, Steve
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 2:32 PM +0900 2006-09-01, <stephen@xemacs.org> wrote:
Right, and they haven't provided the source.
I don't know about CPanel or Plesk, but I'd be willing to bet that they would not be willing to provide the source code to their changes to anyone, although a knowledgeable person could extract the source code differences by comparing what is shipped by the commercial vendor against our code, although it might take some work to figure out which version of our code they should be comparing against.
I'm pretty sure that I know what the answer would be from Apple. You see, the primary problem is that the Server Group is totally and completely unresponsive to their own high-paying Platinum-account customers (i.e., major Universities and businesses with thousands or tens of thousands of machines), and likewise completely unresponsive even to internal people at Apple who are working in other groups.
You'd have to ask Barry as to whether or not he has actually contacted these groups to ask them to contribute their code changes back to the community, or if anyone has gone to the FSF lawyers to have them send a letter requesting that the company in question honor their obligations under the GPL.
I just don't have the answers to the questions you're asking me.
Moreover, I don't think that it's reasonable for you to respond to me in this manner. What have I ever done to you? When have I ever said anything that would lead you to believe that I would have the kinds of answers you require to these extremely loaded questions you're asking?
If you want to get into a diatribe about licensing, please be aware that I'm a BSD guy, and I've found myself surrounded by a bunch of GPL types, so license-wise I've tended to say pretty quiet.
But if you want to argue the finer points of the GPL with someone, my response is going to be that none of this would be a problem if they'd just use a BSD-like license instead and then be done with it.
As such, I'm not going to be your foil for your GPL holy war, and if you want that then you would be better off looking elsewhere.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 1:39 AM -0500 2006-09-01, Brad Knowles wrote:
Sorry, I meant "... stay pretty quiet". That was a bad typo to have in such a place.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/09/01 08:39 AM:
Note, the issues raised are not unique to Mailman or other popular GPL products. There is an undercurrent of concern over how Ubuntu is building on Dedian but not necessarily contributing back, and developer dissatisfaction at the Debian level moving to the more trendy and dynamic Ubuntu front.
The GPL approach has obviously been useful (and popular) but I find many 'just solve the problem' type individuals seem to favour the BSD approach. Kind of "you're welcome to use and modify, just don't blame us for any consequences", whereas with the GPL it's more about a zealous popular uprising against corporate overlords.
I don't think there is any obligation for someone who changes the source of a GPL product to give the changes back to the original developers, but there might be a case of 'good manners' at play in that it is polite to do so. I'm sure developers welcome input even if they choose not to include it in the primary code distribution.
One can however approach someone who has modified the source and request the modified source but there may be trouble getting a diff version of the modifications made and reasons why.
However it's probably a case of motivation. Developers would need to be motivated to chase one of the organisations mentioned and it would be time-consuming and require effort when they might prefer to be coding. Obviously a gap here for a champion from within the user base to pursue the matter further.
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"To teach a man how he may learn to grow independently, and for himself, is perhaps the greatest service that one man can do another." - Benjamin Jowett
![](https://secure.gravatar.com/avatar/358f04f5f993066da926a0892f774c83.jpg?s=120&d=mm&r=g)
Bretton Vine did speak thusly:
Disclaimer: I am not a licensed attorney and this is not to be construed as legal advice.
Have you actually read the GPL?
http://www.gnu.org/licenses/gpl.txt
There is such an obligation explicitly defined in it within section 3 that states that source code of any derivative work MUST be provided either as part of the actual distribution of the work or upon request to ANY third party that requests it. Section 2 also plays heavily into this situation.
Thus by either passively ignoring or actively refusing requests for source, Apple, Plesk and CPanel are in direct violation of the GPL.
And while we are on the subject of the GPL, sections 11 and 12 basically state that there is absolutely no warranty for the fitness or suitability of a GPL program and that your use of a program under the license is entirely at your own risk.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Dragon said the following on 2006/09/01 05:29 PM:
Have you actually read the GPL? http://www.gnu.org/licenses/gpl.txt
yes plus variations ;-)
Yes, but that's not what I said. I said there was no obligation to send changes back to original developers, but that it was polite to do so. Obviously, if the original developers ask for the changes then yes, but if they've failed to do so there is no obligation. (The feedback appears to indicate that they have asked however)
In fact I can take GPL code, modify it and use it internally without either the original developers or any third party knowing I've done so. I'm under zero obligation to inform anyone of my actions or changes. If however I start distributing the changed code it must be done so under the same licence, and upon request I must make the source available.
There is no obligation for me to indicate what I changed from an original code base (code or docs) only an obligation for me to provide the source *on request*.
Manners imply shipping the compiled product with source, but it's not necessary or necessarily a rule followed by everyone.
Thus by either passively ignoring or actively refusing requests for source, Apple, Plesk and CPanel are in direct violation of the GPL.
Ok, then any person is welcome to contact those organisations and request the source. If they fail to provide it you can take the matter up with the relevant people at the FSF.
http://www.gnu.org/licenses/gpl-violation.html
(well technically only copyright holders can do so)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"A new study shows that licking the sweat off a frog can cure depression. The down side is, the minute you stop licking, the frog gets depressed again." - Jay Leno
![](https://secure.gravatar.com/avatar/358f04f5f993066da926a0892f774c83.jpg?s=120&d=mm&r=g)
Bretton Vine sent the message below at 08:47 AM 9/1/2006:
No, it was not exactly what you said but it could be interpreted in such a way.
Yes, you can. But that is also not applicable to this situation because Plesk and Cpanel and Apple have all taken the mailman code, applied changes and redistributed them.
And that is the crux of the issue because as I understand it, such requests have been made and rebuffed or ignored.
Nor is it required under the GPL. The GPL only requires that it be made available and does not specify the exact mechanism of how this must be done.
Thus by either passively ignoring or actively refusing requests for source, Apple, Plesk and CPanel are in direct violation of the GPL.
If the link Mark posted earlier with Apple's source code does indeed have their version (which looks likely due to a different version number on it), then I retract my statement about Apple. By providing the source on the web, they have adhered to both the letter and the spirit of the GPL.
Very true.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Dragon writes:
Bretton Vine did speak thusly:
Bretton's right. Satisfying *any* of 3a, 3b, or 3c means you are in full compliance with section 3. If you distribute source as part of every distribution you make, you are under no legal obligation to give source to any third party. That includes upstream.
BTW, I was quite surprised at the way you construe 3b; I've always assumed "any third party" was a reference to recipients of non-source distributions under 3c. But IANAL and I'm often enough wrong---you're probably right.
Thus by either passively ignoring or actively refusing requests for source, Apple, Plesk and CPanel are in direct violation of the GPL.
cPanel seems not to be. Definitely not at the installation Todd Zullinger has access to. I would not be surprised if both Apple and Plesk are similarly in full technical compliance. Especially Apple, since Steve Jobs has not had very good luck with trying to violate the GPL in the past. :-)
Steve
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Brad Knowles writes:
I just don't have the answers to the questions you're asking me.
That's fine.
Moreover, I don't think that it's reasonable for you to respond to me in this manner. What have I ever done to you?
Since you ask, lots of nice things. I've certainly benefited from your contributions to these lists and the FAQ. Thank you!
I'm not sure what you mean by "manner", but the reason I responded is that I got triggered by the juxtaposition of "us vs. them" language with "GPL". I agree that there's a justification for a feeling of "us vs. them" between Mailman and the companies mentioned, but in my experience the GPL normally contributes to such antagonism, and I've never seen the GPL help alleviate it. So I want the GPL out of the discussion (unless the companies are in violation of their license, which seems possible---that's why I asked for evidence).
When have I ever said anything that would lead you to believe that I would have the kinds of answers you require
Aren't you the guy who was there when the Postel Principle was coined? <wink> You're right, I should ask Barry, but Barry's not here right now that I can see, and you usually do have answers, good answers.
to these extremely loaded questions you're asking?
What's loaded about the questions? True, my phrasing assumed that you probably knew the answers to the questions, but I didn't mean to imply any obligation for you to know them.
Your post asks for more than the GPL does. I agree that it would be good if these companies would participate actively in the community. But I'm more confused than ever why you cited the GPL in support of that, since you write:
As such, I'm not going to be your foil for your GPL holy war, and if you want that then you would be better off looking elsewhere.
All I want w.r.t. the GPL is that downstream do what it explicitly demands, since that is the license Mailman uses.
And maybe Mailman should consider asking for source code from these companies, to improve support for not a few users.
Steve
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 9:30 PM +0900 2006-09-01, <stephen@xemacs.org> wrote:
I'm not really citing the GPL, at least not per se. I know what the GPL actually requires, but as far as I'm concerned any changes that are made without being approved by Barry or filtered back into the community would qualify as "unapproved".
All I want w.r.t. the GPL is that downstream do what it explicitly demands, since that is the license Mailman uses.
If they were willing to do that, I'd be reasonably happy.
And maybe Mailman should consider asking for source code from these companies, to improve support for not a few users.
That's a good idea, but that's another issue for Barry.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Brad Knowles wrote:
FWIW, I only this week discovered that Apple has Mailman source code on it's web site.
I found the following quote somewhat ironic -
Apple uses software created by the Open Source community, such as the HTML rendering engine for Safari, and returns its enhancements to the community.
(<http://www.apple.com/opensource/>)
Anyway, if you go to <http://www.opensource.apple.com/darwinsource/> and follow any of the "Mac OS X 10.3 Darwin 7.0" or later "source" links you will find links to Mailman source. I don't know whether this is Apple modified source or just our source. I haven't had time to investigate this.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 8:42 AM -0700 2006-09-01, Mark Sapiro wrote:
Looking at <http://www.opensource.apple.com/darwinsource/10.3/mailman-105/mailman/NEWS>, it appears that they started with Mailman 2.1.2, but I am not yet seeing any Apple-modified stuff.
Looking at <http://www.opensource.apple.com/darwinsource/10.4.7.ppc/mailman-117/mailman/...>, it looks like they got up to version 2.1.5, but again I'm still trying to figure out what parts may have been modified by Apple.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brad Knowles wrote:
I grabbed the source from:
http://www.opensource.apple.com/darwinsource/tarballs/other/mailman-117.tar.gz
which is linked from (among other places):
http://www.opensource.apple.com/darwinsource/10.4.7.x86/
The mailman sources are in the tarball in the mailman dir. The diff to that is here:
http://pobox.com/~tmz/mailman-apple.diff.bz2
There are other Apple specific things in the tarball, Makefile, init script, etc, which are worth checking out to see how they package Mailman and how that may affect those coming here for some help with those Apple packages.
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Conscience is what hurts when everything else feels so good.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQFDBAEBAgAtBQJE+GtFJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzjghkH/3uFSEtRrSyM9XAg5Vl/47lLqlWPcTCX0MLe C3Si8ZLnYzj/7nDZD+ehmohpMM9p1I6+vl+W3RiG/fKrPfAEV1IAoqEbVBQEJytG sT1F4BOEu1eEpfKuYN4sWdJaCUwgi27uvo2o2jk1BcILxc6SUyEMHXQBhlrML0Kw uz934fTS9UvYYuOrqKPfp5L6euSSRDJNYijIzCVUUw809FYw/yzr8/SuEdXN1e6m dxKjOLoufaPe1fYm1AZf5GsUduZhP7FOwnxj9DGR4OJ+3d0MJ6sE8j551MGjaR58 znov5QwIqoqV+yUV996z1RmXUPeWyR1VGVUVMBpb/JXAYZOVjwI= =QTnP -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
stephen@xemacs.org wrote:
I asked cPanel a few years ago. I got the run-around and they closed the support ticket 2 or 3 times without providing any source or diffs. Only after persisting did they send me a link to a half-assed diff that I know didn't match all that they changed.
I've since had the displeasure of working on a cPanel hosted system and there is a source directory for mailman. If anyone's really curious, I'll diff it against whatever the official source release they're claiming it is.
They may be honoring the letter of the license, but they deserve the shit they get here for abusing the spirit of it so badly. If I made changes to Mailman that caused a regular stream of frequently asked questions I'd fix the problems or get involved in helping answer them just so I could sleep at night. cPanel doesn't do that and they are charging folks good money to package up free software. That leaves a bad taste in *my* mouth, and I'm not even a significant contributor to Mailman.
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
The more laws, the less justice. -- Marcus Tullius Cicero "De Officiis", 44 B.C.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQFDBAEBAgAtBQJE+CMLJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzj8hIH/2wPr7N2DRiWA/domQpwv9uylQea2a8ilIec A29uZeuZyy0vIQiV6qGvrhUdkE/9e/GQBG09+vias5I2U7g9H/4zer9G+esNDm1c 1S6Wag/KzT75/wDIamqb0PyXDuiwq1yAye5cCdPRnKaPWtjLJzTsycPgXmXmDx4v OGF1+NNuOXh1jvA+XQXl7sLTh/bSewgu0QdZIeMYnd+WNoC27eWWin3g6n7CjVNi j87yBzu5pHbW+Maj4EL0opShnmelTpNyst+iqRtwAU5KEq5sC6U7DE5rX9s7xSWM RYK8KCqq4rK7IyplyMtnXgVbhGQydi3VkRDm3eF1+RguZbIl9bc= =E9Gk -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Todd Zullinger writes:
If you actually do have the right to do so, yes, please. If nobody else wants it, feel free to send it to me personally, and I'll stick it up on a website and post an URL in the FAQ. It ought to be available for the benefit of cPanel users who might be able to use it, even if we're not going to use any of it in Mailman itself.
They may be honoring the letter of the license,
And then again, they may not be. Checking the source will help to figure that out.
Cheers, Steve
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
stephen@xemacs.org wrote:
If you actually do have the right to do so, yes, please.
I do, AFAIK. Mailman is GPL'd and I have legitimate root access on that system so I have access to the source code. AIUI, the GPL doesn't permit them to restrict what I do with the source that I get. So it's tough titties for cPanel if they don't like me sharing it with the rest of the world. :)
The diff is rather large and messy. The source dir on cpanel seems to include a build dir with the mailman bin/ utils in it along with some of the stuff from contrib and cron. There are also various remnants of the build process (config.status, Makefiles, etc) strewn about -- perhaps to discourage anyone from using the source easily. :)
In the interests of completeness, I've not excluded any of that from the diff, so it's rather large (~ 7MB unzipped)! This source came from /usr/local/cpanel/src/3rdparty/gpl/mailman-2.1.7 on a cpanel system.
The diff:
http://pobox.com/~tmz/mailman-2.1.7-cpanel.diff.bz2 (1.7MB)
Let me know if you want any other info from the cpanel system and I'll do my best to get it for you.
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
The only reason we still have elections in this country is to see if the pollsters were right. -- Ed Rollins
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQFDBAEBAgAtBQJE+DzoJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzjE3UH/1BNRTGyeU64R5WvwW/AVYuRoJL67IfPru5D dqPlhHSDHYTs/Q9P8wsPWsyrTOlNEVe5XJaxJ/FlROt0tbxKa0s9wHENqcw2DUU9 S+jVga8wkiG4dfyAxMOdg867rSfZf/P6DNXEl+41vmkb+ALFAjvecpoXj+Ulozvl tF8RLQkiMosRdqPhkv5I/xlItRjCuX6cdEA6IjA9TwBd8pj7qHqloiS5X+ox5Prm c1arJjWRX5luoE6C/fbb/hhw8ALME+8mpW6RsQqIkdMODJCWJTZYUfHz3tiVu2kg az+5jHGGR/o0Jrp9oWtm1RKd+rXUzmhr2OKxOw9Cz8D0RaDdmlE= =NppS -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Todd Zullinger writes:
You have to actually receive a distribution to have GPL rights. Merely having access to somebody else's copy is not enough. The system owner can indeed tell you what uses you are and are not allowed, just as a cashier has legitimate access to the contents of the cash register, but isn't allowed to just share out the change to anybody who comes along.
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
stephen@xemacs.org wrote:
You have to actually receive a distribution to have GPL rights. Merely having access to somebody else's copy is not enough.
The system owner most certainly allows me to access and use the source that he was provided as part of the cPanel installation. If you have reason to believe that there are other factors which would prohibit the system owner from sharing that source code, feel free to point those out. But of course, I've already posted the diff and don't plan to retract it. ;)
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Politicians are interested in people. Not that this is always a virtue. Fleas are interested in dogs. -- P.J. O'Rourke
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQFDBAEBAgAtBQJE+FMlJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzjbCgH/2N/i67u6OictBLbibABrwsZZcwOCPN8rZ7g CSAZS7vEhIQnjBNozjqkqggZAYWvkkXgYGeUtpQiCjWdL71yxJd+F9zux8EMlRO8 GCbn/R6S1U5l7Dnb0wd3scAgjA4Q1a+t/TTVXO/kNtwEhvQJs57cu3NeyJkpqaxR oSTyTN7IA2i/yB9rnopWI878TomZribIWw7X+W38mj53mr7b5Etnkt1R/FzlUl/W IGMUiFuPMJqjfTT5IYJz/9//5zdYbiM1B09VtTEoNf2dKUkOluiGJH0prbKqPWjt Xox67v/lLI/RJV4qFXszWMl/Fb44AYsLCbyRrOvUoTW4T7mVGfE= =qrX6 -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
stephen@xemacs.org wrote:
I'm just concerned that sharing might not be the intention of the system owner.
No problem. Sharing this source code is perfectly fine with the system owner. I know him well enough to know that implicitly.
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Drugs may lead to nowhere, but at least it's the scenic route.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQFDBAEBAgAtBQJE+FugJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzjxlkIAJxVfKZeENu/xCfhHcTV2dXWjOhN3hSLey0o 640Pn32IFVKSa74uB9RRYZ+Ifouv/Of0lL9f+DUVJb41omrnYCg6PGeZT/0AeYx0 aC97UJQkv+p23aZ4VuPfKBQPNStrC4vn3XmgYSFsenAU1vjXRW7/SuDQEDtgktU5 V51V6S6VQQPmprg2nPWiP9do6Kdrq+JTKEetri4ZoyxnXlinZP0C5EUZ3OWNWl38 yT7sojobP0PppWZ3OYU1cYzaYPwQXAweRh3M6fIFnwxqPTAPl9y/o1pT0BC8uhjq 3CDDupqjlruhRrOtTn7uZNlVwVVTOjLmXoF0lauCZLOVrXjeDwQ= =NhZz -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Todd Zullinger wrote:
The build directory is created by configure and contains 'configured' versions of the scripts.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 8/31/06 4:09 PM, "Brad Knowles" <brad@stop.mail-abuse.org> wrote:
I continue to think that "un-vetted" is closer. GPL doesn't give Mailman's copyright holders control over what changes are made, which "unapproved" or "unauthorized" would seem to imply.
I think.
--John
![](https://secure.gravatar.com/avatar/358f04f5f993066da926a0892f774c83.jpg?s=120&d=mm&r=g)
Bretton Vine sent the message below at 14:22 8/30/2006:
The TO: and CC: headers of an e-mail are both treated as explicit destinations and should not trigger this behavior. The only type of implicit destination I am aware of is an address in a BCC: field.
I just tested this on one of my lists. I sent an e-mail with the To: set to one of my other e-mail addresses and the CC: set to my list address. I did this with the require_explicit_destination setting both on and off. I did not receive an error, the post was not held. I had require_explicit_destination set to on for all of my lists in the past but I have changed that since we implemented some aggressive anti-spam measures on our server. It worked as advertised when I had it enabled.
My personal opinion on this situation is that the user was not telling you the truth. Whether that was from forgetting or outright deception I have no way to know. The only other thing I can think of is that some other type of error resulted in the message being held.
I will admit I am not overly familiar with the internals of mailman as I am just a (somewhat) knowledgeable user and not an active developer. However, I still cannot see how this could happen and cannot duplicate the behavior as I understand it.
As I am not one of the developers and I was not using mailman when that feature was implemented, I cannot answer if there was any community input into that decision. However, the decision that was made seems quite logical to me.
I repeat, no criticism intended, I just need to be able to give a complete answer and am anticipating the questions I'll be asked. :-)
I don't really understand why this is a concern, to me it just doesn't make a difference. It is very easy to override the implicit destination behavior if it is not appropriate for your lists. I honestly think somebody is making a mountain of a mole hill here.
As I said above, this should never have happened as far as I can tell. I'm sure one of the developers with more knowledge about this will correct me if I am wrong.
If you set the default non-member action to Hold, no posts from non-members will get through unless a moderator explicitly approves them. If your spam filtering is good enough to keep examining the held messages from being an excessive work load, then by all means, disable the setting.
The only potential problem I see, and it is a difficult one to solve, is with e-mails with forged sender addresses that match list member addresses. These e-mails will get through to the list.
Since the use of the BCC: with a forged FROM: address is a common spammer tactic, it will result in some unwanted noise. How often that would happen is anyone's guess. How tolerable the problem would be is also anyone's guess.
Just be aware that such things do tend to increase list-member dissatisfaction and the more volatile/vocal members may comment upon such things on the list. This was one of the driving forces behind my lists migrating from an older version of majordomo to mailman earlier this year.
That is one person's opinion, I would be willing to bet that most people who run members-only lists would disagree.
I don't quite agree, but it seems to be a point of view without a strong counter-argument.
And this is why this setting exists as an option.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Dragon said the following on 2006/08/31 12:24 AM:
I can confirm my own testing duplicates this.
My personal opinion on this situation is that the user was not telling you the truth.
I share this opinion, but have no evidence to support it other than mild speculation. Co-incidence I had two instances in a given 24 hour period, where one fitted the model perfectly and worked as indicated, while the other defies explanation yet requires it.
I cannot answer if there was any community input into that decision. However, the decision that was made seems quite logical to me.
Ditto, however if you'll bear with me here, I'm not a developer either (sysadmin) and answers that satisfy technical people don't always satisfy decision-makers (however familiar they are with the concepts/technology).
What I'm gathering from the development of this discussion is that my initial suspicions were correct and it's possibly just a case of someone trying to shift blame. After all, they would have received immediate notification of the moderator approval and if urgency was of the essence could easily have followed up with me direct.
When you're in the business of providing list-based communication to paying clients (who understand the usefulness of lists, and are mostly technically inclined etc) it doesn't help to give a BOFH answer. At least by discussing the issue I have references from other people who've tested the situation and together we contribute to the pool of user knowledge :-)
I have an excellent boss, who requires exact, simple answers to often difficult questions. I don't think I'm alone here. And one should never mistake ignorance for idiocy, something an /awful/ lot of open source developers (well zealots perhaps) are inclined to do (imho), whether it be through elitism or sheer exasperation at the types of questions asked by a user base. i.e. RTFM or RTFAQ default reply.
If I'm being pedantic (yes again!) it's because these things do come up, and where I was schooled you weren't a fool for asking a question, no matter how simple or obvious the answer might be to anyone else.
I'm hoping for more information so I can prepare a summary of the situation. Clearly there are two potential answers:
- We don't have the full information from the original poster
- We don't have the full information in terms of documentation or skills
If you're in the business of 'making things happen' via mailing lists, and over 10 years experience in doing so which of the above is more relevant? (it helps to have good mentors who can see the impact of collaborative principles and not just the ideologies available to implement them -- the textbook answer is seldom the one they want to hear)
Exim ACLs seem to be taking care of that nicely. Roughly 1 in 10 000 failure over last 6 months. And the system has that sort of load on a daily basis.
In my experience (to date) list-member dissatisfaction is related more to unwanted posts from fellow list-members who don't know how to reply-to-sender when a list is set to reply-to-list; and those who don't know how to reply-to-list when it is set to reply-to-sender and less about unwanted posts.
i.e. user-education/user-error related more than spam concerns
(For epic flame wars feel free to join some .ZA lists where people are more than happy to bicker for days over netiquette and internet ideology <chuckles>)
That is one person's opinion, I would be willing to bet that most people who run members-only lists would disagree.
That one person's opinion is the foremost expert on Internet policy on the African continent. And yes, we've been running lists for quite a long time already. And that person pays the bills, and only funds what produces results so their opinion counts considerably if I want to remain employed <grin>
When someone asks "but why is this enabled by default" an answer of "but you can turn it off" is seldom sufficient in satisfying their curiosity.
Some people want options and flashing lights and a machine that goes "ping" while others actually want to know why the lights flash in the first place. I work for the latter <wink>
Believe it or not, their is an intelligent user base out there and if you're not a coder, it helps to at least ask (or pass on) the questions you hear from it. But I digress ...
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"To dare to live alone is the rarest courage; since there are many who had rather meet their bitterest enemy in the field, than their own hearts in their closet." - Charles Caleb Colton
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 1:21 AM +0200 2006-08-31, Bretton Vine wrote:
I would say that both situations are possible, and maybe even likely.
Well, I've been using Unix for over twenty-two years, a professional Unix system administrator for almost seventeen, specializing in DNS and Internet e-mail administration for over a decade, including a two-year stint as the Sr. Internet Mail System Administrator for America Online, and one of the first people to do some serious large-scale anti-spam work that was contributed back to the user community (with the approval of my boss). I've been involved in administering large mailing lists for over a decade, and I've assisted with some of the largest mailing lists on the planet (as of the time of their creation).
I've been a technical reviewer of a couple of O'Reilly books, technical reviewer of a couple more technical Internet-related books from other publishers, I've written an article on the Network Time Protocol that will be published in the October issue of _;login:_ magazine (published by the USENIX Association), a six-part series on spam-fighting "best practices" that will soon be published on the LOPSA.org website, and I've got a book of my own that I'm working on writing.
And with all that, I know I'm not the most experienced or talented person on the Mailman project. I'm just a mail operations guy who helps to run the python.org mail system and co-moderator of some of the mailing lists on python.org -- including this one.
So, does my opinion count?
The person in question wouldn't happen to be named András Salamon (see <http://www.dns.net/andras/>), would he? If so, András and I go way back (back to the time when he was originally working to create the DNS Resources Directory), and if he's got any questions he can come straight to me.
Last I had heard, András had left the day-to-day management work down in .ZA, and had gone on to establish one of the leading venture capital firms down there, but I haven't checked in with him lately, so maybe he's off doing something else now.
When someone asks "but why is this enabled by default" an answer of "but you can turn it off" is seldom sufficient in satisfying their curiosity.
The answer is that it's turned on by default because that's the safest choice. Period. End of discussion.
Now, the option does exist so that you can decide to change that setting, if you prefer. But you're not going to change the default that's built-in to the code as it is shipped. And I'm pretty sure you're not going to get a different answer from the core developers.
Yeah, but sometimes the answer is that the light flashes because it was programmed to flash, and there is no deeper answer to be had. People who ask those kinds of questions need to understand when they've been given the complete answer, even if it is less enlightening than they wanted.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/08/31 02:37 AM:
So, does my opinion count?
Of course it does. Credentials are useful, experience more so. Heck next week we have a whole bunch of experts here to give opinions to the industry (shameless plug for iweek)
The person in question wouldn't happen to be named András Salamon
Nope, but he's a key figure on the network I look after and has been involved in it various ways since inception and to this day.
Oxford atm.
The answer is that it's turned on by default because that's the safest choice. Period. End of discussion.
Fair enough. At least there is something to reference now instead of "I don't know, give me 5 mins with google and I'll get back to you" <grin>
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"For a smart material to be able to send out a more complex signal it needs to be nonlinear. If you hit a tuning fork twice as hard it will ring twice as loud but still at the same frequency. That's a linear response. If you hit a person twice as hard they're unlikely just to shout twice as loud. That property lets you learn more about the person than the tuning fork." - Neil Gershenfeld, When Things Start to Think, 1999
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bretton Vine wrote:
I repeat, no criticism intended, I just need to be able to give a complete answer and am anticipating the questions I'll be asked. :-)
I think most of what I'm going to say here has been said by Dragon and Brad already, but just for emphasis...
The major reason for require_explicit_destination is it helps filter spam on an 'open' list (generic_nonmember_action = accept) and on a closed list where the spammer might spoof a list member's address as sender because much spam does not address the recipient directly.
The default setting in Defaults.py can be overridden by any site that whishes the default for new lists to be No.
Whatever is chosen as the Defaults.py value for any particular list setting, some will wish it had been the other way. It is simply not possible to create "out of the box" defaults that will satisfy everyone. That is why a site can change the defaults for itself and individual lists can be changed to be different from the site defaults.
What you are saying above is not correct.
require_explicit_destination means only that the list posting address or one of the acceptable_aliases addresses must appear somewhere in a To: or Cc: header of the post as received by Mailman. The presence of a Cc: header or Bcc: header (which Mailman probably never sees). has nothing to do with it.
Thus of your 3 examples above, if 'list' is the list posting address that Mailman expects to see, only the 3rd example will be held for implicit destination because in this and only this case, Mailman doesn't see the list address as a recipient of the post.
Further,
To: someone Cc: list
will also be accepted.
When the message is held for 'implicit destination', view the headers of the message in the admindb interface and/or forward the post to yourself, and you will see that what I'm saying is correct.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Mark Sapiro said the following on 2006/08/31 01:22 AM:
I understand, thanks for the additional clarification :-) (Lot easier to illustrate a point when a number of people say the same/similar thing)
Aaaah, but that's the crux of the situation. I have read the documentation. I have searched the FAQs. I have asked the list and I keep getting the same answer: there is no obvious reason a {TO:listname,CC:thirdparty} post should result in the "message has implicit destination" error.
However I am expected to provide one.
I have an example of {TO:list1;BCC:list2} resulting in the administrative error so I know it works as it should. But I also have an example where I get that error without the different inputs and yet can't reproduce the error myself.
If I'm being a bit anal it's because I need to be quite sure of myself if I'm going to suggest the problem exists between keyboard and chair ...
Yup, tested and it works. Except I have a message from a list-member that matches that setup and still resulted in the error indicated. Odd? I think so. Does the error lie with the system, no, I'm pretty sure it doesn't going by the useful input I've had. Thanks again :-)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"You have not converted a man because you have silenced him." - John Morley
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bretton Vine wrote:
I understand and I sympathize. In another life, I worked at a college. The main user liason/applications programmer person for the student information system used to refer the these kinds of things as being caused by a 'poltergeist'. It drove me crazy, because I knew there was a real explaination for every glitch, and I wanted to find it, but I think the 'poltergeist' explaination worked for many of the users.
Do you have an actual message? Where did this message come from? Is this a message captured from the admindb interface, received from the list after approval or sent to you after the fact? Or are you just talking about the message without actually having it in hand?
Here's my advice for the next time if there is one. Examine the actual message headers in the admindb interface and in addition to approving the message, check the box to forward a copy to yourself. It would have been really handy if you had done this with the original message, but of course you had no way to know you would want/need this information.
Also, you've probably already set require_explicit_destination off for the list so there won't be a next time.
Hint - look at max_num_recipients before you get burned on that one too.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Mark Sapiro said the following on 2006/08/31 02:55 AM:
Yeah, the "radial flux in the atmospheric pressure" excuse may work for most users but not for my boss :-)
Do you have an actual message?
Yes
Where did this message come from?
A list-member, cc'd to non-list member (subsequently subbed)
Is this a message captured from the admindb interface, received from the list after approval or sent to you after the fact?
Actually you've hit the nail on the head here. I didn't look at the headers in the mailman interface and the headers of the received message only reveal normal From: To: Cc: etc
Or are you just talking about the message without actually having it in hand?
No I have it, I just didn't know what to look for when the error occurred, and approved it. Given that this was a time-critical notification for local infrastructure, and concerns were only voiced long after alternatives had been explored the blame has to fall somewhere.
(which is ok if there is a *good* explanation and solution at hand)
Exactly. Hopefully others will learn from this experience and it won't be a wasted exercise and merely a brief annoyance.
Also, you've probably already set require_explicit_destination off for the list so there won't be a next time.
Pretty much
Hint - look at max_num_recipients before you get burned on that one too.
Set to 5 (default)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"I had a linguistics professor who said that it's man's ability to use language that makes him the dominant species on the planet. That may be. But I think there's one other thing that separates us from animals. We aren't afraid of vacuum cleaners." - Jef
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bretton Vine wrote:
It occurred to me that if the list has archives, the raw message as sent to the list members will be in archives/private/listname.mbox/listname.mbox. This message will not be the exact message received by Mailman and held for implict destination because Mailman does manipulate headers a bit, but as long as the list is not fully personalized, the To: and Cc: headers should be intact.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 2:22 AM +0200 2006-08-31, Bretton Vine wrote:
There is no answer we can give you. The software does not work the way you have described.
The only two possible answers I can think of are:
The user was intentionally lying to you.
The user did not fully understand the question and the situation, and therefore gave you an inaccurate response.
Therefore, if you want to be able to give a complete and correct technical response, you must gather more information from the user, including incontrovertible proof of exactly what they sent to your server so that you can duplicate the described behaviour.
Until you can duplicate the described behaviour based on the information you have from the user, it will be impossible for you to give a complete and correct technical answer.
If I'm being a bit anal it's because I need to be quite sure of myself if I'm going to suggest the problem exists between keyboard and chair ...
Just ask for more information. You don't need to imply anything, just tell them that you're trying to test all the possible paths through the code, to understand how the system could have responded in the way it did.
If they are unwilling or unable to help, then you should tell your management that you do not believe it is possible for the code to behave in the manner described but that you do not have enough information to prove that, and then it's up to them to make a decision.
Making real-life decisions with incomplete information is something that human beings do every moment of their waking life, it shouldn't be too hard for them to do it again in this case.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/1c4a4096ba25b08fbf1a8cb1c4bf9fcb.jpg?s=120&d=mm&r=g)
On 8/30/06 8:07 PM, Brad Knowles at brad@stop.mail-abuse.org wrote:
Just a thought and I may be all wet here but is it possible the user is sending to an alias for the listname, possibly an alternative hostname for the machine, that mailman doesn't know is an acceptable alternative and therefore considers it to an implicit destination?
For example, mailman expects lists.example.com but mail is sent to list@foo.example.com which is the same host.
-- Larry Stone lstone19@stonejongleux.com http://www.stonejongleux.com/
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Larry Stone wrote:
Mailman expects to find listname@host_name (host_name is the list attribute) or something that matches acceptable_aliases in a To:, Cc:, Resent-To: or Resent-Cc: header in the message.
For historical reasons Mailman also accepts listname@anydomain, so the difference between list@lists.example.com, list@foo.example.com or list@example.com wouldn't be the explaination here.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Dragon said the following on 2006/08/30 10:03 PM:
Oops... forgot to send my reply to the list too. Sorry about that Bretton, I did not mean for you to receive it twice.
Not a problem, and thanks for the reply ;-) However it doesn't solve my problem of determining why a TO: list@vdomain; CC: third@party resulted in "message has implicit destination error". I can't seem to reproduce the incident myself for some reason.
(no criticism intended to developers, but I have to ask:) Was this requested by users; were users involved in this decision; or was it a case of developers deciding for users what they thought was best given the environment of email/lists from the developer perspective?
I repeat, no criticism intended, I just need to be able to give a complete answer and am anticipating the questions I'll be asked. :-)
Personally, I believe it to be a reasonable default.
I don't disagree. However the documentation is clear that BCC'ing a list will result in administrative oversight (if setting is'on'). But not very clear as to why a TO:list;CC:3rd-party would result in the same by a post from a list member who is authorised to post.
In terms of the logs, the error is /exactly/ the same whether it's
TO: list CC: someone
or
TO: list BCC: someone
or
TO: someone BCC: list
Yes, I'm being pedantic -- but an explanation of the principle doesn't always answer what happens in practice. I know answers can't be sucked out of thin-air, but perhaps this has come up before? (or not and I need to look deeper)
We've found relatively little spam making it to any lists as it is. By just how much a margin will turning the setting off impact on posts from non-members reaching the list is non-member posting is already disallowed? Is it just theoretical, negligible or will have it have major impact?
In terms of our logs, the "message has implicit destination" occurs maybe once for every 50 or so "post by non-member/unapproved-address to member-only list" so if you look at it from a higher level service provider approach it doesn't seem like it would make much of a difference, and therefore is unnecessary to leave the setting enabled.
I don't quite agree, but it seems to be a point of view without a strong counter-argument.
regards
| Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
Every portrait that is painted with feeling is a portrait of the artist, not of the sitter. - Oscar Wilde
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 11:22 PM +0200 2006-08-30, Bretton Vine wrote:
The developers *are* the original users. They wrote Mailman for themselves and their own needs, and were willing to share that with others. What has happened since is that a variety of other features have been added over time, based on their own requirements and desires as well as input from others.
But all of the core developers are also heavy users of Mailman, both on python.org and on other mailing list servers -- including some of the largest known Mailman-hosted mailing lists servers.
I'm not convinced that your case is what you think it is. I have not heard enough details about the problem to know for sure.
The answer is "it depends".
This week, changing this setting may make no visible difference, but next week you might get bombarded with spam being sent to the list which does not include the list address as a named recipient in either the "To:" or "Cc:" headers.
Every site is different. Every list is different. Every month is different. Every week is different. Every day is different.
Pick out which of these different issues apply to your different situation, and then figure out which different answer applies to your case.
At some sites, you're not going to see this kind of spam very often. At other sites, you see boatloads of it on an hourly basis. It all depends.
We prefer to have this option default to "on", because it is safer that way, and people can always choose to set their choice to be more permissive. The reverse would be much worse for sites that have these kinds of problems, especially if those sites tend to be administered by less Mailman-savvy personnel, since a great deal of damage could be done in a very short period of time.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/08/31 12:09 AM: <snip useful comments>
(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.
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.
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.
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. This is a frustration I personally have as I'm often the person documenting things smarter people do on the network I look after.
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*.
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.
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 $$$)
Ok, granted, no-one's specifically 'selling' anything here. That doesn't negate responsibility for the default options though. It's insufficient to give people an "option" to change something. Some need to know why/how/what.
</wipes froth from mouth>
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".
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? Now apply the same basic principle to a web-based list-administrative interface. Throw in some experienced majordomo users for good measure, along with some people that are unaware of anything other than a browser called IE exists and give them full control of their own lists. Seriously, what's the worst that can happen -- someone learning from mistakes, something we do naturally?
In my experience, presenting the end user with all the options early on (with clear explanations) leads to a more rapid and confident learning curve than giving them permanent training wheels and no explanation. Takes a bit more effort, but the rewards are well worth it. But at the same time you have a market that wants a one-size-fits-all solution. Catch-22.
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? If not, why is the default set to "on"?
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
regards
| Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
aibohphobia, n., The fear of palindromes.
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 2:07 AM +0200 2006-08-31, Bretton Vine wrote:
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.
The methods of open source development pre-date Richard Stallman and his GNU followers. Some of us remember those days.
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.
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.
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.
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".
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 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?
I don't see how this is any different from what we're already doing today.
Please elaborate.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/08/31 03:01 AM:
The methods of open source development pre-date Richard Stallman and his GNU followers. Some of us remember those days.
And quite a few are still around to teach us who take the net etc for granted which is a good thing.
So far my experience has been wonderful with the product, good and bad with the documentation, and rather difficult in terms of user-error, namely mine.
Then that's the answer I have. My job is to keep things running, and if they break fix them fast or provide reasons/solutions. However it's hard sometimes defending a choice in platform when some or all of the following are insufficient:
- because everyone's using it
- because it's free [speech or beer]
- I don't know! It worked yesterday
No offence intended, but this is a rather closed-off point of view. It's completely valid yes, but leaves no room for organic growth. A view of "we have enough users, we do this for our own reasons, we know we can improve this and that but there's no urgency" actually shrinks a community in the end.
I'm not saying there's an obligation to use or prove your software (and time/effort interacting with the user base) just that any project can become bigger than the sum of its parts and developers should be aware of that.
I'll leave the philosophical analysis of that aside for now.
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.
Doesn't seem quite efficient to have people duplicating labour for no reason other than stubbornness.
Nor are we specifically a commercial list environment. The nature of our income-generating business is such that lists have proven to be extremely useful over the years and form the basis of in-house communication and communication for the participating associations we manage.
However my point is that Mailman will still be used commercially. Which creates expectations. You can't manage the expectations of others so it's a difficult road to travel.
I understand. But look at it from a point-of-view of say a prior majordomo installation where the safe defaults are different defaults. Look at it from the point-of-view of someone who knows the prior defaults and may be confused by the change. Yes the new defaults are safe, but why? (obvious answer: changing environment and needs)
Aye, and balance a hierarchy of dependencies between organisations and information dispersal (and pace thereof) and legal accountability becomes a concern.
Change may be necessary, but not everyone wants it. In my current situation we've discovered that the need to disperse information quickly and accurately is more important than the possibility of a flood of spam. I sold my employer a migration path in a particular direction and this filtered down to clients but has had some unintended consequences along the way.
I think a fair analogy would be (as if speaking to a client):
I'm sorry, we can't assist you as normal, we're busy upgrading our systems and did not anticipate this issue, please call again soon
Obviously there are situations you just can't do this in.
For the lowest common denominator? None. Even the simplest possible web interface would be too complex for them.
Boy, that's harsh. ISOC-ZA had an open-day last year, setup some computers and an internet link in an under-privileged area. Invited the local community (young and old) to come see what the Internet was all about. Many using computers for the first time. And they practically had to pull the people away from PCs so others could get a chance too.
Didn't take long for someone presented with a browser and search engine to get the swing of things. (And yet the irony is that there are middle-class workers who have been using computers at work for some years who still 'just don't get it')
I've knocked out our system quite a few times (by accident or oversight) and yes there's often hell to pay and some sleepless nights -- but we've yet to find a user who takes the system down because they have a web-interface or email-interface to the system so they can manage their own list.
It's like the parent who refuses to let their child near a pc in case they break it (but secretly because they wouldn't know how to fix it if they did) compared to the parent who gives a child an old keyboard to bang away on in the early years. The latter somehow never seem to actually break things beyond the point of being able to fix them. The former end up as luddites.
See Subject: (devils advocate) ;-)
In alternate reality one, the safe defaults are automatically decided for the user. In alternate reality two they are suggested but the user has to enable them. Which reality informs the user more?
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
Tyler: Hitting bottom is not a weekend retreat, it's not a damn seminar. Stop trying to control everything and just let go. Let go! - Fight Club
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 4:56 AM +0200 2006-08-31, Bretton Vine wrote:
So far my experience has been wonderful with the product, good and bad with the documentation, and rather difficult in terms of user-error, namely mine.
I am of the opinion that all software sucks, but some sucks less than others. IMO, Mailman sucks less than any other MLM I've seen.
Of course, amongst most open-source projects, documentation is a serious weak spot. Those who are developers write code, not documentation. And if they do write documentation, you frequently wish that they hadn't. Those who are operational-types (like me) don't write code, and usually don't write documentation, and if they do write documentation you frequently wish that they hadn't.
The good documentation writers rarely seem to cross paths with any open source project I've seen.
It's a known serious weak spot within the Mailman project, and we'd love to be able to resolve this issue, but that means we need to get some people onboard that are good at writing documentation. Any suggestions you may have in this area would be gratefully accepted.
I can't say where things will end up. I don't think I can even make much of a guess. I can tell you that we're getting a large enough influx of users that it is difficult for us to keep up without doing anything more to actively draw in more users.
In that kind of high-growth environment, it's hard to justify doing anything that would actively draw in more users and would likely hamper other development efforts that we consider to be more important than maximum growth of the userbase in the shortest possible time.
My preference would be to have a more sustainable growth pattern over a longer period of time, based on a higher quality product that we've been able to develop and field, then let the growth take care of itself.
But that's just my personal view, and is not necessarily shared by anyone else.
I think that the developers are well aware of this issue, especially since multiple other groups have taken the Mailman code and made unapproved changes to it, and then fielded that to their users -- but without providing adequate support for their modified versions and thus leaving us holding the bag they created.
Sometimes you can't stop them, no matter what you do. IMO, when you discover that the kind of situation you've got with a particular person, then the best thing to do is to recommend that they go ahead and do whatever they want on their own systems and to report back to you regarding their success.
Otherwise, you're mud wrestling with a pig, which only gets you dirty and sweaty and annoys the pig.
However my point is that Mailman will still be used commercially.
True. Like it or not, there's nothing we can do to stop them.
Which
creates expectations.
Also true.
You can't manage the expectations of others so it's a
difficult road to travel.
Indeed. We do the best we can through what documentation is available (including the FAQ), but there's little we can do beyond that.
Majordomo is different from Mailman, and I would not be surprised if certain features were present in one package and not in the other, or if certain defaults were set one way in one package and the opposite way in the other.
But if people don't understand that different software is frequently different, I'm not sure that there's much I can do to help them, and I'm not sure that there's much that anyone else can do to help them, either.
Do you want a complete and total moron to have his finger on the nuclear button, and capable of blowing up the entire planet many times over?
Oh, waitaminnit, we already have that situation....
The number of things that a list moderator or list admin can do through the web are limited, and the danger is reduced. But if/when we make all site administration functions available through the web, the danger will be quite a bit higher.
Even list admins can subscribe a bunch of other addresses to their lists, and create loops with their subscriptions. It only takes one loop that causes every message coming in to the list to be duplicated and then re-sent back to the same list (and duplicated again, ad nauseum), to bring down the whole system.
If you've got a large system (e.g., something that can generate millions of mail messages per day), it's easy enough to make a mistake that could take down a lot of other systems around the world and not just your own.
These are powerful tools we're talking about here, and it's easy to do things to wind up accidentally shooting yourself in the foot -- or maybe accidentally shooting your neighbor in the head.
With powerful tools, you also need powerful safeguards.
Right, but precisely who is our "user", or perhaps I should say "customer"?
I submit that *our* customer is the site admin, and this is precisely the kind of thing we offer to them. The customer(s) of the site admin would be the list admin(s), and the customer(s) of the list admin(s) would be the list moderator(s) and the list recipient(s).
So, it's up to the site admin(s) to look through the defaults we've provided to them and decide which ones they want to change for their customers, and it's up to the list admin(s) to look through the defaults they're given by the site admin(s) and decide which ones that they want to change for their customers.
I submit we've done our job for our customers, and it's up to them to do their job for their customers, and so on.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/08/31 05:36 AM:
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
Sounds like a good plan. In a world of build-it, grow-it, sell-it in 24 hours it's useful to have the voice of reason prevail.
Yes, my initial experience (relating to virtual domains on a single installation) using third party patches took a lot of time to reach the conclusion that was already summarised as:
"it's possible, but better to have multiple separate installations instead"
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. In turn I had to settle on an installation method, write my own HOWTO specific to our system and then tweak it over time to remove what was unnecessary and add in what I missed conceptually first time around. A useful exercise, but time-consuming.
Indeed. We do the best we can through what documentation is available (including the FAQ), but there's little we can do beyond that.
I disagree, I've found this discussion quite informative and sure others have as well. What I mean is you can 'do more' than just code or write up some documentation. Merely engaging the user base one-on-one adds something more to the experience of learning.
After all, for most people it's more like this:
user <--> support desk <--> engineer <--> developer
with lots of fancy but useless communication methods in between. I think most people are eager to learn, just afraid of looking stupid by raising a hand for a question (especially a frequently asked one)
I know. And embarrassing when you're the last to find out <chuckles> I understand Mailman is superior to Majordomo in this respect, or is this configuration dependant?
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)
Thanks, you've just illustrated a point I often try to make. Ultimately the proverbial 'you' drives the computer. You're responsible for what it does and doesn't do. Mistakes happen, but so too does random knowledge ... you know like you pick up a new short-cut you didn't know by watching someone else do it fist.
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 :-)
I submit we've done our job for our customers, and it's up to them to do their job for their customers, and so on.
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. 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)
I can point my users to documentation and URLs but I can't make them read :-)
| Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
If you're not failing every now and again, it's a sign you're not doing anything very innovative. - W. Allen
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 9:06 AM +0200 2006-08-31, Bretton Vine wrote:
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.
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, 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.
No "good dead" ever goes unpunished. ;)
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.
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@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/>.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Brad Knowles writes:
IMHO, it's the *same way to go.* AIUI (I seem to be missing a post or two) Mailman accepted the mail, Mailman did not drop it on the floor, Mailman *could* have sent it---but the Postel Principle doesn't imply that it should have done so. We have good reason (by default, which default doesn't apply to Bretton's shop, it seems) to believe that that post should be looked at (strictly ;-) by a human before sending.
Steve
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 8/30/06 6:01 PM, "Brad Knowles" <brad@stop.mail-abuse.org> wrote:
The methods of open source development pre-date Richard Stallman and his GNU followers. Some of us remember those days.
For example, SHARE from the 1950s. At one point, MITs 704 (or 709 or 7090 by then) data center posted a notice which, paraphrased from memory, said "We have SOS (SHARE Operating System) and will attempt to run it on request. We won't be responsible for failures of SOS."
By the way, the explanation of the option in the administrator interface seems reasonably clear to me (as a Mailman "customer" not developer). However, I doubt that there are many new list administrators who look there when setting up a list.
And, unfortunately, were I preparing a list of options for a "You really ought to look at these options and check that they are set appropriately" paragraph, I probably wouldn't include this one. There are so many which are more important for such a thing.
--John
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
John W. Baxter said the following on 2006/08/31 06:58 PM:
Perhaps a list of "you /really/ should set these settings to X" would be useful to people short on time :-) Of course you could just bundle the product that way in the first place but where's the fun in that?
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"I think that's how Chicago got started. A bunch of people in New York said, 'Gee, I'm enjoying the crime and the poverty, but it just isn't cold enough. Let's go west.'" - Richard Jeni
![](https://secure.gravatar.com/avatar/358f04f5f993066da926a0892f774c83.jpg?s=120&d=mm&r=g)
Bretton Vine sent the message below at 10:08 8/31/2006:
That is what the Defaults.py file is for.
The defaults as shipped were chosen by the developers. We should assume that they were chosen for good, logical reasons that apply to the majority of installations.
But if you don't like the defaults or have a reason to choose a different setting, you can change them at your own risk either through configuring each list or by overriding the setting in mm_cfg.py
Open source projects are never going to have documentation to the standard you want. Unless you or somebody else is willing to take on that large project, continuing to harp on the subject is only going to serve to annoy people.
The fact that this software is made available to the community free of charge is a gift to the community. The fact that people like Brad and Mark and others are willing to expend large amounts of their time responding to queries here should be taken as what it is, another gift to the community. I think they have gone above and beyond the call of duty in this discussion and I am amazed at the restraint they have shown.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Dragon said the following on 2006/08/31 07:44 PM:
I'm not criticising, and I'm more than willing to put in some effort. What useful settings apply? The default 'legacy' antispam measures are merely an example (for example).
That's the trouble with email - tone is lost, along with intention ;-)
I think they have gone above and beyond the call of duty in this discussion and I am amazed at the restraint they have shown.
The teacher learns more from the student than the student learns from the teacher. It would be wise not to forget that. <big grin>
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"It is important that students bring a certain ragamuffin, barefoot, irreverence to their studies; they are not here to worship what is known, but to question it." - Jacob Chanowski
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Dragon said the following on 2006/08/31 07:44 PM:
(on a more serious note)
I view it differently. I have had great feedback and I highly doubt either of the parties mentioned viewed a response as a "restraining, difficult exercise". I /really/ use lists to their full advantage and with some in particular have never felt my input or response was an exercise in patience or restraint. It's a labour of love. You do it because it's what you do.
That's not to say I don't appreciate a response (some time after the fact) with another avenue to explore (thanks Mark) but compare the difference between "you're harping on about nothing" to "have you tried this?". The latter (in hindsight) is blindingly obvious -- and yet no-one else let their sub-conscious ponder the problem a while longer.
Lists are communities. And community isn't about 'gifts' from the elders or sticking to sensible rules. It's about invigorating the elders so they feel like children in a toy-store again. (and no I'm not being ageist or condescending or merely rebellious here)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"This is a test designed to provoke an emotional response: The water supply IS tainted"
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 8:25 PM +0200 2006-08-31, Bretton Vine wrote:
Maybe I'm getting better at this process than I have been in the past, but I most definitely held back quite a bit in my responses. I did allow myself to get a bit testy, but that's about it.
It took me a while to realize that you were more playing devil's advocate (on behalf of your boss) as opposed to actually believing in some of the things you were saying.
And yes, a great deal of context is lost in e-mail. Remember that about 90% of all human communication is not verbalized, and of the remainder about 90% is more in the tone of how you respond as opposed to the actual words that are chosen. Pretty much all of that is lost in e-mail, leaving only the words -- and about 1% of what would normally be conveyed in a natural human conversation.
A lot of my responses were defensive in nature, responding to the way I felt that our entire community was being attacked, and I took that pretty personally.
As such, there really wasn't any time available for me to ponder the question in any more depth. If I'd had that time, I might have been able to find a better way to convey what it was I was trying to get across.
Now, I may have managed to moderate my response quite a bit, but that doesn't change the fundamental nature of the situation as it occurred.
It should be about enabling people to contribute something and allow them to feel useful, in whatever way that they find that they are best able to do. We don't always succeed in that goal, however. But as we work towards that goal, we should find that when everyone helps everyone else, we all benefit from the combined strength, and the result is much greater than the sum of its parts.
The big problem comes when a new person comes in, or a new situation occurs, and one or more members of the community feels like they are being attacked, and how they respond. The result can either strengthen the enlarged community, or be extremely destructive.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/f861849565e5eb3313e869f4f3fb77d0.jpg?s=120&d=mm&r=g)
--On August 31, 2006 7:08:22 PM +0200 Bretton Vine <bretton@hivemind.net> wrote:
To which I reply:
Could we maybe leave this poor dead horse to rest in peace?
Apparently, many of the posters to this list believe (with some justification, imho) that it should take explicit action to undo safe defaults, rather than requiring explicit action to set safe values. You disagree. You've made that abundantly clear. Fine. We believe that you disagree.
But based on my (rather more than I care to contemplate) years in this business, I think you're wrong.
-- Steve Burling <mailto:srb@umich.edu> University of Michigan, ICPSR Voice: +1 734 615.3779 330 Packard Street FAX: +1 734 647.8700 Ann Arbor, MI 48104-2910
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Steve Burling said the following on 2006/08/31 07:55 PM:
Could we maybe leave this poor dead horse to rest in peace?
Only if I get a last word in edgewise :-)
Then you've misunderstood me. I don't disagree, and since turning the setting off have seen an immediate *and* significant increase in the amount of spam getting to open lists which answers a question I raised earlier.
The point I was illustrating is that if you have to justify the rationale behind a default setting to a third-party-decision-maker -- what is the most appropriate and concise response?
But based on my (rather more than I care to contemplate) years in this business, I think you're wrong.
I may well be. However I dispute the reasoning that things are done a certain way 'just because that's the way they're done'. This thread has resulted in far more knowledge than I need convey on to my boss/clients, but it has been immensely useful too. Both in terms of my learning, and proposing alternate perspectives. Just because I present a point-of-view doesn't mean I agree with it. Nor does it invalidate it.
I've heard arguments from developers critical of third parties modifying the software in a particular way and then failing to support it accordingly. I've heard arguments that the developers know what's best. I've questioned whether these approaches are based on developer-need, user-input or pure reasoning. I don't believe I've done anything a curious individual could be faulted for, nor do I see any evidence that people willing to take a moment's pause for a reasoned response reacting uncomfortably or being unwilling to share their experience or philosophy-of-approach.
In closing, I needed a simple answer. I couldn't find one myself, so I asked. In return I learned far more than I requested, and developed an immediate respect for those who understood where I was coming from. In time perhaps those who endured irritation will understand. :-)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"All progress is based upon a universal innate desire on the part of every organism to live beyond its income." — Samuel Butler (1835-1902),British writer.
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 8:44 PM +0200 2006-08-31, Bretton Vine wrote:
This is the key point that was not coming across to me, at least not until much later in the exchange. Speaking only for myself, I seriously misunderstood what you were asking and why, which greatly colored my responses.
I'm still not certain that we've given you the best answer to this question, but I'm hoping that you'll be able to synthesize something that you will then be able to contribute back to the community, and we will hopefully be able to avoid these kinds of problems in the future -- at least with respect to this one particular issue.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/09/01 01:24 AM:
My apologies, I could have been clearer. I did try and fork the thread with the inclusion of (devils advocate!) in the subject line.
I may not have what I was looking specifically, but I do have a clearer of how to approach things in future.
I've had to edit context significantly for various reasons (brevity being one) but it comes down this. We've had a solution in place for 10 years that just works but doesn't offer us the functionality we need or clients want any more. I've been on mailman run lists for ~6 years and found the setup to be more useful and when the time came for a new server had to make a number of decisions based on skills available, difference in volumes of legitimate mail and spam today (compared to setup of ageing server from 96) and new things to be learnt using a different OS and architecture.
A mistake appears to be the perception (prior to installation and initial use phase) that Mailman was Majordomo with a web-gui and archives. It's not. It's a different product and approach entirely. This realisation is hammered home in the implementation of Mailman -- but not easily visible when researching alternative solutions to the previous way we did things.
Such a mistaken perception is echoed both up to management and down to users in selling the solution. You get approval, go ahead and implement and then there this "oops" moment and realisation you didn't have all the knowledge to begin with, and sold management and users a solution you just couldn't (at the time) anticipate certain problems with. So it's your head on the block and you either have to wing it or come up with an explanation that satisfies both users and management without too much trouble in the process.
Just as an example, some list-owners have pending administrative request queues numbering in the hundreds already. No amount of prodding or pushing or assisting helps them just to complete a small and easy daily task. Feedback is "my prior list didn't bother me with stuff" or "Oh, I used to just ignore that stuff anyway". Horse --> water situation.
Additionally in terms of the historical setup, things with majordomo were already highly customised to our needs, and when I came in I assumed/took-for-granted this was the default (old system has even worse documentation than anything else I've seen <chuckles>) and also assumed thing would be echoed in the Mailman setup. My mistake, but during the "ask around for suggestions" phase most of the feedback I got was Mailman orientated, like the move is just a casual change in clothes. It's not :-)
Now despite my mixed positive/negative reactions to documentation and feedback from the list, and growing growing appreciation of why certain things were done a certain way, neither users or management have the time to sift through the same volume of information to reach a satisfactory conclusion. Instead you get a very offensive response due to resistance to change, or new variables.
You see the following doesn't cut it in that situation:
- but we can change it
- we can modify the source if we need to
- that's the way the developers chose to do it
- the documentation was lacking
In an environment where someone has to take responsibility for a situation, even if it's not their fault as such, providing the best answer to users or management can go two ways. Shift the blame, or fix the problem -- even if it means undoing the best practices suggested and letting users/management realise for themselves why it's a bad idea. But in some environments you just can't afford to do this.
So far I've discovered that yes, most of the safe defaults are the best desired functionality. And that on a Debian/Exim setup it's best to install from source, and if using virtual domains to install a separate installation of mailman per domain. The additional overhead on the box isn't that much for ~20 domains. It might be for more than that though. I've also found the documentation to be scattered but where there is info that can be referenced, it's generally pretty good.
Once we have a stable system that meets the needs of users and management I'll be happy to share the setup of how we've done it in our particular way along with some rationale behind the different decisions based both on what I've learnt on this list, and from user/management feedback.
Obviously every installation is in a different environment, and as has been mentioned Mailman isn't a one-stop-solution-for-all-situations solution. There is also a lot of public misconception about Mailman in general -- things you only realise when you're actually implementing it on a box or run into trouble. I doubt anyone is to blame for this -- there are simply too many variables involved.
I'd suggest to anyone looking at Mailman as a solution search the docs/FAQ/list-archives, *and* join the list and ask a few questions before actually implementing. It's a lot easier to anticipate certain things that way. :-)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"Gods are fragile things; they may be killed by a whiff of science or a dose of common sense." - Chapman Cohen
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bretton Vine wrote:
FYI, in case you missed it, beginning with 2.1.6 there is a max_days_to_hold list setting and the corresponding DEFAULT_MAX_DAYS_TO_HOLD mm_cfg.py setting.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 8/30/06 6:01 PM, "Brad Knowles" <brad@stop.mail-abuse.org> wrote:
"unapproved" may be a bit strong. Perhaps "un-vetted" would be closer?
But the idea is right on. When I see a thread about running Mailman on CPanel or Plesk or Mac OS X Server, I ignore the thread (and I run Mac OS X on my desktop).
I just recently wrote a FAQ entry on this subject -- see FAQ 1.32.
Quite nicely done!
--John
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 10:06 AM -0700 2006-08-31, John W. Baxter quoted "Brad Knowles" <brad@stop.mail-abuse.org>:
Actually, I think either "unapproved" or "unauthorized" are the most appropriate terms. After all, the code is released under the GPL, and anyone who is making modifications to that code and then making their modified version available to their customers (or otherwise benefiting from those modifications) are supposed to contribute the source to their changes back to the community. But CPanel has not done this, neither has Plesk, nor Apple.
Now, in a way, Apple gives back to the project more than they probably realize, but that's not the same thing.
So, while we don't make that big a deal of this issue, I think I'm actually being reasonably lenient on these companies.
I just recently wrote a FAQ entry on this subject -- see FAQ 1.32.
Quite nicely done!
Thanks!
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Brad Knowles writes:
Excuse me? The GPL *explicitly* approves and authorizes (not to mention implicitly encourages) modification and redistribution without conditions other than providing source. That's exactly what "license" means.
Has anybody at Mailman asked CPanel, Plesk, or Apple for source and been refused? Or one of their customers, and been refused because they were under NDA? If we haven't asked, how can we bitch?
C'mon, Brad, you know what the GPL actually says. They're supposed to give the source to their customers. That's all it says.
It is quite possible to write a license that says you *must* give your modifications back to some entity. You could argue that the reason the GPL doesn't do that is that "the community" is the only appropriate beneficiary, but it's impossible to legally define "the community" in a satisfactory way. But I don't think that's what Richard Stallman has in mind when he declares licenses containing such clauses "unfree". Nor do they satisfy the DFSG or the OSD. I believe it's that the whole idea of demanding payment of any kind is unfree.
So, while we don't make that big a deal of this issue, I think I'm actually being reasonably lenient on these companies.
I would say we're not trying to accomplish by jawbone what we refuse to put in the license. And that's very important to me. It's one of the things I like best about this community. Of course you're certainly welcome to consider that you're being lenient; I'm simply explaining that I very much appreciate your lenience, but I rationalize it differently.
Once again, has anybody simply *asked* these companies for their code, and maybe for some contribution of labor toward integrating it? If so, how recently? I realize that we probably "dislike" some of their changes, so they wouldn't make it into the mainline (at least not as defaults), but it could exist on more or less deprecated branches. Surely there are CPanel- or Plesk-using ISPs who would like to have Mailman project support available to their customers; we should be able to get moral, if not financial, support from them.
Sincere regards, Steve
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 2:32 PM +0900 2006-09-01, <stephen@xemacs.org> wrote:
Right, and they haven't provided the source.
I don't know about CPanel or Plesk, but I'd be willing to bet that they would not be willing to provide the source code to their changes to anyone, although a knowledgeable person could extract the source code differences by comparing what is shipped by the commercial vendor against our code, although it might take some work to figure out which version of our code they should be comparing against.
I'm pretty sure that I know what the answer would be from Apple. You see, the primary problem is that the Server Group is totally and completely unresponsive to their own high-paying Platinum-account customers (i.e., major Universities and businesses with thousands or tens of thousands of machines), and likewise completely unresponsive even to internal people at Apple who are working in other groups.
You'd have to ask Barry as to whether or not he has actually contacted these groups to ask them to contribute their code changes back to the community, or if anyone has gone to the FSF lawyers to have them send a letter requesting that the company in question honor their obligations under the GPL.
I just don't have the answers to the questions you're asking me.
Moreover, I don't think that it's reasonable for you to respond to me in this manner. What have I ever done to you? When have I ever said anything that would lead you to believe that I would have the kinds of answers you require to these extremely loaded questions you're asking?
If you want to get into a diatribe about licensing, please be aware that I'm a BSD guy, and I've found myself surrounded by a bunch of GPL types, so license-wise I've tended to say pretty quiet.
But if you want to argue the finer points of the GPL with someone, my response is going to be that none of this would be a problem if they'd just use a BSD-like license instead and then be done with it.
As such, I'm not going to be your foil for your GPL holy war, and if you want that then you would be better off looking elsewhere.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 1:39 AM -0500 2006-09-01, Brad Knowles wrote:
Sorry, I meant "... stay pretty quiet". That was a bad typo to have in such a place.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/09/01 08:39 AM:
Note, the issues raised are not unique to Mailman or other popular GPL products. There is an undercurrent of concern over how Ubuntu is building on Dedian but not necessarily contributing back, and developer dissatisfaction at the Debian level moving to the more trendy and dynamic Ubuntu front.
The GPL approach has obviously been useful (and popular) but I find many 'just solve the problem' type individuals seem to favour the BSD approach. Kind of "you're welcome to use and modify, just don't blame us for any consequences", whereas with the GPL it's more about a zealous popular uprising against corporate overlords.
I don't think there is any obligation for someone who changes the source of a GPL product to give the changes back to the original developers, but there might be a case of 'good manners' at play in that it is polite to do so. I'm sure developers welcome input even if they choose not to include it in the primary code distribution.
One can however approach someone who has modified the source and request the modified source but there may be trouble getting a diff version of the modifications made and reasons why.
However it's probably a case of motivation. Developers would need to be motivated to chase one of the organisations mentioned and it would be time-consuming and require effort when they might prefer to be coding. Obviously a gap here for a champion from within the user base to pursue the matter further.
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"To teach a man how he may learn to grow independently, and for himself, is perhaps the greatest service that one man can do another." - Benjamin Jowett
![](https://secure.gravatar.com/avatar/358f04f5f993066da926a0892f774c83.jpg?s=120&d=mm&r=g)
Bretton Vine did speak thusly:
Disclaimer: I am not a licensed attorney and this is not to be construed as legal advice.
Have you actually read the GPL?
http://www.gnu.org/licenses/gpl.txt
There is such an obligation explicitly defined in it within section 3 that states that source code of any derivative work MUST be provided either as part of the actual distribution of the work or upon request to ANY third party that requests it. Section 2 also plays heavily into this situation.
Thus by either passively ignoring or actively refusing requests for source, Apple, Plesk and CPanel are in direct violation of the GPL.
And while we are on the subject of the GPL, sections 11 and 12 basically state that there is absolutely no warranty for the fitness or suitability of a GPL program and that your use of a program under the license is entirely at your own risk.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Dragon said the following on 2006/09/01 05:29 PM:
Have you actually read the GPL? http://www.gnu.org/licenses/gpl.txt
yes plus variations ;-)
Yes, but that's not what I said. I said there was no obligation to send changes back to original developers, but that it was polite to do so. Obviously, if the original developers ask for the changes then yes, but if they've failed to do so there is no obligation. (The feedback appears to indicate that they have asked however)
In fact I can take GPL code, modify it and use it internally without either the original developers or any third party knowing I've done so. I'm under zero obligation to inform anyone of my actions or changes. If however I start distributing the changed code it must be done so under the same licence, and upon request I must make the source available.
There is no obligation for me to indicate what I changed from an original code base (code or docs) only an obligation for me to provide the source *on request*.
Manners imply shipping the compiled product with source, but it's not necessary or necessarily a rule followed by everyone.
Thus by either passively ignoring or actively refusing requests for source, Apple, Plesk and CPanel are in direct violation of the GPL.
Ok, then any person is welcome to contact those organisations and request the source. If they fail to provide it you can take the matter up with the relevant people at the FSF.
http://www.gnu.org/licenses/gpl-violation.html
(well technically only copyright holders can do so)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"A new study shows that licking the sweat off a frog can cure depression. The down side is, the minute you stop licking, the frog gets depressed again." - Jay Leno
![](https://secure.gravatar.com/avatar/358f04f5f993066da926a0892f774c83.jpg?s=120&d=mm&r=g)
Bretton Vine sent the message below at 08:47 AM 9/1/2006:
No, it was not exactly what you said but it could be interpreted in such a way.
Yes, you can. But that is also not applicable to this situation because Plesk and Cpanel and Apple have all taken the mailman code, applied changes and redistributed them.
And that is the crux of the issue because as I understand it, such requests have been made and rebuffed or ignored.
Nor is it required under the GPL. The GPL only requires that it be made available and does not specify the exact mechanism of how this must be done.
Thus by either passively ignoring or actively refusing requests for source, Apple, Plesk and CPanel are in direct violation of the GPL.
If the link Mark posted earlier with Apple's source code does indeed have their version (which looks likely due to a different version number on it), then I retract my statement about Apple. By providing the source on the web, they have adhered to both the letter and the spirit of the GPL.
Very true.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Dragon writes:
Bretton Vine did speak thusly:
Bretton's right. Satisfying *any* of 3a, 3b, or 3c means you are in full compliance with section 3. If you distribute source as part of every distribution you make, you are under no legal obligation to give source to any third party. That includes upstream.
BTW, I was quite surprised at the way you construe 3b; I've always assumed "any third party" was a reference to recipients of non-source distributions under 3c. But IANAL and I'm often enough wrong---you're probably right.
Thus by either passively ignoring or actively refusing requests for source, Apple, Plesk and CPanel are in direct violation of the GPL.
cPanel seems not to be. Definitely not at the installation Todd Zullinger has access to. I would not be surprised if both Apple and Plesk are similarly in full technical compliance. Especially Apple, since Steve Jobs has not had very good luck with trying to violate the GPL in the past. :-)
Steve
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Brad Knowles writes:
I just don't have the answers to the questions you're asking me.
That's fine.
Moreover, I don't think that it's reasonable for you to respond to me in this manner. What have I ever done to you?
Since you ask, lots of nice things. I've certainly benefited from your contributions to these lists and the FAQ. Thank you!
I'm not sure what you mean by "manner", but the reason I responded is that I got triggered by the juxtaposition of "us vs. them" language with "GPL". I agree that there's a justification for a feeling of "us vs. them" between Mailman and the companies mentioned, but in my experience the GPL normally contributes to such antagonism, and I've never seen the GPL help alleviate it. So I want the GPL out of the discussion (unless the companies are in violation of their license, which seems possible---that's why I asked for evidence).
When have I ever said anything that would lead you to believe that I would have the kinds of answers you require
Aren't you the guy who was there when the Postel Principle was coined? <wink> You're right, I should ask Barry, but Barry's not here right now that I can see, and you usually do have answers, good answers.
to these extremely loaded questions you're asking?
What's loaded about the questions? True, my phrasing assumed that you probably knew the answers to the questions, but I didn't mean to imply any obligation for you to know them.
Your post asks for more than the GPL does. I agree that it would be good if these companies would participate actively in the community. But I'm more confused than ever why you cited the GPL in support of that, since you write:
As such, I'm not going to be your foil for your GPL holy war, and if you want that then you would be better off looking elsewhere.
All I want w.r.t. the GPL is that downstream do what it explicitly demands, since that is the license Mailman uses.
And maybe Mailman should consider asking for source code from these companies, to improve support for not a few users.
Steve
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 9:30 PM +0900 2006-09-01, <stephen@xemacs.org> wrote:
I'm not really citing the GPL, at least not per se. I know what the GPL actually requires, but as far as I'm concerned any changes that are made without being approved by Barry or filtered back into the community would qualify as "unapproved".
All I want w.r.t. the GPL is that downstream do what it explicitly demands, since that is the license Mailman uses.
If they were willing to do that, I'd be reasonably happy.
And maybe Mailman should consider asking for source code from these companies, to improve support for not a few users.
That's a good idea, but that's another issue for Barry.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Brad Knowles wrote:
FWIW, I only this week discovered that Apple has Mailman source code on it's web site.
I found the following quote somewhat ironic -
Apple uses software created by the Open Source community, such as the HTML rendering engine for Safari, and returns its enhancements to the community.
(<http://www.apple.com/opensource/>)
Anyway, if you go to <http://www.opensource.apple.com/darwinsource/> and follow any of the "Mac OS X 10.3 Darwin 7.0" or later "source" links you will find links to Mailman source. I don't know whether this is Apple modified source or just our source. I haven't had time to investigate this.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 8:42 AM -0700 2006-09-01, Mark Sapiro wrote:
Looking at <http://www.opensource.apple.com/darwinsource/10.3/mailman-105/mailman/NEWS>, it appears that they started with Mailman 2.1.2, but I am not yet seeing any Apple-modified stuff.
Looking at <http://www.opensource.apple.com/darwinsource/10.4.7.ppc/mailman-117/mailman/...>, it looks like they got up to version 2.1.5, but again I'm still trying to figure out what parts may have been modified by Apple.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brad Knowles wrote:
I grabbed the source from:
http://www.opensource.apple.com/darwinsource/tarballs/other/mailman-117.tar.gz
which is linked from (among other places):
http://www.opensource.apple.com/darwinsource/10.4.7.x86/
The mailman sources are in the tarball in the mailman dir. The diff to that is here:
http://pobox.com/~tmz/mailman-apple.diff.bz2
There are other Apple specific things in the tarball, Makefile, init script, etc, which are worth checking out to see how they package Mailman and how that may affect those coming here for some help with those Apple packages.
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Conscience is what hurts when everything else feels so good.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQFDBAEBAgAtBQJE+GtFJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzjghkH/3uFSEtRrSyM9XAg5Vl/47lLqlWPcTCX0MLe C3Si8ZLnYzj/7nDZD+ehmohpMM9p1I6+vl+W3RiG/fKrPfAEV1IAoqEbVBQEJytG sT1F4BOEu1eEpfKuYN4sWdJaCUwgi27uvo2o2jk1BcILxc6SUyEMHXQBhlrML0Kw uz934fTS9UvYYuOrqKPfp5L6euSSRDJNYijIzCVUUw809FYw/yzr8/SuEdXN1e6m dxKjOLoufaPe1fYm1AZf5GsUduZhP7FOwnxj9DGR4OJ+3d0MJ6sE8j551MGjaR58 znov5QwIqoqV+yUV996z1RmXUPeWyR1VGVUVMBpb/JXAYZOVjwI= =QTnP -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
stephen@xemacs.org wrote:
I asked cPanel a few years ago. I got the run-around and they closed the support ticket 2 or 3 times without providing any source or diffs. Only after persisting did they send me a link to a half-assed diff that I know didn't match all that they changed.
I've since had the displeasure of working on a cPanel hosted system and there is a source directory for mailman. If anyone's really curious, I'll diff it against whatever the official source release they're claiming it is.
They may be honoring the letter of the license, but they deserve the shit they get here for abusing the spirit of it so badly. If I made changes to Mailman that caused a regular stream of frequently asked questions I'd fix the problems or get involved in helping answer them just so I could sleep at night. cPanel doesn't do that and they are charging folks good money to package up free software. That leaves a bad taste in *my* mouth, and I'm not even a significant contributor to Mailman.
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
The more laws, the less justice. -- Marcus Tullius Cicero "De Officiis", 44 B.C.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQFDBAEBAgAtBQJE+CMLJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzj8hIH/2wPr7N2DRiWA/domQpwv9uylQea2a8ilIec A29uZeuZyy0vIQiV6qGvrhUdkE/9e/GQBG09+vias5I2U7g9H/4zer9G+esNDm1c 1S6Wag/KzT75/wDIamqb0PyXDuiwq1yAye5cCdPRnKaPWtjLJzTsycPgXmXmDx4v OGF1+NNuOXh1jvA+XQXl7sLTh/bSewgu0QdZIeMYnd+WNoC27eWWin3g6n7CjVNi j87yBzu5pHbW+Maj4EL0opShnmelTpNyst+iqRtwAU5KEq5sC6U7DE5rX9s7xSWM RYK8KCqq4rK7IyplyMtnXgVbhGQydi3VkRDm3eF1+RguZbIl9bc= =E9Gk -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Todd Zullinger writes:
If you actually do have the right to do so, yes, please. If nobody else wants it, feel free to send it to me personally, and I'll stick it up on a website and post an URL in the FAQ. It ought to be available for the benefit of cPanel users who might be able to use it, even if we're not going to use any of it in Mailman itself.
They may be honoring the letter of the license,
And then again, they may not be. Checking the source will help to figure that out.
Cheers, Steve
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
stephen@xemacs.org wrote:
If you actually do have the right to do so, yes, please.
I do, AFAIK. Mailman is GPL'd and I have legitimate root access on that system so I have access to the source code. AIUI, the GPL doesn't permit them to restrict what I do with the source that I get. So it's tough titties for cPanel if they don't like me sharing it with the rest of the world. :)
The diff is rather large and messy. The source dir on cpanel seems to include a build dir with the mailman bin/ utils in it along with some of the stuff from contrib and cron. There are also various remnants of the build process (config.status, Makefiles, etc) strewn about -- perhaps to discourage anyone from using the source easily. :)
In the interests of completeness, I've not excluded any of that from the diff, so it's rather large (~ 7MB unzipped)! This source came from /usr/local/cpanel/src/3rdparty/gpl/mailman-2.1.7 on a cpanel system.
The diff:
http://pobox.com/~tmz/mailman-2.1.7-cpanel.diff.bz2 (1.7MB)
Let me know if you want any other info from the cpanel system and I'll do my best to get it for you.
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
The only reason we still have elections in this country is to see if the pollsters were right. -- Ed Rollins
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQFDBAEBAgAtBQJE+DzoJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzjE3UH/1BNRTGyeU64R5WvwW/AVYuRoJL67IfPru5D dqPlhHSDHYTs/Q9P8wsPWsyrTOlNEVe5XJaxJ/FlROt0tbxKa0s9wHENqcw2DUU9 S+jVga8wkiG4dfyAxMOdg867rSfZf/P6DNXEl+41vmkb+ALFAjvecpoXj+Ulozvl tF8RLQkiMosRdqPhkv5I/xlItRjCuX6cdEA6IjA9TwBd8pj7qHqloiS5X+ox5Prm c1arJjWRX5luoE6C/fbb/hhw8ALME+8mpW6RsQqIkdMODJCWJTZYUfHz3tiVu2kg az+5jHGGR/o0Jrp9oWtm1RKd+rXUzmhr2OKxOw9Cz8D0RaDdmlE= =NppS -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Todd Zullinger writes:
You have to actually receive a distribution to have GPL rights. Merely having access to somebody else's copy is not enough. The system owner can indeed tell you what uses you are and are not allowed, just as a cashier has legitimate access to the contents of the cash register, but isn't allowed to just share out the change to anybody who comes along.
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
stephen@xemacs.org wrote:
You have to actually receive a distribution to have GPL rights. Merely having access to somebody else's copy is not enough.
The system owner most certainly allows me to access and use the source that he was provided as part of the cPanel installation. If you have reason to believe that there are other factors which would prohibit the system owner from sharing that source code, feel free to point those out. But of course, I've already posted the diff and don't plan to retract it. ;)
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Politicians are interested in people. Not that this is always a virtue. Fleas are interested in dogs. -- P.J. O'Rourke
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQFDBAEBAgAtBQJE+FMlJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzjbCgH/2N/i67u6OictBLbibABrwsZZcwOCPN8rZ7g CSAZS7vEhIQnjBNozjqkqggZAYWvkkXgYGeUtpQiCjWdL71yxJd+F9zux8EMlRO8 GCbn/R6S1U5l7Dnb0wd3scAgjA4Q1a+t/TTVXO/kNtwEhvQJs57cu3NeyJkpqaxR oSTyTN7IA2i/yB9rnopWI878TomZribIWw7X+W38mj53mr7b5Etnkt1R/FzlUl/W IGMUiFuPMJqjfTT5IYJz/9//5zdYbiM1B09VtTEoNf2dKUkOluiGJH0prbKqPWjt Xox67v/lLI/RJV4qFXszWMl/Fb44AYsLCbyRrOvUoTW4T7mVGfE= =qrX6 -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
stephen@xemacs.org wrote:
I'm just concerned that sharing might not be the intention of the system owner.
No problem. Sharing this source code is perfectly fine with the system owner. I know him well enough to know that implicitly.
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Drugs may lead to nowhere, but at least it's the scenic route.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQFDBAEBAgAtBQJE+FugJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzjxlkIAJxVfKZeENu/xCfhHcTV2dXWjOhN3hSLey0o 640Pn32IFVKSa74uB9RRYZ+Ifouv/Of0lL9f+DUVJb41omrnYCg6PGeZT/0AeYx0 aC97UJQkv+p23aZ4VuPfKBQPNStrC4vn3XmgYSFsenAU1vjXRW7/SuDQEDtgktU5 V51V6S6VQQPmprg2nPWiP9do6Kdrq+JTKEetri4ZoyxnXlinZP0C5EUZ3OWNWl38 yT7sojobP0PppWZ3OYU1cYzaYPwQXAweRh3M6fIFnwxqPTAPl9y/o1pT0BC8uhjq 3CDDupqjlruhRrOtTn7uZNlVwVVTOjLmXoF0lauCZLOVrXjeDwQ= =NhZz -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Todd Zullinger wrote:
The build directory is created by configure and contains 'configured' versions of the scripts.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 8/31/06 4:09 PM, "Brad Knowles" <brad@stop.mail-abuse.org> wrote:
I continue to think that "un-vetted" is closer. GPL doesn't give Mailman's copyright holders control over what changes are made, which "unapproved" or "unauthorized" would seem to imply.
I think.
--John
![](https://secure.gravatar.com/avatar/358f04f5f993066da926a0892f774c83.jpg?s=120&d=mm&r=g)
Bretton Vine sent the message below at 14:22 8/30/2006:
The TO: and CC: headers of an e-mail are both treated as explicit destinations and should not trigger this behavior. The only type of implicit destination I am aware of is an address in a BCC: field.
I just tested this on one of my lists. I sent an e-mail with the To: set to one of my other e-mail addresses and the CC: set to my list address. I did this with the require_explicit_destination setting both on and off. I did not receive an error, the post was not held. I had require_explicit_destination set to on for all of my lists in the past but I have changed that since we implemented some aggressive anti-spam measures on our server. It worked as advertised when I had it enabled.
My personal opinion on this situation is that the user was not telling you the truth. Whether that was from forgetting or outright deception I have no way to know. The only other thing I can think of is that some other type of error resulted in the message being held.
I will admit I am not overly familiar with the internals of mailman as I am just a (somewhat) knowledgeable user and not an active developer. However, I still cannot see how this could happen and cannot duplicate the behavior as I understand it.
As I am not one of the developers and I was not using mailman when that feature was implemented, I cannot answer if there was any community input into that decision. However, the decision that was made seems quite logical to me.
I repeat, no criticism intended, I just need to be able to give a complete answer and am anticipating the questions I'll be asked. :-)
I don't really understand why this is a concern, to me it just doesn't make a difference. It is very easy to override the implicit destination behavior if it is not appropriate for your lists. I honestly think somebody is making a mountain of a mole hill here.
As I said above, this should never have happened as far as I can tell. I'm sure one of the developers with more knowledge about this will correct me if I am wrong.
If you set the default non-member action to Hold, no posts from non-members will get through unless a moderator explicitly approves them. If your spam filtering is good enough to keep examining the held messages from being an excessive work load, then by all means, disable the setting.
The only potential problem I see, and it is a difficult one to solve, is with e-mails with forged sender addresses that match list member addresses. These e-mails will get through to the list.
Since the use of the BCC: with a forged FROM: address is a common spammer tactic, it will result in some unwanted noise. How often that would happen is anyone's guess. How tolerable the problem would be is also anyone's guess.
Just be aware that such things do tend to increase list-member dissatisfaction and the more volatile/vocal members may comment upon such things on the list. This was one of the driving forces behind my lists migrating from an older version of majordomo to mailman earlier this year.
That is one person's opinion, I would be willing to bet that most people who run members-only lists would disagree.
I don't quite agree, but it seems to be a point of view without a strong counter-argument.
And this is why this setting exists as an option.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Dragon said the following on 2006/08/31 12:24 AM:
I can confirm my own testing duplicates this.
My personal opinion on this situation is that the user was not telling you the truth.
I share this opinion, but have no evidence to support it other than mild speculation. Co-incidence I had two instances in a given 24 hour period, where one fitted the model perfectly and worked as indicated, while the other defies explanation yet requires it.
I cannot answer if there was any community input into that decision. However, the decision that was made seems quite logical to me.
Ditto, however if you'll bear with me here, I'm not a developer either (sysadmin) and answers that satisfy technical people don't always satisfy decision-makers (however familiar they are with the concepts/technology).
What I'm gathering from the development of this discussion is that my initial suspicions were correct and it's possibly just a case of someone trying to shift blame. After all, they would have received immediate notification of the moderator approval and if urgency was of the essence could easily have followed up with me direct.
When you're in the business of providing list-based communication to paying clients (who understand the usefulness of lists, and are mostly technically inclined etc) it doesn't help to give a BOFH answer. At least by discussing the issue I have references from other people who've tested the situation and together we contribute to the pool of user knowledge :-)
I have an excellent boss, who requires exact, simple answers to often difficult questions. I don't think I'm alone here. And one should never mistake ignorance for idiocy, something an /awful/ lot of open source developers (well zealots perhaps) are inclined to do (imho), whether it be through elitism or sheer exasperation at the types of questions asked by a user base. i.e. RTFM or RTFAQ default reply.
If I'm being pedantic (yes again!) it's because these things do come up, and where I was schooled you weren't a fool for asking a question, no matter how simple or obvious the answer might be to anyone else.
I'm hoping for more information so I can prepare a summary of the situation. Clearly there are two potential answers:
- We don't have the full information from the original poster
- We don't have the full information in terms of documentation or skills
If you're in the business of 'making things happen' via mailing lists, and over 10 years experience in doing so which of the above is more relevant? (it helps to have good mentors who can see the impact of collaborative principles and not just the ideologies available to implement them -- the textbook answer is seldom the one they want to hear)
Exim ACLs seem to be taking care of that nicely. Roughly 1 in 10 000 failure over last 6 months. And the system has that sort of load on a daily basis.
In my experience (to date) list-member dissatisfaction is related more to unwanted posts from fellow list-members who don't know how to reply-to-sender when a list is set to reply-to-list; and those who don't know how to reply-to-list when it is set to reply-to-sender and less about unwanted posts.
i.e. user-education/user-error related more than spam concerns
(For epic flame wars feel free to join some .ZA lists where people are more than happy to bicker for days over netiquette and internet ideology <chuckles>)
That is one person's opinion, I would be willing to bet that most people who run members-only lists would disagree.
That one person's opinion is the foremost expert on Internet policy on the African continent. And yes, we've been running lists for quite a long time already. And that person pays the bills, and only funds what produces results so their opinion counts considerably if I want to remain employed <grin>
When someone asks "but why is this enabled by default" an answer of "but you can turn it off" is seldom sufficient in satisfying their curiosity.
Some people want options and flashing lights and a machine that goes "ping" while others actually want to know why the lights flash in the first place. I work for the latter <wink>
Believe it or not, their is an intelligent user base out there and if you're not a coder, it helps to at least ask (or pass on) the questions you hear from it. But I digress ...
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"To dare to live alone is the rarest courage; since there are many who had rather meet their bitterest enemy in the field, than their own hearts in their closet." - Charles Caleb Colton
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 1:21 AM +0200 2006-08-31, Bretton Vine wrote:
I would say that both situations are possible, and maybe even likely.
Well, I've been using Unix for over twenty-two years, a professional Unix system administrator for almost seventeen, specializing in DNS and Internet e-mail administration for over a decade, including a two-year stint as the Sr. Internet Mail System Administrator for America Online, and one of the first people to do some serious large-scale anti-spam work that was contributed back to the user community (with the approval of my boss). I've been involved in administering large mailing lists for over a decade, and I've assisted with some of the largest mailing lists on the planet (as of the time of their creation).
I've been a technical reviewer of a couple of O'Reilly books, technical reviewer of a couple more technical Internet-related books from other publishers, I've written an article on the Network Time Protocol that will be published in the October issue of _;login:_ magazine (published by the USENIX Association), a six-part series on spam-fighting "best practices" that will soon be published on the LOPSA.org website, and I've got a book of my own that I'm working on writing.
And with all that, I know I'm not the most experienced or talented person on the Mailman project. I'm just a mail operations guy who helps to run the python.org mail system and co-moderator of some of the mailing lists on python.org -- including this one.
So, does my opinion count?
The person in question wouldn't happen to be named András Salamon (see <http://www.dns.net/andras/>), would he? If so, András and I go way back (back to the time when he was originally working to create the DNS Resources Directory), and if he's got any questions he can come straight to me.
Last I had heard, András had left the day-to-day management work down in .ZA, and had gone on to establish one of the leading venture capital firms down there, but I haven't checked in with him lately, so maybe he's off doing something else now.
When someone asks "but why is this enabled by default" an answer of "but you can turn it off" is seldom sufficient in satisfying their curiosity.
The answer is that it's turned on by default because that's the safest choice. Period. End of discussion.
Now, the option does exist so that you can decide to change that setting, if you prefer. But you're not going to change the default that's built-in to the code as it is shipped. And I'm pretty sure you're not going to get a different answer from the core developers.
Yeah, but sometimes the answer is that the light flashes because it was programmed to flash, and there is no deeper answer to be had. People who ask those kinds of questions need to understand when they've been given the complete answer, even if it is less enlightening than they wanted.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Brad Knowles said the following on 2006/08/31 02:37 AM:
So, does my opinion count?
Of course it does. Credentials are useful, experience more so. Heck next week we have a whole bunch of experts here to give opinions to the industry (shameless plug for iweek)
The person in question wouldn't happen to be named András Salamon
Nope, but he's a key figure on the network I look after and has been involved in it various ways since inception and to this day.
Oxford atm.
The answer is that it's turned on by default because that's the safest choice. Period. End of discussion.
Fair enough. At least there is something to reference now instead of "I don't know, give me 5 mins with google and I'll get back to you" <grin>
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"For a smart material to be able to send out a more complex signal it needs to be nonlinear. If you hit a tuning fork twice as hard it will ring twice as loud but still at the same frequency. That's a linear response. If you hit a person twice as hard they're unlikely just to shout twice as loud. That property lets you learn more about the person than the tuning fork." - Neil Gershenfeld, When Things Start to Think, 1999
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bretton Vine wrote:
I repeat, no criticism intended, I just need to be able to give a complete answer and am anticipating the questions I'll be asked. :-)
I think most of what I'm going to say here has been said by Dragon and Brad already, but just for emphasis...
The major reason for require_explicit_destination is it helps filter spam on an 'open' list (generic_nonmember_action = accept) and on a closed list where the spammer might spoof a list member's address as sender because much spam does not address the recipient directly.
The default setting in Defaults.py can be overridden by any site that whishes the default for new lists to be No.
Whatever is chosen as the Defaults.py value for any particular list setting, some will wish it had been the other way. It is simply not possible to create "out of the box" defaults that will satisfy everyone. That is why a site can change the defaults for itself and individual lists can be changed to be different from the site defaults.
What you are saying above is not correct.
require_explicit_destination means only that the list posting address or one of the acceptable_aliases addresses must appear somewhere in a To: or Cc: header of the post as received by Mailman. The presence of a Cc: header or Bcc: header (which Mailman probably never sees). has nothing to do with it.
Thus of your 3 examples above, if 'list' is the list posting address that Mailman expects to see, only the 3rd example will be held for implicit destination because in this and only this case, Mailman doesn't see the list address as a recipient of the post.
Further,
To: someone Cc: list
will also be accepted.
When the message is held for 'implicit destination', view the headers of the message in the admindb interface and/or forward the post to yourself, and you will see that what I'm saying is correct.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Mark Sapiro said the following on 2006/08/31 01:22 AM:
I understand, thanks for the additional clarification :-) (Lot easier to illustrate a point when a number of people say the same/similar thing)
Aaaah, but that's the crux of the situation. I have read the documentation. I have searched the FAQs. I have asked the list and I keep getting the same answer: there is no obvious reason a {TO:listname,CC:thirdparty} post should result in the "message has implicit destination" error.
However I am expected to provide one.
I have an example of {TO:list1;BCC:list2} resulting in the administrative error so I know it works as it should. But I also have an example where I get that error without the different inputs and yet can't reproduce the error myself.
If I'm being a bit anal it's because I need to be quite sure of myself if I'm going to suggest the problem exists between keyboard and chair ...
Yup, tested and it works. Except I have a message from a list-member that matches that setup and still resulted in the error indicated. Odd? I think so. Does the error lie with the system, no, I'm pretty sure it doesn't going by the useful input I've had. Thanks again :-)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"You have not converted a man because you have silenced him." - John Morley
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bretton Vine wrote:
I understand and I sympathize. In another life, I worked at a college. The main user liason/applications programmer person for the student information system used to refer the these kinds of things as being caused by a 'poltergeist'. It drove me crazy, because I knew there was a real explaination for every glitch, and I wanted to find it, but I think the 'poltergeist' explaination worked for many of the users.
Do you have an actual message? Where did this message come from? Is this a message captured from the admindb interface, received from the list after approval or sent to you after the fact? Or are you just talking about the message without actually having it in hand?
Here's my advice for the next time if there is one. Examine the actual message headers in the admindb interface and in addition to approving the message, check the box to forward a copy to yourself. It would have been really handy if you had done this with the original message, but of course you had no way to know you would want/need this information.
Also, you've probably already set require_explicit_destination off for the list so there won't be a next time.
Hint - look at max_num_recipients before you get burned on that one too.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/76c8f12da5ea861b2a4c33ccb0ae7dd0.jpg?s=120&d=mm&r=g)
Mark Sapiro said the following on 2006/08/31 02:55 AM:
Yeah, the "radial flux in the atmospheric pressure" excuse may work for most users but not for my boss :-)
Do you have an actual message?
Yes
Where did this message come from?
A list-member, cc'd to non-list member (subsequently subbed)
Is this a message captured from the admindb interface, received from the list after approval or sent to you after the fact?
Actually you've hit the nail on the head here. I didn't look at the headers in the mailman interface and the headers of the received message only reveal normal From: To: Cc: etc
Or are you just talking about the message without actually having it in hand?
No I have it, I just didn't know what to look for when the error occurred, and approved it. Given that this was a time-critical notification for local infrastructure, and concerns were only voiced long after alternatives had been explored the blame has to fall somewhere.
(which is ok if there is a *good* explanation and solution at hand)
Exactly. Hopefully others will learn from this experience and it won't be a wasted exercise and merely a brief annoyance.
Also, you've probably already set require_explicit_destination off for the list so there won't be a next time.
Pretty much
Hint - look at max_num_recipients before you get burned on that one too.
Set to 5 (default)
-- | Bretton Vine | 083 633 8475 | bretton@hivemind.net | | GPG: http://bretton.hivemind.net/bretton_vine.asc |
"I had a linguistics professor who said that it's man's ability to use language that makes him the dominant species on the planet. That may be. But I think there's one other thing that separates us from animals. We aren't afraid of vacuum cleaners." - Jef
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bretton Vine wrote:
It occurred to me that if the list has archives, the raw message as sent to the list members will be in archives/private/listname.mbox/listname.mbox. This message will not be the exact message received by Mailman and held for implict destination because Mailman does manipulate headers a bit, but as long as the list is not fully personalized, the To: and Cc: headers should be intact.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 2:22 AM +0200 2006-08-31, Bretton Vine wrote:
There is no answer we can give you. The software does not work the way you have described.
The only two possible answers I can think of are:
The user was intentionally lying to you.
The user did not fully understand the question and the situation, and therefore gave you an inaccurate response.
Therefore, if you want to be able to give a complete and correct technical response, you must gather more information from the user, including incontrovertible proof of exactly what they sent to your server so that you can duplicate the described behaviour.
Until you can duplicate the described behaviour based on the information you have from the user, it will be impossible for you to give a complete and correct technical answer.
If I'm being a bit anal it's because I need to be quite sure of myself if I'm going to suggest the problem exists between keyboard and chair ...
Just ask for more information. You don't need to imply anything, just tell them that you're trying to test all the possible paths through the code, to understand how the system could have responded in the way it did.
If they are unwilling or unable to help, then you should tell your management that you do not believe it is possible for the code to behave in the manner described but that you do not have enough information to prove that, and then it's up to them to make a decision.
Making real-life decisions with incomplete information is something that human beings do every moment of their waking life, it shouldn't be too hard for them to do it again in this case.
-- Brad Knowles, <brad@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/>.
![](https://secure.gravatar.com/avatar/1c4a4096ba25b08fbf1a8cb1c4bf9fcb.jpg?s=120&d=mm&r=g)
On 8/30/06 8:07 PM, Brad Knowles at brad@stop.mail-abuse.org wrote:
Just a thought and I may be all wet here but is it possible the user is sending to an alias for the listname, possibly an alternative hostname for the machine, that mailman doesn't know is an acceptable alternative and therefore considers it to an implicit destination?
For example, mailman expects lists.example.com but mail is sent to list@foo.example.com which is the same host.
-- Larry Stone lstone19@stonejongleux.com http://www.stonejongleux.com/
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Larry Stone wrote:
Mailman expects to find listname@host_name (host_name is the list attribute) or something that matches acceptable_aliases in a To:, Cc:, Resent-To: or Resent-Cc: header in the message.
For historical reasons Mailman also accepts listname@anydomain, so the difference between list@lists.example.com, list@foo.example.com or list@example.com wouldn't be the explaination here.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (9)
-
Brad Knowles
-
Bretton Vine
-
Dragon
-
John W. Baxter
-
Larry Stone
-
Mark Sapiro
-
stephen@xemacs.org
-
Steve Burling
-
Todd Zullinger