Re: This IETF discussion list
--On søndag, juni 01, 2003 19:43:04 +0200 Tomson Eric (Yahoo.fr) [EMAIL PROTECTED] wrote: By example, the more messages from A*** A*** I read, the more I think he is making statements of his own, without verification, without proof, without experience... Maybe this is due to a low technical knowledge? Or to a lack of valuable, proven information? (No offense. Just wondering...) Also remember J*** F*** and all his IPv8, IPv16,... stuff! Do such people just troll for the pleasure, or are they convinced of what they state? I find it amusing that we discuss about SPAM, while we are victims of a kind of spamming! We are not even able to properly filter this list, and we think about preventing SPAM worlwide! Back to my first question. I don't say I know the answer. I don't say I have a solution. I'm just thinking, and sharing my thoughts with you all. note that there's a document currently in Last Call that might be relevant: The IESG has received a request to consider A Practice for Revoking Posting Rights to IETF mailing lists draft-mrose-ietf-posting-03.txt as a BCP. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2003-6-13. Not much comment here so far. Anyway, it must be difficult to be this list's moderator! :-/ the current moderator thinks that it's a job that needs a little more attention than he's currently giving it, and considering alternatives :-)
Re: authenticated email
On Tue, Jun 03, 2003 at 11:13:24PM +0200, [EMAIL PROTECTED] said: [snip] Unless these issues -- and many more -- can be finessed, the cure might be worse than the disease. I thought I'd try this is there any particular disadvantage or centralization of power implied in me signing this message with my PGP key? not unless you consider the network of keyservers unduly centralized ... If not, is there any particular reason that I shouldn't do this all the time? A small number of mail client/PGP combinations may not interoperate correctly with your particular mail client/PGP combination. However, that's certainly no different (and considerably less widespread) than Outlook or other clients sending all mail as HTML, which interoperates poorly with text-only clients. (dead horse there, I know) It's not a solution, but is there a downside? None that I have seen yet (except I'm realizing that either my passphrase is too long, or the time period for which mutt caches it is too short). I'm sure others will have different opinions though. Also, the debate between PGP/MIME and the older plaintext signatures is a well-worn one. Harald Alvestrand, wondering. -- Scott Francis || darkuncle (at) darkuncle (dot) net illum oportet crescere me autem minui pgp0.pgp Description: PGP signature
Re: authenticated email
I have tried both s/mime and pgp, well in fact still trying to use pgp. The main problem is an implementation problem, where a bad and popular version of Outlook was crashing when trying to verify the signature. Now it all comes down to a global PKI, be it SSL/TLS or PGP. PGP has got it running at an individual user level with the www.keyservers.net but for TLS NO CA will deliver a certificate that can sign other certificates (corporate e-mail certificates). I think there are some attempt to do that... If you look back on this list you will see a thread called GLOBAL PKI where there was a lot of discussion at the time... For spamming having signed e-mail is good as you can trace back (traceability). But are you responsible when a virus on your computer sends signed e-mail with a virus attachment. At a SPAM meeting before INET2002 a company talked about certifying advert Well all the options are open, but going to have a mainstream digital signature is the goal... Cheers Franck On Wed, 2003-06-04 at 09:13, Harald Tveit Alvestrand wrote: I thought I'd try this is there any particular disadvantage or centralization of power implied in me signing this message with my PGP key? If not, is there any particular reason that I shouldn't do this all the time? It's not a solution, but is there a downside? Harald Alvestrand, wondering. -- Franck Martin [EMAIL PROTECTED] SOPAC
RE: Engineering to deal with the social problem of spam
Iljitsch van Beijnum wrote: Just adding authentication only solves a very small part of the problem: we can then accurately whitelist known senders. Two points: 1) besides white listing, the approach also provides irrefutable evidence to law enforcement about spam sources. 2) it is clear from the related threads that many would rather continue the lively exchange debating nirvana, rather than tackle the small parts of the problem that are technically achievable. A new interpersonal batch communication system certainly sounds like a good idea. The problem with email is that it is incredibly ill-suited for transferring larger files. A new protocol should be able to do much better in this area. However, this doesn't have much to do with spam issues and might make the whole thing much more complex. We can always make it more complex than necessary, but it is pointless to compare the complexity of a new system that does the job with a system that is proven to be open to abuse. No one believes that a house lock keeps out all intruders, and indeed some do get in. But we *do* believe that house locks reduce the threat to a socially acceptable level. The trouble is that on the internet, you can go from house to house and try to break locks and nobody will stop you. In the real world, you wouldn't be able to do that for very long. Adopt draft-hain-ipv6-pi* as the standard addressing plan, provide automated intrusion detection reporting, and Internet prowlers wouldn't be able to attack for very long either. So let's show some adaptability of our own and plug those SMTP holes. Or simply leave SMTP to the spammers and move on. Why look at individual messages? How much non-bulk mail can someone possibly need to send? 10 messages per hour? 100? 1000? @ 5kB/message on a 10MB/sec link, 2k/sec. That's why it's important to look at ALL mail rather than just copies of one message. Spammers by now know how to make messages look different even though they're essentially identical. Exactly how would you coorelate email across multiple accounts, on multiple service providers? Someone's home MTA sould be able to simply rate limit the number of messages an individual user gets to inject into the global email distribution system. Then all we need is a system to differentiate between trusted MTAs and rogue ones run by spammers. Why would a spammer limit themselves to a single MTA, or account. Run VMware on a laptop, and there could easliy be 10 parallel rate-limited sessions going on. If the rates are low enough, each virtual system could automatically log into another account on another MTA, then come back when the timer goes off. Tony
RE: The utilitiy of IP is at stake here
Anthony Atkielski wrote: ... I've always wondered why signatures of ink on paper are binding, whereas digital signatures are not, even though digital signatures are literally billions or trillions of times more difficult to forge. E-mail can be easily forged, but then again, so can a fax. So what's so special about fax? I really don't know, maybe one of the armature lawyers will enlighten us. My perception is that it is derived from the physical paper evidence, and that forging email is so simple for Joe-sixpack that everyone knows not to trust it. Tony
Re: authenticated email
Michael Thomas wrote: It depends on what you mean by signing. Signing a message in and of itself ought not hurt anything modulo software bugs, etc. But the real question is what does the receiving program (MTA, MUA) do with that signature? At the very least it could verify the signature, but then what? If it doesn't verify do you drop it? (transitive trust comes into play, but most likely). Does it do anything beyond that? Let me ask something in return: do you think that just the act of signing mail -- with no trust roots implied -- could help? My sense is that it might in a sow-the-seeds kind of way for some later goodness (it's as you say not a solution). I too would be happy to hear downsides. Without trust roots, webs of trust, or additional mailing list daemon features, signed e-mail doesn't really add anything, at least not now. Signed e-mail could help ensure that e-mail sent to a list comes from the same person as the one who subscribed to the list. But then again, the same feature could be implemented much simpler by some header which must stay constant from the same person and is stripped off by the list daemon when forwarding the mail to the subscribers. More seriously, ensuring the sender's address is right is useless IMHO unless there's a policy for letting people to sign-up to a list. Spammers could get a new address and generate a key pair, sign up using them, send spam, and repeat with another address and key. So, its the same old question once again: how do we all enroll ourselves to the same trusted root or web of trust? Should the next PGP key signing party be held in the plenary, for everyone? Or maybe Harald stands in the IETF reception desk to look at people's passports and certifies keys? Hmm... maybe we could make PGP key mandatory in registration, and have the secretariat form a web of trust. At least we could trace every key to a credit card number... sounds pretty good but this wouldn't deal with the folks who don't come to the meetings. Maybe we could turn on mandatory PGP signing for all list e-mail for a year, and at the end of the year make a web of trust for the folks who sent e-mail that year. That wouldn't be perfect, but it would sure reduce the size of queue in front of Harald for the passport check ;-) --Jari
Re: Engineering to deal with the social problem of spam
(I really wanted to stop this thread with my previous message, but...) On woensdag, jun 4, 2003, at 02:54 Europe/Amsterdam, Tony Hain wrote: Just adding authentication only solves a very small part of the problem: we can then accurately whitelist known senders. Two points: 1) besides white listing, the approach also provides irrefutable evidence to law enforcement about spam sources. Ok, there's some value in that if we build a good key infrastructure. Wouldn't say irrefutable even then, though. What I meant to say: we need more than authentication. A new interpersonal batch communication system certainly sounds like a good idea. The problem with email is that it is incredibly ill-suited for transferring larger files. A new protocol should be able to do much better in this area. However, this doesn't have much to do with spam issues and might make the whole thing much more complex. We can always make it more complex than necessary, but it is pointless to compare the complexity of a new system that does the job with a system that is proven to be open to abuse. SMTP shouldn't be used to transfer binary files. It leads to all kinds of problems: clogged mailboxes, wasted bandwidth (base64, aargghh!), you name it. A better batch interpersonal communication system would be able to send the message, but then negotiate what to do with the attachment. From some people you may want to always immediately receive the attachment, from others you may want to read the message first and then decide whether to inititate the transfer of the attachment. This would be very cool except that it breaks current email systems at a fairly fundamental level. Adding authentication on the other hand, can be done in a way that may not be compatible with current ESTMP, but it does (or at least: could) fit into the current email architecture without too much trouble. The trouble is that on the internet, you can go from house to house and try to break locks and nobody will stop you. In the real world, you wouldn't be able to do that for very long. Adopt draft-hain-ipv6-pi* as the standard addressing plan, provide automated intrusion detection reporting, and Internet prowlers wouldn't be able to attack for very long either. Only if someone cares enough to go to the place where the prowler deploys his activities. There was a time when this was a reasonable assumption; but this time is now in the past. So let's show some adaptability of our own and plug those SMTP holes. Or simply leave SMTP to the spammers and move on. Fine by me. Why look at individual messages? How much non-bulk mail can someone possibly need to send? 10 messages per hour? 100? 1000? @ 5kB/message on a 10MB/sec link, 2k/sec. And how exactly would those messages be non-bulk? I mean, I type fast, but even then it takes a second or so to even find the recipients for a message. That's why it's important to look at ALL mail rather than just copies of one message. Spammers by now know how to make messages look different even though they're essentially identical. Exactly how would you coorelate email across multiple accounts, on multiple service providers? We push this back to the source MTA. Then if the source MTA does a bad job, we revoke the MTA's not-a-spammer accreditation so only messages with whitelisted senders can get through. Alternatively, we can build a serial number system. An MTA must then add a serial number that starts from 0 every day or every week to every message. This way everyone who receives a message from this MTA knows how many messages the MTA has already transmitted this period. Obviously spammers will fake the serial number so we also build a system that makes it possible to check if a serial number wasn't used more than once afterwards. This shouldn't be much of a problem for spammers if they can set up a new MTA in five minutes, but if they (for instance) have to get three people in good standing to sign the new MTA's key in order to be able to start a new spam run, then it gets more troublesome for them. Someone's home MTA sould be able to simply rate limit the number of messages an individual user gets to inject into the global email distribution system. Then all we need is a system to differentiate between trusted MTAs and rogue ones run by spammers. Why would a spammer limit themselves to a single MTA, or account. Run VMware on a laptop, and there could easliy be 10 parallel rate-limited sessions going on. If the rates are low enough, each virtual system could automatically log into another account on another MTA, then come back when the timer goes off. At a limit of 1000 messages per hour per account, they need 1 account-hours to send out 10 million spam messages. Assuming it takes 64 hours (on the weekend) to get an account yanked for spamming that's 160 accounts. This is a good start. Add some additional stuff such as limiting the number of messages per hour based on the number of bounces
Re: authenticated email
--On tirsdag, juni 03, 2003 16:02:52 -0700 Michael Thomas [EMAIL PROTECTED] wrote: It depends on what you mean by signing. Signing a message in and of itself ought not hurt anything modulo software bugs, etc. But the real question is what does the receiving program (MTA, MUA) do with that signature? At the very least it could verify the signature, but then what? If it doesn't verify do you drop it? (transitive trust comes into play, but most likely). Does it do anything beyond that? Let me ask something in return: do you think that just the act of signing mail -- with no trust roots implied -- could help? My sense is that it might in a sow-the-seeds kind of way for some later goodness (it's as you say not a solution). I too would be happy to hear downsides. well... if signing my email would help get rid of the nonconformant mailers on the path that do perverse stuff that breaks signatures, that certainly would be a benefit to the world verifying my own signature failed and here's why: Original: --==1875089384== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Copy: --==1875089384== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The difference matters not at all to anything but a signature verifier. sigh. Harald
Re: authenticated email
On Wed, Jun 04, 2003 at 09:02:57AM +0300, Jari Arkko wrote: Without trust roots, webs of trust, or additional mailing list daemon features, signed e-mail doesn't really add anything, at least not now. Signed e-mail could help ensure that e-mail sent to a list comes from the same person as the one who subscribed to the list. But then again, the same feature could be implemented much simpler by some header which must stay constant from the same person and is stripped off by the list daemon when forwarding the mail to the subscribers. Signed e-mail is useful for assuring that e-mail message sent at one point in time is the same as an e-mail message sent earlier. (Not necessarily just for list mail, but also for person-to-person mail.) So, its the same old question once again: how do we all enroll ourselves to the same trusted root or web of trust? For the specialized case of preventing SPAM, it's not necessarily necessary to do the full authenticated e-mail where we know the identity/passport number/Al Quaeda cell designation of the sender. (Such things are of interest to John Ashcroft and others of that ilk pushing Total Information Awareness, but it's not really needed if the only requirement is to stop SPAM.) So imagine a system where if you want to send private e-mail to someone, your public key figureprint must either be on a list of acceptable senders, or you must submit some kind of mathematical evidence that you have spent 5-10 minutes of CPU time crunching on some particular problem. After you do this, you get added to that person's good guys list, unless it turns out that you have sent spam or something else annoying/abusive, at which point the user can remove you from the trusted list, and the next time you want to send e-mail to this person, you have to crunch for another 5-10 minutes of CPU time. Yeah, some special provision would be needed for CPU-limited PDA's, but most PDA's that I've seen don't attempt to talk to the network directly; they generally go through some kind of mutually trusted gateway box that could do the CPU crunching for them. (Or you could argue that since that initial contact simply won't be supported from by CPU-limited PDA's if they don't have a mutually trusted third party that can pay the hashcash for them.) The point of this message is not to argue that this is the Right Way to do things, but to point out that you don't necessarily have to solve the authenticated e-mail problem (I invoke PKI; your project is doomed to long, slow, painful, lingering death) in order to solve the SPAM problem. - Ted
Re: authenticated email
--On onsdag, juni 04, 2003 13:02:11 +0200 Alexandru Petrescu [EMAIL PROTECTED] wrote: Harald Tveit Alvestrand wrote: I thought I'd try this is there any particular disadvantage or centralization of power implied in me signing this message with my PGP key? Is there an IETF PGP keyserver somewhere? nope. we have had a lot of PGP key signing parties at IETFs, but nothing official. I generally use wwwkeys.eu.pgp.net when I look for keys, but there's nothing very magical about that. Did you store the key securely on the keyserver? Why should I? It's signed, so it's either there or not there - you can't fake it, just remove it. (And sometimes I wish the keyservers WOULD drop some keys - there's an old key of mine out there that I don't use any more) Which keyserver? Which port? The particular network I connect to is blocking most ports, so I can't retrieve your public key. It's attached below, too. Anything to increase the Kbytes-posting-stats :) On another hand, the same particular network recommends that its users use a particular MUA, which has built-in certs of certain CAs, which allows readers of this email to trust I am who I claim to be, legally (as if I showed an ID). If not, is there any particular reason that I shouldn't do this all the time? Will the government of the country you live in allow you to store your public key on a public PGP keyserver? (a particular government was _not_ allowing it as of 1997, and if things have changed since then I'm happy, but the try and find out way is high risk for me.) The Norwegian government does not care, so that's not a downside for me - but of course, your mileage may vary. Harald -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.2 (GNU/Linux) mQGiBDS6GscRBADSUKFMf4osMWUHpRqFUjqklLpq4tjL5gYFH5sjYFleu0XYWsB1 AI9ToSfKljxYkePRSXIMArb94RV2VHLmyEvU5VLgKgLT6Sw8mUyf5GJh2uC+fECq on8b5yFiuRo7Fut7b0sDvRv7/TPbQ7brKBboQK7H2IWKmBbjDIhKnkiElwCg/3nK JJNg8/V9G06BNg9At6WDWcUEALZuJx+y0wGqhIZvZExwekYZuVH1kWJ3gvq/r0U0 ESrsXQ4p4NAFfG+uWpGTyHDOS4xTvgQE6bAe1RNsIbevi4WeT00yYbUEnR6Ylqyr SYGBMLBacEjCenS4bQOCVhv25oZQS60FQXeHDRpsnLt4DsPNn0OuTyDT7xyPzNAy 5eTQA/4mktErIaqWNRwmto/Tx71J90EqCcOoQQQ2XbDlmRp29AK8O782AAp0HgW1 ebK4cuUOwHOwYWHyFqeCVhrVjfVUJu62iyg54QKgaIPU7RwiCAM03buBJz4fMo3B wHyP3uLn/ICxBoTGz/rPYJ1RktfvP7KIXJ1dct1u45wRy83dSLQuSGFyYWxkIFR2 ZWl0IEFsdmVzdHJhbmQgPEhhcmFsZEBBbHZlc3RyYW5kLm5vPohOBBARAgAOBAsD AQICGQEFAjfJgygACgkQOMj+2+WY0F5CNQCdGxcVXgFjHfvpoaRKltv8cSvS9iUA nRY9zfYjWEmBOZvMBADMHTFogPM7iEYEEBECAAYFAjyZbDMACgkQ4hFoDYCwek8h FQCg6guHn1DLmXzrJSeoltYkboVihnwAmgPUnRT4fSJ88/jKhjltI0gHUSxIiQCV AgUQPJlsNUQVcM1Ga0KJAQFDawP9EZ1J4lkNR+HAxa2RUvQcSEPCE/2B2P2QMABn vtCFFhlxseD/qyLk3Dz03WaOsVS/Qi0hV3U3XpoGW5b5IKLxtv2JSK4g3ciaxt10 dKlvkM2Mo3DqI4Jj/2UONV7Vm6Fy8ViX/z6jJx8dtSSf4o+wwSJXE3Lpw72xsy73 tfpqc/SIRgQQEQIABgUCPJlsNwAKCRDtOjnjk2dMQLHxAKDqK2VkXr9x1nwpGxe9 koRt8+JtjgCg+Zr/UYqOIARtu0p5YyWcxcdpa/GIRgQQEQIABgUCPJpH9AAKCRAs bbJ87KtMIKxuAKCNRMIhIAeJyKYnmxhE9r3NC0pekwCeNFlUJ3srLwqkWfz8I3fB 5ZDUA+SIXAQQAQEABgUCOe1THgAKCRAz8FU8F14BOQVBAf4q6b3VOsHx3tvkoE+p pOCJhWeVXdZYY8hF/kLdscIdl9XMANazGtnKpVaki540wdteBxQW1wREttYixGc7 kTrbiEYEEBECAAYFAjgq5qAACgkQNnstYOXbLtrJWQCfW0FT60pXiniou2988Iik VwRRfZQAn3WLmHD2rzbnv7alMqlP/HEn96GTiEYEEBECAAYFAjyZZw0ACgkQtfZN GkrRZbRadwCcCHUFBzyhMk7C90xaba7e+BU9zSwAoPzKZnbhL5nDxRwjZnzbvGA0 +gFNiEYEEBECAAYFAjgrCywACgkQwM9r9d5kYh6+qACffyf5IulmTj2nJBTWDdyI +dBl9XoAoM8ClQ/mos+a1FtzzQeuGc47Kwe7iEYEEBECAAYFAjgqZMYACgkQ1KVN SMW+c1jcRwCglJNF0koNr5LwQ1yR+ziiaKJmEH4AoJPboEhTT6s1RD3S/Qq8OuNl D+oqiEYEEBECAAYFAjgqSdwACgkQ3SDCJgQwZVbZBQCaAw4G2iUltXbBLytrb6Yq 21R/+GkAoOT58dXEIt7TMj6fU0aze5c+s967iEYEEBECAAYFAjyZamMACgkQ7O2h hlqBXB86yACg1Rjy1TaYF2MN9lsdg0LjLw0R5S4AoMUfZdSd2UaOpCYGFJORqFBL Z0RciQCUAwUQPJmFP/bvOLj4Q3BxAQF+YgP4zayJnWfWTmy2CNLGXwlF9gERBhNE qLmhsICzkUZcV/v+vZUowhRmiMIEQhqssSsymvn27Z89dDlv4GQ7Xvq9FbcQmmxZ agS14vUHnY+Z8za2XqloD/qB1OlqwlB7f93DXN8pUQEB7IMfYkcxVDHeF8KF0WXy s3jiAN6+ELSOH4hGBBARAgAGBQI8mh6cAAoJEPyNdnM8hiYPZIcAnA3k21raO2BN NgV7bPmA3asqHUgRAJ9gWOLF0tFKP7eV94Smvhe8g49wDYhGBBARAgAGBQI8mkhs AAoJEH5cypraYkBDcHIAn3m7rVrkU5J29QfUIYW1cPS5fKPFAJ4gae/C0bvj7w7r yKkI/3nS2jzZu4hGBBARAgAGBQI8mYH0AAoJEMl0JfuuS12SXX0AnA6xp1seY+o3 atEg8pGAaBEDC9SfAJ4k+aj2Um6qfEAyNoJEEOc6rO/hXYhGBBIRAgAGBQI9YXsh AAoJEEouP6ZaRCq0aE0An17m1RVs5UQR0D+t3rySmR4OivMUAJ0TEUC1b0NW57sf u+AGjRz1XtasmohGBBARAgAGBQI8rFkHAAoJEEbhbVTZrEgjAD4AoIVKZsLRVijc iv8tW12q/LyVku8hAKCVrQkL+2tekZVm3jiESFZDxpSP7rQuSGFyYWxkIFR2ZWl0 IEFsdmVzdHJhbmQgPGFsdmVzdHJhbmRAY2lzY28uY29tPohGBBARAgAGBQI8mkf7 AAoJECxtsnzsq0wgLMsAoJSizecoJ22KjP4ZZVNbjVNSoEpNAKDzaAIWmczroetX jyC/LzB88kYbD4hLBBARAgALBQI57VdYBAsDAQIACgkQOMj+2+WY0F4BEQCgyBri eNCNJPcW4zOTXS3Qrn7yXZ8AnRFwI7AcmnuLCRxpdbIBegdOtumliQCVAwUQPJmF R/bvOLj4Q3BxAQH6DAP8Dbsy5PabqJCwCHJK+FGMOsDuQjJ/xT/5EyJNoD+qToqA ufi3YXdzHwQiqzRDuk+5IH2C2CTfDQluz0fzVU51Tepg1ifHDpw9CutgtuKIMwtV 2xdVG2zt0HX1EJrYKn+j+2XERuWazpzg0tD5XGSDs3QTmXwFGH9+iEmxnIr8BdWI RgQQEQIABgUCPJpIcAAKCRB+XMqa2mJAQ9IrAJ4uekVx3BAE0QgLhgsLzmprBsRS
Re: authenticated email
Theodore Ts'o wrote: Signed e-mail is useful for assuring that e-mail message sent at one point in time is the same as an e-mail message sent earlier. (Not necessarily just for list mail, but also for person-to-person mail.) ... For the specialized case of preventing SPAM, it's not necessarily necessary to do the full authenticated e-mail where we know the ... someone, your public key figureprint must either be on a list of acceptable senders, or you must submit some kind of mathematical evidence that you have spent 5-10 minutes of CPU time crunching on some particular problem. Agreed. CPU time falls under the same class of schemes as the address validity test that we already have for list e-mail; the spammer has to invest more time and money, and have a bigger risk of capture, the more we demand from unknown senders. On list enrollment, you could even demand that the same address be valid for some time, such as a day, through a delayed validation scheme. Hit and run spammers might not be able to use the same mail address for a very long time. Could we use the same for person-to-person e-mail? If I read the spam a day after it has been sent, will the spammer's mail agent still be there for an automatic ack that the address is valid? In general, I'm very much in favor of these types of mechanisms as opposed to a knee jerk lets authenticate everyone and see if it helps approaches ;-) (This doesn't mean that such mechanisms are ready to be deployed and problem free in all cases.) Yeah, some special provision would be needed for CPU-limited PDA's, but most PDA's that I've seen don't attempt to talk to the network directly; they generally go through some kind of mutually trusted gateway box that could do the CPU crunching for them. And speaking of problems, I do think the imparity between different devices is a real issue for the CPU time method. *Your* PDA may not talk to the network directly, but *my* phone runs IMAP, SMTP, SSH, SSL, HTTP, and streaming video from the net in addition to the usual office applications such as Doom and C64 emulator ;-) Given this, some people might argue that my phone can then afford the CPU crunching as well. Perhaps, but the problem is that while the capacity in the low-end increases, the same happens for the high-end as well. I'd claim that the relative speed difference stays constant over time. I don't have a good suggestion on how to resolve this, however. Perhaps the lowest common denominator is still a big enough deterrent? Note that help from a network entity is not likely solve this problem. Think about it: the average users are not going to install their own network helpers. They are going to rely ISPs' servers. So, we'd see SMTP servers that do the number crunching on behalf of the ISP's customers. Enter a spammer who claims to have a small device... --Jari
