>You're missing my point. SIMS already incorporates RBLs. You don't >*have* to use them and, apparently, you don't. Fine. But for those >of us that *do* use RBLs, it might be nice if the clients themselves >could turn this function off or on. That's all I'm asking for.
I think if we look at this practically, you're one step away from your clients then asking for even finer tuning. "I want to receive e-mail from [this spammer] but not [that one]." Clients think this is all trivial for the admin to implement. At what point do you tell them it can't be done, or to stop whining? From a further practical standpoint, changing the password I suspect is a well-defined command-response procedure defined in the relevant RFCs. Somehow, you have to have a way for the client to communicate to the server not to use the blacklist. either every time a connection is made, or at least once initially so SIMS can can keep a list associated with all the accounts. Is there even a protocol in the RFCs that could easily implement this? If Stalker has a trivial way to implement this idea without adding per-user web admin, for example, sure what the hell... I wouldn't use it but maybe others would. But my vote for the limited programming time put to SIMS is for more important features... Stefan Jeglinski ############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
