David Bremner <[EMAIL PROTECTED]> writes: > What do people think about the idea of nagging people who do not > confirm? More precisely, after some time out, resend a confirm > message that says > > "hey, you didn't confirm yet. If you don't, I'm going to delete > your email".
I guess I don't see the point of this. Your first confirmation request clearly laid out what needed to be done, and said that the message would not be delivered if they didn't confirm. If they choose not to confirm, that's their choice. How is yet another message going to change things? Keep in mind that there may be a good reason why the message wasn't confirmed. For example, my confirmation request says something to the effect of: "please don't confirm this message if your question is answered in the TMDA FAQ". Sending another confirmation request to these folks will simply be confusing and annoying. Another example is that sometimes when I reply to a mailing list and Cc: someone, I get back a confirmation request. However, since I _know_ the person I Cc'd is reading the list, I don't reply to his confirmation request. Also consider that receiving a TMDA confirmation request essentially gives the sender a "second chance" to decide whether he wants that message delivered or not. He may re-read his original, decide that that wasn't really what he meant to say, and compose a new message, leaving his first message unconfirmed. I could go on and on here, but I think you get the idea. > It seems roughly in the spirit of those "could not deliver message for > 4 hours" messages. Your assumption is that a non-confirmation is some sort of failure, which as I've explained above, is often not the case. Since there is no way you can tell, it's better to be conservative. You might say, "make this feature optional then if you don't like it". No, because as this thread demonstrates, users are not always aware of the potential consequences of something like this. IMO, it offers marginal (if any) benefit, and will only serve to incite further animosity towards TMDA. _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
