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(_dot_)maes(_at_)oracle(_dot_)com
IM: shmaes (AIM, Y!,Skype) or stephane_maes(_at_)hotmail(_dot_)com (MSN
Messenger)
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org <ietf-bounces(_at_)ietf(_dot_)org>
To: ietf(_at_)ietf(_dot_)org <ietf(_at_)ietf(_dot_)org>
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf