
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