Subject: Re: idea for spam protection

From: Stephane Maes <[email-masked]>
Date: Sat, 12 Mar 2005 17:00:23 -0700

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: [email-masked]
IM: shmaes (AIM, Y!,Skype) or [email-masked] (MSN Messenger) 

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf