On Thu, 16 Dec 2004 19:50:19 -0600 (CST) Winship <[log in to unmask]> said: >With this proposed new scheme, editor trumping review, rather than >review trumping editor, as it has always been in the past, will, it >seems >to me, make hash of this setup, which many lists use: > >* Send= Editor >* Editor= id@address,(LISTNAME) >* Default-Options= REVIEW > >This is used so that postings from new subscribers will be vetted by the >listowner (or editor if different). This configuration, which I call The Kludge, is one of the biggest mistakes I made in LISTSERV's 18 year history. I had so much to do back then, a full-time student in another city a 3-4 hours' train ride away, that I figured this would save me time. Instead of implementing a proper feature to do what people wanted to do, I allowed this kludge to prosper. This unfortunate decision has cost me hundreds and hundreds of hours of time, and thousands for my colleagues in support. The Editor privilege is the third most powerful privilege you can grant in LISTSERV, after list owner and LISTSERV administrator. You are making this enormous grant of rights to your entire constituency. To make this situation viable, you need additional locks and bolts. Every time a lock is changed in LISTSERV, there needs to be a careful review of every possible variant of The Kludge to make sure that security is not compromised. The original purpose of The Kludge was to make LISTSERV forward postings from non-subscribers to a human for review, instead of rejecting them. It worked reasonably well at a time when LISTSERV was so much smaller and only had a small number of security controls. Later, I added features like the REVIEW option to do what The Kludge originally did. But this did not kill The Kludge - people discovered new ways in which to combine these new features with The Kludge to achieve even more subtle behaviour. Although none of these subtle boundary combinations are guaranteed to keep working with new releases, people expect this to be the case anyway. Every time I change something in LISTSERV's posting control, which I avoid like the plague, I end up breaking one or more of the subtle Kludge combinations, and the complaints start coming. Sometimes The Kludge can be repaired, sometimes it can't. Much as I want long-time customers to be happy, the fact is that the total worldwide number of Kludgemasters is somewhere between 50 and 100. There are more people using the basic form of The Kludge because they read it on the net somewhere or copied it from another list, but that one is easy enough to keep alive. The true Kludgemasters are vocal, but few. And yet most feature requests that could impact The Kludge are rejected or delayed until there is a compelling need to change the posting control code, as was the case in 14.3 for the "Confirm,Non-Member" option that gets rid of spam so effectively that I cannot imagine running an open list without that option any more. But let's get back to your list header sample: >* Send= Editor >* Editor= id@address,(LISTNAME) >* Default-Options= REVIEW > >This is used so that postings from new subscribers will be vetted by the >listowner (or editor if different). You don't need "Send= Editor" for that. You can have "Send= Private" and "Editor= human@address". Existing subscribers can post directly unless they have the REVIEW option, in which case they go to the editor. New subscribers get the REVIEW option. There is no Editor vs REVIEW conflict, and you are not granting any privileges to your entire list. A lot of people use The Kludge out of old habit, when there are better and *supported* ways to achieve the same thing. There is no risk that a design change will cause REVIEW to stop working altogether in the normal case of a "Send= Private" list (a bug could do that, but it would get fixed of course). But the order in which the many security controls are examined can change from one version to another, either by accident or for a reason. If you craft a list configuration that says that X is allowed to do something, and that at the same time says that X is not allowed to do it, you are basically tossing a coin. The coin might always fall on the same side for a given version of LISTSERV, but it could flip around when the code is updated. >Why the sudden about face, in violation of precedent? Why, previously, >did you think that it was proper for review to override editor, but now >you think editor should trump review? The answer is simply that I never thought that it was proper for REVIEW to take precedence. When the REVIEW option was added, I did not think of the potential conflict with Editor, and the implementation happened to give REVIEW the upper hand. Unfortunately, this implementation was unable to support the double confirmation process of "Send= Editor,Confirm,Non-Member" and some of the other changes I wanted to make for 14.3. To ensure security with the double confirmation process (which is actually a triple confirmation internally, but for any given configuration, you will only ever see at most two of the three confirmations), I had to change the logic substantially, and the precedence is no longer as before. I think the new precedence makes more sense, and I also think it is a good thing if people who do not need to use The Kludge stop using it, not because The Kludge takes up so much valuable development time, but because, in spite of my best efforts, I have broken The Kludge several times in LISTSERV's history, so far without compromising security, but one day I might make a mistake and open up a security flaw for lists configured to use The Kludge. It is simply safer and more trouble-free to use supported methods to achieve the desired policy. And it is a one-time change, do it now and you won't have to worry about precedence of list header controls again. New customers typically don't use The Kludge because there is almost always a way to do the same thing using supported methods and, being new customers, they weren't list owners in 1987 when The Kludge was invented. Eric