Yes, paritcularly when all that was needed was a trivial change to the list config.
I see this as a sign of the times. The 3rd gen list managers, developed before the rise of the WWW, are slowly being displaced by the 4th gen list managers that provide integrated WWW interfaces to list managment for the list manager, list supscription management to the user, and WWW-accessible archives for everyone.
Both SmartList and Majordomo have add-ons that provide this but the 4G list managers have them as a part of the core.
Quoting "David R. Linn" drl@vuse.vanderbilt.edu:
Yes, paritcularly when all that was needed was a trivial change to the list config.
Since YEARS list members complained about this, sending emails to Stephen and the list without any reaction of a responsible person. Now suddenly someone made a decision without asking the list members.
This list owns the list members not someone at an university who wants to be a big list master!
Such an behaviour is disappointing and doesn't encourage anybody continuing to support SmartList/Procmail.
If the SmartList-Package-Maintainer agree to point to another list server for SmartList we could simply set up one very quickly (with searchable (web) archive ....) running with SL.
I don't like to remember a password to unsubscribe and I don't like such a "list dictatorship"!
Werner
At 10:30 AM -0400 7/28/00, Werner Reisberger is rumored to have typed:
Since YEARS list members complained about this, sending emails to Stephen and the list without any reaction of a responsible person. Now suddenly someone made a decision without asking the list members.
This isn't _exactly_ news, since the procmail mailing list has been running on mailman for months now. It was only a matter of time before the SmartList list migrated as well...I can't help but wonder if the maintainers didn't even notice the SmartList mailing list for a while, since I expected it to migrate long before now.
I say again; the procmail and SmartList maijling lists don't really belong on rwth-aachen.de anyway anymore.
(with searchable (web) archive ....)
(*sigh*) Who needs a searchable Web archive, when there's a searchable archive server? It's a _mailing list,_ for goodness' sake.
I don't like such a "list dictatorship"!
By definition, the list maintainer _is_ a dictator; his list, his rules, so I don't have any major problem with that. (Anyone who runs a successful mailing list as a democracy has no more than three subscribers.) But a mailing list dedicated to a specific piece of software _should_ be controlled (not necessarily served, but controlled) by the same people who control the source to the software. Otherwise, stupid things like this happen. I'm betting the admins aren't even sure what SmartList _is,_ and so what a silly, brain-damaged idea running its support list under mailman really is.
Charlie
On or about Fri, Jul 28, 2000 at 11:03:31AM -0400, Charlie Summers typed:
(with searchable (web) archive ....)
(*sigh*) Who needs a searchable Web archive, when there's a searchable archive server? It's a _mailing list,_ for goodness' sake.
Actually, that's a very significant concern - convergence is all very well, but I've met plenty of web-based "discussion boards", and they're part of the reason why I choose to run mailing lists instead.
I've been giving some thought to writing a web-based administration interface for smartlist. It would be easy enough to do, but with things like mailman around, is there really a demand for it?
I wonder if anyone's analysed the security benefit of the X-Command: header, not because of the password authentication, but simply because so many modern mailers won't let you insert a custom header field...
Quoting Charlie Summers charlie@lofcom.com:
(with searchable (web) archive ....)
(*sigh*) Who needs a searchable Web archive, when there's a
searchable
archive server? It's a _mailing list,_ for goodness' sake.
The search ability of SL isn't in any way user friendly. Only command line freaks likes such a thing. I value an easily searchable mailing list because it frequently prevents to subscribe to a list for one question which has been answered several times.
I don't like such a "list dictatorship"!
By definition, the list maintainer _is_ a dictator; his list, his
rules,
That's true, but in case of the SL list there wasn't any maintainer. Maybe formal but not in practice. I am a list member since many years and I never saw a single message from a list admin. I never saw any admin reply to the numerous complains about spam messages.
Someone even deleted the whole list archive (probably cause there was a disk space shortage) without notifying anybody.
Therefore it's justified to say that this list is owned by the members and the members have to be asked before such decisions which happened now.
Werner
On Fri, 28 Jul 2000, David R. Linn wrote:
I see this as a sign of the times.
Yes, but be wary, though.
I've gone to SmartList from Mailman because it has something Mailman still hasn't figured out yet: stability under heavy load.
Run the current version of Mailman on a list of more than about 20k subscribers, and don't be surprised if you see multiple copies of your messages go out (at least, that's been my experience...) Something to do with file locking issues and a moderately loaded server. I liked Mailman otherwise, and wish them well, but I needed something that I can rely on, so here I am.
It is a shame, but now that tech decisions are being made more by technical managers and less by the actual techs, the 'sexy' software package frequently wins out, regardless of how long its been around, its reputation, or even its performance.
I'm certainly willing to bear with SmartList's 'homely' appearance. It's extensible, stable, and very fast... And eventually, when the community finds the time to put a pretty face on it, it will truly kick ass, and we'll all be ahead of the learning curve... =)
--Rob
On or about Fri, Jul 28, 2000 at 09:17:49AM -0700, Rob Flickenger typed:
I'm certainly willing to bear with SmartList's 'homely' appearance. It's extensible, stable, and very fast... And eventually, when the community finds the time to put a pretty face on it, it will truly kick ass, and we'll all be ahead of the learning curve... =)
OK. What does a web interface for smartlist need?
Considering the "list administration" side first:
The most basic version would simply send appropriately-formatted X-Command: mail to the list-server. That's fairly trivial to get right. But I'm considering the possibilities inherent in a slightly larger CGI, which might be run suid to the list user, which could maniupulate the list data files directly - to check authentication, add/remove users, and so on.
As for the user side, how would you prevent malicious foreign unsubscriptions without a password? The existing "confirm" patch from aks would be helpful, here.
Do we want a mhonarc-like archiving system, given that mhonarc is pretty easy to integrate with smartlist already?
Roger
Roger Burton West [roger@firedrake.org] wrote:
OK. What does a web interface for smartlist need?
Considering the "list administration" side first:
The most basic version would simply send appropriately-formatted X-Command: mail to the list-server. That's fairly trivial to get right. But I'm considering the possibilities inherent in a slightly larger CGI, which might be run suid to the list user, which could maniupulate the list data files directly - to check authentication, add/remove users, and so on.
What I do here for our mailing lists, we have _everyone_ go through our website to manage their mailing lists. (Kind of like the mailman program.) I hacked Smartlist to prevent it from sending subscribe and unsubscribe messages to the user. This way a user will come to our website, subscribe to the list, the cgi script will generate a username/password from the persons contact info, then the cgi script e-mails the user with this info. It also just sends the appropriate X-COMMAND subscribe/unsubscribe to Smartlist. (then it does silly backend Oracle stuff to keep track of the users info.)
This way I can track the people on my mailing list better.
It would be nice if a unified frontend cgi script existed, then my poor attempt to hacking procmail scripts. :) It would be a nice option to say if you want smartlist to send a subscribe e-mail or not.
my 2c, Steve
Roger;
PLEASE understand this is not directed toward you, although I am using your letter as a starting point for my own, since your views seem to be in many cases the majority view of those on the list.
Everyone Else;
At 12:25 PM -0400 7/28/00, Roger Burton West is rumored to have typed:
OK. What does a web interface for smartlist need?
Nothing, IMHO. It is possible that some inept admins might need a web-based system, I suppose, but SmartList doesn't really need one.
The most basic version would simply send appropriately-formatted X-Command: mail to the list-server. That's fairly trivial to get right.
You're right, having written a couple of 'em myself for different (and inept) clients. But it's even _more_ trivial to simply send an X-Command: via email and be done with it. No, really, it's simple. Mind numbingly easy. Why does everyone make it so tough? (I know I keep saying this. But I am _truly_ perplexed - it's as if someone told me that it was difficult-if-not-impossible to tell time on a digital watch...I just can't understand the confusion.)
But I'm considering the possibilities inherent in a slightly larger CGI, which might be run suid to the list user, which could maniupulate the list data files directly - to check authentication, add/remove users, and so on.
Why would you bother to do something like that, when SmartList already handles it quite nicely? If you're going to waste the time doing that, you should probably just write a new mailing list software package and be done with it. (Gee, inbound email already runs as the list user, so no external suid required. SmartList already handles adding and removing users, even locking the dist file so it doesn't step on itself. Wow...it actually does all the things you're reinventing already. Simple, ain't it?)
As for the user side, how would you prevent malicious foreign unsubscriptions without a password? The existing "confirm" patch from aks would be helpful, here.
You mean _is_ helpful here. It already exists; why re-invent it?
Do we want a mhonarc-like archiving system, given that mhonarc is pretty easy to integrate with smartlist already?
Again, it's a MAILING LIST. If you want to work on the Web, use Phorum or another piece of BBS software. "We" don't want a web-based archiving system; for those who do, mhonarc already exists - why re-invent it. But this part of "we" is happy as punch with the email-based search engine. (If you don't like the existing email search mech, please feel free to re-write it; that's what open-source means.)
And at the risk of alienating three quarters of the subscribers to this list, I have to say that if you can't figure out how to use an X-Command, given all the examples all over the place (see the Manual and the .examples directory), you shouldn't be running _any_ mailing list server. Use Topica or eGroups and save yourself a lot of grief. If you don't understand the simple concept of the X-Command, you shouldn't be adminning _anything._
And if your potential subscriber is too stupid to subscribe without you needing a Web-based X-Command system to send a subscribe X-Command, do you really need _that_ subscriber? (My tolerance for people who can't follow the simple confirm instructions is long past exausted.) That sounds to me like the blind leading the blind...
Look, folks, if maintaining SmartList were difficult, I'd understand all the hand-wringing about Web-based tools. But good grief, it pretty much maintains _itself,_ and the maintainer only has to get involved occasionally when the potential subscriber is unable to follow simple subscription instructions, or the procbounce routines can't figure out the address because a Lotus Notes mail server doesn't know how to send a properly-formatted bounce. So where exactly is the tremendous _need_ for Web-based maintenance packages?
I honestly don't understand it. Can _anyone_ explain why using a web server to control a mailing list as simple to maintain as SmartList is a "good thing?"
Charlie
On Fri, Jul 28, 2000 at 01:47:47PM -0400, Charlie Summers wrote:
And at the risk of alienating three quarters of the subscribers to this list, I have to say that if you can't figure out how to use an X-Command, given all the examples all over the place (see the Manual and the .examples directory), you shouldn't be running _any_ mailing list server. Use Topica or eGroups and save yourself a lot of grief. If you don't understand the simple concept of the X-Command, you shouldn't be adminning _anything._ ...
I honestly don't understand it. Can _anyone_ explain why using a web server to control a mailing list as simple to maintain as SmartList is a "good thing?"
In our case, because we don't agree with your premise above. I used to be less sympathetic, too, but it turns out that there are an awful lot of people who get spooked by a command line and yet make perfectly fine list managers if they have a Web-based admin interface to work with.
Another reason is that editing on-disk files, such as the accept list or digest.admin is annoying and inconvenient to do in e-mail (indeed, I don't think it's possible in stock SmartList). It's loads easier to do that on the Web.
We run the mailing list server. We grok command lines and X-Commands. Some of our users, do too, and they're happy sending X-Commands to the list server. The other list managers use their happy shiny Web forms. Everyone gets what they need.
the X-Curmudgeon, T.
At 2:09 PM -0400 7/28/00, Tim Pierce is rumored to have typed:
In our case, because we don't agree with your premise above. I used to be less sympathetic, too, but it turns out that there are an awful lot of people who get spooked by a command line and yet make perfectly fine list managers if they have a Web-based admin interface to work with.
(*sigh*) I am guessing you are leasing mailing lists, which is a completely different issue. Those people aren't list admins, they are people who are the titular head of a mailing list. Apples and oranges. (And, frankly, I wouldn't be using SmartList for that, since there are less expensive commercial alternatives for commercial list leasing, but that's a seperate issue I don't want to get into.)
Another reason is that editing on-disk files, such as the accept list or digest.admin is annoying and inconvenient to do in e-mail (indeed, I don't think it's possible in stock SmartList).
Either is subscription confirmation. If you really want it, it's easy enough to write...but why bother?
It's loads easier to do that on the Web.
No, it's loads easier to do with pico, or joe, or (ugh) vi, or even grep; it's a pain in the arse to do on the Web in comparison. But again, you're in a different position - you are intentionally trying to make it so simple that people who shouldn't be operating a mailing list in the first place don't hurt anything on your system while pretending to be in charge of one. That's not being a list admin...like it or no, _you_ are the administrator for the list server.
So if _you_ need a web-based form to admin the server, my earlier comments apply. Otherwise, you're clouding the issue.
Most of the people on _this_ mailing list are installing SmartList on their own servers (or even on a virtual server, which is perfectly possible since SmartList doesn't require root; I ran it that way for a lot of years because my providers wouldn't/couldn't install it), not people leasing lists from their providers (who, by definition, should be providing the support). It is to _those_ people I refer. The leasors are _assumed_ to be the same folks I referred to Topica or eGroups, and _should_ have their hands held by the admin (that's you). It's the admins of the servers who should know better, and as we've seen time and time again, don't seem to.
Charlie
Charlie Summers wrote:
And at the risk of alienating three quarters of the subscribers to this list, I have to say that if you can't figure out how to use an X-Command, given all the examples all over the place (see the Manual and the .examples directory), you shouldn't be running _any_ mailing list server. Use Topica or eGroups and save yourself a lot of grief. If you don't understand the simple concept of the X-Command, you shouldn't be adminning _anything._
Not everyone uses real operating systems. It is notoriously hard to get a high-end Windows mail client to send an X-Command. Then there is the fact that the SmartList documentation doesn't mention the fact that you can send multiple X-Commands in one email. Sending email after email when you have lots of maintenance to do gets quite tedious. For this reason, I wrote a CGI script to do multi-subcribe-unsubscribe-checkdist-etc. from a web form.
And if your potential subscriber is too stupid to subscribe without you needing a Web-based X-Command system to send a subscribe X-Command, do you really need _that_ subscriber? (My tolerance for people who can't follow the simple confirm instructions is long past exausted.) That sounds to me like the blind leading the blind...
The level of competence in the average Internet user has gone down. I had to put in a pre-screening before accepting a subscribe/unsubscribe because users didn't understand the failure messages that Smartlist puts out. I check only for exact matches (case ignored), so it's possible that multigram will catch some duplicates I didn't on a subscribe, but my users are certain of whether they have succeeded in unsubscribing, which is, by the way, imperative in today's Internet, where everybody has tried out several mail services. That is, Johnny gets onto yahoo.com and subscribes john4832@yahoo.com to your list. Then he switches to hotmail and sets yahoo to forward there. Then he gets a corporate account ( john@dunkindonuts.com ) and sets hotmail to forward there. When the boss complains about him getting personal mail at work (your mailing list), he's probably too clueless to realize that the list doesn't have john@dunkindonuts.com . As a result, he sends in an email, thinking its been laid to rest, eventually gets a failure notice, tries a few more times, gets really angry, and starts sending you threatening emails. If he already knew, instantaneously, that he is not subscribed with that address, the problem is reduced, at least to a certain extent.
So, essentially, I think the reasons for web interfaces to SmartList are (1) ease of executing X-Commands (2) possibility for instantaneous feedback for users (3) ease for users too stupid to type "unsubscribe", since anti-spam activists tell them to send "remove" instead.
Mark Polo
At 2:26 PM -0400 7/28/00, ZENIT News Agency is rumored to have typed:
Not everyone uses real operating systems. It is notoriously hard to get a high-end Windows mail client to send an X-Command.
It is mind-numbingly _simple_ to use _any_ mail client to send an X-Command. Please see .examples/rc.local.r00 from the distribution for the methodology.
Then there is the fact that the SmartList documentation doesn't mention the fact that you can send multiple X-Commands in one email.
As an aside (which is probably the only part of this message that is actually on-topic reletive to the charter of this mailing list), can someone in private email explain to me _why_ that works? I mean, it shouldn't, since there are no loop structures in procmail, so how comes one _can_ send specifically-formatted multiple X-Commands in a single email and have them execute?
Sending email after email when you have lots of maintenance to do gets quite tedious.
Having run mailing lists for a whole lot of years, I have to wonder about that. I probably send three or four X-Commands in a week's time for the three main lists I operate (the little ones don't count). What "lots of maintenance," exactly, is necessary? Maybe you have your bounce limits set incorrectly? Maybe _all_ of your subscribers are from Lotus Notes systems? Other than occasionally removing people, rarely adding people, and sometimes asking the server how many are subscribed to a specific list (I'm lazy and wrote a "countdist" X-Command), I don't need to _do_ much maintenance. SmartList removes ~98% of the bounces all on its own, and I _expect_ the users to figure out how to reply to the confirmation message to subscribe to the list (I don't use unsub confirmations). If they can't figure out how to hit the reply button as clearly noted in the instructions, and instead insist on creating new messages and hand-typing the confirmation cookie in the body of the mail changing the zeros into capital o's, I'm happy _not_ to have them sending email to the list, thanks - heaven only knows what havoc they might reak.
The level of competence in the average Internet user has gone down.
Indeed. My argument is that it's apparent to me the level of competence of the average list server administrator has as well. And _this_ is something I can't accept without at least trying to deal with it. (I love questions like, "If I do <this>, what will happen?" I want to shout, "TRY IT, FOR PETE'S SAKE!")
Besides, the newbie subscribers need to _learn,_ not be coddled. If we expect a minimum amount of common sense from our subscribers, they will provide it, or not be our users. (Where does it say we _need_ to have every clueless newbie on our lists? Do we want quality discussions, or just raw numbers of subscribers? Just a philosophical question which requires no answer, since each of us will have a personal take on the situation.)
he's probably too clueless to realize that the list doesn't have john@dunkindonuts.com
Of course. I do have some form letters set up for that kind of nonsense, but then I have SmartList sending me copies of the -request mail, so I can actually keep an eye on things. I have to send the occasional idiot one of them, but I have to admit if you get unnerved because some moron is complaining to you, you're probably too thin-skinned to be running a mailing list in the first place. ;)
(Truth is, I send out more programmed form letters for addresses not subscribed and bad subjects than anything else, but I have specific standards set for these things. Most sensible people wouldn't be as anal as I am about the minor stuff.)
So, essentially, I think the reasons for web interfaces to SmartList are (1) ease of executing X-Commands
Shown above to be totally unnecessary, since it's already mind-numbingly simple...just make it the first line of your body, and use the recipe in .examples/rc.local.r00...
(2) possibility for instantaneous feedback for users
This one I don't get, but I'll accept that which I don't understand
(3) ease for users too stupid to type "unsubscribe", since anti-spam activists tell them to send "remove" instead.
...which works just fine, thanks; please look at this recipe from rc.request:
----- # # Is it an unsubscription request? #
:0 EHB * 9876543210^0 ^^(.+$)*Subject:[ ]*([(<]no(ne| subject\ ( ((file transmission|given))?)[>)])?(\ ($(.+$)*(^[ ]*)+((.+|$)+[,.:;]([ ]+|$)+)?)?\ (Could you )?(please )?\ (sign( [^ ]+ |-)?off|cancel|leave|delete|remove|(un|de)-?sub)>|\ ($(.+$)*$(.*$)*)?(.*[^a-z])?\ ((un-?|(un|de)-?sub?)s(cr|c|r)i|\ (leave|(delete|remove) .* from|(sign|take|get) .* off) .* [a-z-]*list>)) * 1^0 B ?? ^^([ ]|$)*unsub(scribe)?([ ].*)?([ ]|$)*\ [^ a-z]?^^ { -----
Ok, so I admit these recipies make me want to curl up into the fetal position; but if you send the word "remove" in the subject of a message to <listname>-request, it gets processed, as does "cancel," "leave," and even "desubscribe." (!) So where is the problem again?
Charlie
On Fri, Jul 28, 2000 at 03:10:42PM -0400, Charlie Summers wrote:
As an aside (which is probably the only part of this message that is actually on-topic reletive to the charter of this mailing list), can someone in private email explain to me _why_ that works? I mean, it shouldn't, since there are no loop structures in procmail, so how comes one _can_ send specifically-formatted multiple X-Commands in a single email and have them execute?
The SmartList back-end is controlled by shell scripts. X-Commands are actually processed and executed by the "x_command" shell script, which does loop over its arguments.
At 3:18 PM -0400 7/28/00, Tim Pierce is rumored to have typed:
The SmartList back-end is controlled by shell scripts. X-Commands are actually processed and executed by the "x_command" shell script, which does loop over its arguments.
I'm sorry, I asked the wrong question (or the right question the wrong way); I know about the x_command script, having added some blocks. A more precise question is, why/how does formail send multiple lines from the header to the script? Shouldn't it only send the X-Command: header line w/o the following indented lines? (This is why I wanted to do this privately; I'm forced to point out holes in my knowledge of the C programs.)
Charlie
At 15:57 -0400 28 Jul 2000, Charlie Summers charlie@lofcom.com wrote:
precise question is, why/how does formail send multiple lines from the header to the script? Shouldn't it only send the X-Command: header line w/o the following indented lines? (This is why I wanted to do this privately; I'm
No, it should (and does) include the following indented lines, since they're still part of the X-Command: header field.
forced to point out holes in my knowledge of the C programs.)
This isn't really about the C programs. It's about RFC 822, which says that a new line in the header should be ignored if it's followed by whitespace.
At 15:10 -0400 28 Jul 2000, Charlie Summers charlie@lofcom.com wrote:
there are no loop structures in procmail, so how comes one _can_ send specifically-formatted multiple X-Commands in a single email and have them execute?
The looping isn't done in procmail, it's done in the x_command shell script.
Charlie Summers pondered parenthetically,
| (I love questions like, "If I do <this>, what will happen?" I want to | shout, "TRY IT, FOR PETE'S SAKE!")
Charlie, I disagree there. Look at this way of stating what you say you want to shout: "What will happen if you do that is that you'll learn what happens when you do it." I feel the question is valid: the person asking is con- cerned that just going ahead and doing doing it might cause some damage and doesn't want to barge forth without checking first. You don't try to iden- tify an unknown substance by tasting it, nor by feeding it to your family.
Charlie posed in passing,
| (Where does it say we _need_ to have every clueless newbie on our lists? Do | we want quality discussions, or just raw numbers of subscribers? Just a | philosophical question which requires no answer, since each of us will have | a personal take on the situation.)
Oh, I feel it deserves an answer.
There are listowners interested in quality, and those interested in quantity.
The latter are composed principally of those who sell or swap ads and those whose egos are invested in the size of the membership rolls and the number of posts. Both care only about having big numbers to brag about. Mention things like signal-to-noise ratios or bandwidth use to them, and they won't understand the concepts.
The former, on the other hand, will trash posts that carry 5Kb of HTML just to MIME-wrap "me too" with a .signature because the sender thinks stationery or color changes are pretty. They'll ask members not to requote entire di- gest issues to respond to a single sentence from a single component post.
At 5:19 PM -0400 7/28/00, David W. Tamkin is rumored to have typed:
| (I love questions like, "If I do <this>, what will happen?" I want to | shout, "TRY IT, FOR PETE'S SAKE!")
<snip>
You don't try to iden- tify an unknown substance by tasting it, nor by feeding it to your family.
(*sigh*) It's a computer program, not a foodstuff. If you set up a testing, non-production list, you can then test recipies to your heart's content. This isn't a mushroom found in the wild, it's a piece of open-source software, where the user may freely access and alter _every piece_ of the code.
When someone asks that question, they are simply too lazy to learn the software by experimentation, which is the _only_ way to really understand any software, but especially open-source, which _demands_ the courage to accept the learning curve.
Instead of asking that question, the user should have tried it, and if it didn't produce the expected results ask the list _why,_ including the experiment's results. If, on the other hand, the person tests a new recipe on a production mailing list, I have no sympathy if it blows up in their face. But I _expect_ everyone using SmartList to at least attempt an understanding of it; I am weary of people acting like they purchased a $2k license to listserv and expecting the same "customer support." SmartList is cool, and you can do nifty things with it - pretty much anything you can imagine, if you have the courage to learn procmail and experiment. (Example: I didn't like the way the digests looked, so I rewrote digest using list conditionals...each digest list may look different. Tough? Nope, only took a minute and the slightest knowledge of shell scripting. But effective, and kinda cool.)
Charlie posed in passing,
| (Where does it say we _need_ to have every clueless newbie on our lists?
<snip>
Oh, I feel it deserves an answer.
Maybe, and your answer is pretty much what mine would be (almost to the level of scarcasm, although I might be grumpier on a good day). However, an equal argument could be made by the other side, I suppose, and since it has nothing to do with supporting the list management software I should never have even posed the question in this forum. (It's certainly on-topic in other forums, though.)
Charlie
I can understand your fustration with people not willing to invest the time and energy into the 'learning curve', but america needs 500,000 new programmers, and many of the ones that are here now are very overworked, and smartlist/procmail can be very fustrating and demanding of your time.
that is why I switched to ezmlm. after i installed qmail (a very good tutorial by adam mckenna, showed how). I had a fully functional list the same day.
many of the functions of a mailing list that are standard, are a pain with smartlist. in ezmlm, i had a new digested, moderated, list up with one command.
i suggest if anyone is having a problem doing something with smartlist, stop butting your head against the wall, install qmail, and ezmlm (300,000 delievers a day for lists.mysql.com) and relax this weekend.
qmail convert, #mike
At 7:07 PM -0400 7/28/00, Mike McNicholas is rumored to have typed:
smartlist/procmail can be very fustrating and demanding of your time.
Not particularly, unless you want to do something really cool.
that is why I switched to ezmlm. after i installed qmail (a very good tutorial by adam mckenna, showed how). I had a fully functional list the same day.
Well, I had a SmartList list operating after the first day I installed it, too, and sendmail doesn't give jaw-clenchingly cutsy error messages like, "Sorry it didn't work out," not to mention a mailing list server name that gets caught in spam filters monitoring for specific keywords used in spam messages. But I've been able to configure everything in my lists I didn't like, and make things run _exactly_ the way I want, not the way someone else thinks I should when using one command.
Besides, what you neglected to mention is that procmail isn't _only_ used for mailing lists, but has about a gadzillion other uses (everything from delivering mail to rejecting spam to sorting those pesky mailing list inbound messages), where ezmlm is...well...a mailing list server based on a MTA that I don't want to use anyway.
I hope you enjoy it; I understand that even majordomo has its proponents. But I'll stick to SmartList, thanks a bunch.
Charlie (who hopes some of the clueless try to install qmail, so they pester _that_ list's subscribers...)
if these 'clueless' are pestering you, why do you spend so much time responding to them. at least I was trying to offer a suggestion. and If you find it so easy to develop with smartlist, why don't you offer source code rather than flames.
#mike
Charlie (who hopes some of the clueless try to install qmail, so they pester _that_ list's subscribers...)
At 8:57 PM -0400 7/28/00, Mike McNicholas is rumored to have typed:
if these 'clueless' are pestering you, why do you spend so much time responding to them.
(*sigh*) You are right in your insinuation, at least in the case of this particular response. But hey, it's Friday night, my daughter's in bed, and Invisible Man/Farscape doesn't start for a little while yet, so I have some time.
at least I was trying to offer a suggestion.
No, you were promoting another piece of software. Which you are welcomed to do, of course, but if you do it on a support list for SmartList, plan on getting called on it. I wouldn't be so crass as to subscribe to the qmail list and complain about it (say, being a bandwidth hog) when I'm not using it; that's just a matter of being polite. Please tell the ezmlm folks about how lousy SmartList is, not us, since we disagree.
and If you find it so easy to develop with smartlist, why don't you offer source code rather than flames.
I do; for those who request help (and who have shown the least little bit of initiative), I help as much as I can. Since you only ever bothered to ask one question that I can find to the mailing list (on 11 July, 03:11:51 +0200, subjected "newbie -> no From: headers," archive/latest/7621 not that that will help anyone anymore, and note I didn't go back through my archives prior to January, 2000), and that question was not particularly interesting to me (since you seemed to be going about "hiding" things, making some simple things unnecessarily complex, while requesting help on what seemed to me to be an unrelated problem), I freely admit I never answered it. Here's a surprise...I don't answer every posting on the list, and don't claim to do so. From the tone you're using, I'm guessing you received little or no useful help on that one question. However, there are quite a number of people on this list who _have_ received answers (or pointed questions to gently lead them in the right direction) from me, generally privately if the questions didn't seem to me to be of general interest (or were the same-old-same-old). Ask around, and you'll find I spend a good piece of time helping people who are willling to invest the time; or don't ask around, doesn't much matter to me.
However, since _you_ have admitted you don't understand procmail/SmartList, and found it so painfully difficult to use that you migrated to something else, what exactly do _you_ have to add to the discussion on the SmartList support list? Will you be able to help _anyone_ here with _any_ question? Might I politely suggest that since you use and seem to be completely happy with ezmlm that you contribute to _that_ software's support list, and unsubscribe from this one?
Charlie (who hasn't "flamed" _anyone_ on this list; trust me, if you think I did, you are way too new to the Net to know what a "flame" really is.)
On Fri, Jul 28, 2000 at 01:47:47PM -0400, Charlie Summers wrote:
Roger;
PLEASE understand this is not directed toward you, although I am using your letter as a starting point for my own, since your views seem to be in many cases the majority view of those on the list.
Point taken. Actually, I don't think you've quite seen my views; what I'd like to do is seduce the poor suckers who think the web's the answer to everything into using a decent, solid mailing list package such as SL, by making it a bit easier for them to do so; then, once they're hooked, get them thinking about the _real_ stuff, hand-hacked procmail recipes and so on. See also the end of this message.
You're right, having written a couple of 'em myself for different (and inept) clients. But it's even _more_ trivial to simply send an X-Command: via email and be done with it. No, really, it's simple. Mind numbingly easy. Why does everyone make it so tough?
Because people these days have horribly incomptently written MUAs which try to hide this sort of nasty technical thing from them. (Heavy irony.)
Why would you bother to do something like that, when SmartList already handles it quite nicely? If you're going to waste the time doing that, you should probably just write a new mailing list software package and be done with it.
Actually, I'm giving serious thought to that anyway - an ML package talking to a database back-end would be interesting to write.
As for the user side, how would you prevent malicious foreign unsubscriptions without a password? The existing "confirm" patch from aks would be helpful, here.
You mean _is_ helpful here. It already exists; why re-invent it?
Yes; the thing is, I don't think it would be _optional_ any more. Anything that lets people unsubscribe arbitrary addresses by mail is open to abuse; but if they can do it by web, it _will_ be abused, because you've just opened it up to all the real idiots out there.
And at the risk of alienating three quarters of the subscribers to this list, I have to say that if you can't figure out how to use an X-Command, given all the examples all over the place (see the Manual and the .examples directory), you shouldn't be running _any_ mailing list server. Use Topica or eGroups and save yourself a lot of grief. If you don't understand the simple concept of the X-Command, you shouldn't be adminning _anything._
I agree entirely! On the other hand, I want to see the spammers that are Topica and Egroups go out of business.
Look, folks, if maintaining SmartList were difficult, I'd understand all the hand-wringing about Web-based tools. But good grief, it pretty much maintains _itself,_ and the maintainer only has to get involved occasionally when the potential subscriber is unable to follow simple subscription instructions, or the procbounce routines can't figure out the address because a Lotus Notes mail server doesn't know how to send a properly-formatted bounce. So where exactly is the tremendous _need_ for Web-based maintenance packages?
Because if SL doesn't have the checkboxes, people will go instead to egroups and get bombarded with spam; or majordomo and have their systems flushed by crackers; or mailman and _only_ be able to do useful stuff via the web interface. (Such, at least, is my experience of mailman lists.)
I want to see things done _right_. If that means adding a few bits of candy on top of the pill to make it more palatable, so be it - you can always take them off again if you're able to face the real thing.
R
At 3:14 PM -0400 7/28/00, Roger Burton West is rumored to have typed:
Because people these days have horribly incomptently written MUAs which try to hide this sort of nasty technical thing from them. (Heavy irony.)
Sorry, broken-record time. (Boy, did that date me or what?)
Am I the _only_ person who read the .example files, and so know that the X-Command line may be placed in the body if one incorporates the recipe in .examples/rc.local.r00? This eliminates _all_ discussion about mail clients, since it will work perfectly with _any_ client.
Yes; the thing is, I don't think it would be _optional_ any more.
I agree completely here; actually, I'd argue that everyone should have the right _not_ to use confirmation, but then shouldn't complain when their server ends up on the RBL or ORBS lists. ;)
I agree entirely! On the other hand, I want to see the spammers that are Topica and Egroups go out of business.
Again off-topic, this is an opportunity for a _serious_ business plan to lease advert-free lists to consumers and businesses; but again, I wouldn't use SmartList for a bunch of large lists, I'd instead use a large commercial package (which more expensive at outlay, is less expensive in admin time for a gigantic number of mega-subscriber mailing lists and already has the "newbie" admin routines).
Because if SL doesn't have the checkboxes, people will go instead to egroups and get bombarded with spam
...much as I _hate_ these services, I have to tell you that although I am subscribed to lists on both services under nom de plumes, I haven't received spam from them to those addresses (other than the annoying advertisements in all of the mail that comes through them), noting that I have never posted to the lists and only monitor them. This is not to be construed as a positive comment; I still dislike them as much as you do.
or majordomo and have their systems flushed by crackers
He, he...you don't need crackers if you have really large lists, with all those perl processes running when the bounces come rolling in. (That said, procbounce can get kinda ugly, too, when outfits like AOL hold bounces for a bunch of mailing lists and shove them all at the server at the same time...)
or mailman and _only_ be able to do useful stuff via the web interface. (Such, at least, is my experience of mailman lists.)
From the user end, you can do pretty much everything the web interface can by sending the proper commands to the server via email. I dunno about the admin section, since I've never bothered installing mailman.
I want to see things done _right_. If that means adding a few bits of candy on top of the pill to make it more palatable, so be it - you can always take them off again if you're able to face the real thing.
Point taken.
Charlie
On Fri, Jul 28, 2000 at 04:11:36PM -0400, Charlie Summers wrote:
Am I the _only_ person who read the .example files, and so know that the X-Command line may be placed in the body if one incorporates the recipe in .examples/rc.local.r00? This eliminates _all_ discussion about mail clients, since it will work perfectly with _any_ client.
If you have control over the SL installation; we've had plenty of mail here from people whose ISPs have installed it and who want to be able to use the vanilla version.
I agree entirely! On the other hand, I want to see the spammers that are Topica and Egroups go out of business.
Again off-topic, this is an opportunity for a _serious_ business plan to lease advert-free lists to consumers and businesses;
Most people don't seem to object to advertisements as much as I (and, it seems, you) do. Witness the "free" ISPs in the USA.
...much as I _hate_ these services, I have to tell you that although I am subscribed to lists on both services under nom de plumes, I haven't received spam from them to those addresses (other than the annoying advertisements in all of the mail that comes through them), noting that I have never posted to the lists and only monitor them. This is not to be construed as a positive comment; I still dislike them as much as you do.
It's also not my experience.
or mailman and _only_ be able to do useful stuff via the web interface. (Such, at least, is my experience of mailman lists.)
From the user end, you can do pretty much everything the web interface can by sending the proper commands to the server via email. I dunno about the admin section, since I've never bothered installing mailman.
Fair enough.
Roger
At 4:22 PM -0400 7/28/00, Roger Burton West is rumored to have typed:
If you have control over the SL installation; we've had plenty of mail here from people whose ISPs have installed it and who want to be able to use the vanilla version.
Well, you don't need control over the install, all you need is control over the list directory (which can and should be donated to the user by the admin). But even so, the complaint should be directed to the ISP, since anyone who doesn't default rc.local.r00 to the version in .examples obviously doesn't understand what's happening.
Charlie
On Fri, Jul 28, 2000 at 08:14:21PM +0100, Roger Burton West wrote:
As for the user side, how would you prevent malicious foreign unsubscriptions without a password? The existing "confirm" patch from aks would be helpful, here.
You mean _is_ helpful here. It already exists; why re-invent it?
Yes; the thing is, I don't think it would be _optional_ any more. Anything that lets people unsubscribe arbitrary addresses by mail is open to abuse; but if they can do it by web, it _will_ be abused, because you've just opened it up to all the real idiots out there.
You could easily integrate the confirm addon into SL. I think it will be installed by default with Debian Linux.
If you want a more secure unsubscription mechanism for a web interface you need something like passwords, PGP keys or SSL client certificates ;) which is all much more complicated for the ordinary user than simply pushing the reply button of the mail client to confirm a (un)subscription.
Werner
On Fri, Jul 28, 2000 at 11:05:27PM +0200, Werner Reisberger wrote:
You could easily integrate the confirm addon into SL. I think it will be installed by default with Debian Linux.
This is correct; in fact, that's what I use.
If you want a more secure unsubscription mechanism for a web interface you need something like passwords, PGP keys or SSL client certificates ;) which is all much more complicated for the ordinary user than simply pushing the reply button of the mail client to confirm a (un)subscription.
Yup.
I think that one of the things I'm trying to say is that there is no web mechanism for authentication of an email address equivalent to "I will send mail to this address, and if you get it you can send it back with the key that I put in there and prove that it's really an address you control".
Roger (about to put all computers in boxes and move to a new house, won't be answering email for a bit...)
smartlist@lists.rwth-aachen.de
-
Aaron Schrab -
Charlie Summers -
David R. Linn -
David W. Tamkin -
Mike McNicholas -
Rob Flickenger -
Roger Burton West -
Steve Bankowitz -
Tim Pierce -
Werner Reisberger -
ZENIT News Agency