At 4:04 PM -0400 9/2/01, higgins@peg.com is rumored to have typed:

confirm -- if I managed only 1 list I'm sure I'd like it. However, I run 30+ (ok, 44) lists. There's a web page interface which lets people subscribe and unsubscribe to multiple lists. I'm looking for something a bit more robust.

Forgive me for correcting you, but confirm is _completely_ robust. It, and SmartList in general, just doesn't work the way I believe you want it to work; this is an entirely different circumstance which doesn't affect the operation of the software in general. With SmartList, each list is seperate; if you want a single-server approach with the combinant increase in required resources required by perl or python's intepreted nature, I suggest you move to majordomo or mailman. SmartList alows each list to be completely seperate allowing considerably more flexibility between lists, while operating with an extremely small resource footprint. This is apparently not what you are interested in. (And so there is no confusion, I know of SmartList implimentations with _hundreds_ of lists that are completely happy with its operation and robustness. I'm only running twenty-two public or private lists with probably sixteen different list administrators, but I'm quite happy with SmartList's operation.)

For example, if I'm waiting for a response from address x, never send a request to x.

I do not understand what you mean by this; if you mean while waiting for confirmation the address will not receive list email, confirm does that. If you mean something else, which is likely, you will need to be a bit more clear in your question.

Check a reject list before sending.

Um...SmartList does that out-of-the-box without any add-ons, and so long as the reject file is not delinked, this can be universal among all of the lists on your server. Forgive me for asking, but did you get the chance to read the .etc/Manual file (included in the SmartList distribution) and FAQ (URL included in my last message) before posting? I also request you phrase your questions more carefully, since apparently the correct answer to what I believed to be your initial question isn't really the information you are looking for. If I understand your current question (which I may not, considering that I obviously misunderstood your initial question), I believe the answer is that SmartList will not operate the way you require. Charlie

At 7:49 PM -0400 9/2/01, higgins@peg.com is rumored to have typed:

No, I explained the problem. I don't want 10 clicks of a submit page to drop 440 you have been subscribed messages into someone's mail box.

Obviously, I am too dense to understand your explaination, so I will leave that to others to decipher - I don't see where 44 lists would create 440, or 4400, messages. (I thought I mentioned that unlike mailman or majordomo, each list is seperate in SmartList's "viewpoint." Therefore, there isn't an underlying "list-of-list" management system, which would make what I think you suggest difficult using SmartList as an engine. That doesn't mean you aren't welcomed to write this layer yourself, but it isn't native to the way SmartList handles mailing lists and so would seem to me to be quite difficult. If you've been using SmartList since 1994, I assume you are aware of this difference in philosophy.)

The reject list is not checked prior to confirm's operation. Hence, it's possible to harass someone using the subscription mechanism.

(*sigh*) It should be simple enough for you to integrate a reject file lookup into the confirmation routines should this be an issue for you; simply add a recipe to the rc.local.r00 file checking the reject file and do what you will should the target address be found therein. Since I have never seen this to be a problem, I have not written the recipes you are looking for, nor has, to my limited knowledge, anyone else. You are welcomed (and even expected) to customize SmartList in any way you find desirable. Of course, it is STILL possible to "harass someone using the subscription mechanism," since until the maintainer manually adds the target address to the reject file the harasser could, I suppose, send multiple subscription requests. That would not be the most efficient way to harass someone, though, since there are plenty of lists out there which don't require confirmation to use for that purpose (mailbombs are depressingly simple to send even now).

I don't require that smartlist do it, merely that it is integrable into a smartlist environment.

Please consider making the code you add to do whatever it is you want available to the rest of the community once you have completed it. Since it's obvious I can neither understand your questions, nor supply answers (or at least not the ones you want), I will not respond to you again, and will leave it to others on the list. Charlie

In article <200109022349.f82NniT19844@emily.peg.com>, higgins@peg.com writes:

No, I explained the problem. I don't want 10 clicks of a submit page to drop 440 you have been subscribed messages into someone's mail box. Right now the worst that happens is they get 44 subscribed messages, a bunch of e-mails and 44 unsubscribed messages. With confirm, it would be possible for someone to have us do their dirty work and drop 4400 did you want to be subscribed messages into their mailbox. In other words, confirm aggravates the situation.

The web tool which handles subscribe requests should check each list's cookie directory to see if a confirmation message has already been sent to that user. If it has, don't send another one. Problem solved.