Jim Ramsay <[EMAIL PROTECTED]> writes: > Yeah, maybe the terminology is a bit different in tmda-cgi land. > I've always thought it's silly to whitelist an email address but not > release it from the queue. When I whitelist a message in tmda-cgi, > it's usually an automated website email confirmation I know I'll be > hearing from again, so I'd just end up releasing it anyway if they > were separate steps. > > But maybe we should make a note of that somewhere in the tmda-cgi > docs, that "whitelist" also releases, just as "blacklist" also > deletes. I suppose I could also add a function for "Whitelist but > do not release", but I don't know who would use it.
Personally, I think the current behavior is wrong, and you should consider changing it. First, it's non-intuitive. In general, if presented with a GUI that had separate buttons for whitelist and release, I'd expect each to do only their job, not trigger one another. Next, it runs counter to the behavior of tmda-pending which is confusing. Further, it's restrictive. If I just want to whitelist or blacklist the message without releasing or deleting it, I can't. Lastly, why is it necessary for whitelist/blacklist to trigger release/delete when the PENDING_RELEASE_APPEND and PENDING_DELETE_APPEND are available? One just has to set them to get the same behavior if desired. > Just for interest sake, is there some reason my patch wouldn't do > all this? Sorry, I wasn't very clear in my last message. Your patch would work fine, I just found the implementation confusing. X-Primary-Address should never be confused with Return-Path, and overloading the 'return_path' variable didn't make this distinction clear. It was too easy for someone to assume 'return_path' was something it wasn't later on down the road and get burned by it. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
