Hmm, But wouldn't it be an unrealistic demand on constrained clients. Some of us try to resolve the issues of a stack unsuitable for practical / usable mobile email. This proposal would surely result into reduced battery life and encourage fragmentation from the IETF stack for mobile. How would you proposed to address these clients? Wouldn't exceptions for mobile then actually defeat the proposal or at least open the potential for loopholes? Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - RTCC & Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296. e-mail: stephane.maes@xxxxxxxxxx IM: shmaes (AIM, Y!,Skype) or stephane_maes@xxxxxxxxxxx (MSN Messenger) -----Original Message----- From: ietf-bounces@xxxxxxxx <ietf-bounces@xxxxxxxx> To: ietf@xxxxxxxx <ietf@xxxxxxxx> Sent: Sat Mar 12 07:55:12 2005 Subject: idea for spam protection hi, I didn't find a suitable working group so I post it here. I hope it isn't a too inappropriate list. I haven't really been following the debate regarding spam protection and had rather hoped that the issue would be resolved on its own but it seems it won't. I have had an easily realizable idea (oh well) for spam protection for a while: the reason spam gets sent is because obviously someone is making money at it. if it suddenly becomes expensive to send emails, it will stop. my idea is to use encryption (for now - better alternatives might exist); if it takes up to 1 minute to encrypt a mail, the cost per mail is increased greatly. this would be realized through an extension to the SMTP-protocol, allowing the server to request that (say) some message is to be encrypted with a key (which is horribly large, or a more expensive algorithm is requested). when the sender gives the encrypted message, the server verifies correctness and lets the email through. obviously, the algorithm should be chosen as to create much work for the sender and little work for the verifying receiver. instead of encryption (which government hates so much), an NP-hard problem could be used instead. an extension on top of that is a feature to let trusted mails through, which is needed for mailing lists to still work. this could be solved with assymetric keys (signing). so, first off, has anyone looked at realizing this? if not, how do I get around to get things started? should I publish some RFC-draft and, if so, where? thanks, Johan Henriksson _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf