Date: Tue, 11 Feb 2003 15:04:21 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Brad Knowles <brad.knowles@skynet.be> Cc: Rahul Siddharthan <rsidd@online.fr>, freebsd-chat@freebsd.org Subject: Re: Email push and pull (was Re: matthew dillon) Message-ID: <3E498175.295FC389@mindspring.com> References: <20030211032932.GA1253@papagena.rockefeller.edu> <a05200f2bba6e8fc03a0f@[10.0.1.2]>
next in thread | previous in thread | raw e-mail | index | archive | help
Brad Knowles wrote: > At 10:29 PM -0500 2003/02/10, Rahul Siddharthan wrote: > > http://cr.yp.to/im2000.html > > OK, it's now 2003. Still, nice idea. If spam continues to grow at > > present rates, some such scheme may become necessary by 2010 or > > even earlier... > > Okay, so you're going to replace the e-mail system for the entire > Internet. You're going to go to local storage on the sender's > system, but then you still have to generate messages to be sent to > the recipients to tell them to come pick up their mail -- how do you > do that? It's even better than that. Assume you have smaller, fixed-sized messages: then what you are really talking about is that the sending machine is the storing machine, giving you two avenues of attack for a given host. If you assume that they aren't fixed sized, then you have to send variable-length location data along with the message, rather than using the peer identity in order to obtain the location of the message identified. At that point, the difference between sending a message to its destination and sending a notification of the location of a message to its destination, is moot: you can launch the same denial of service attack that you could launch if you were sending actual messages, rather than pointers to messages. If we go back to the fixed length message case, then you can launch exactly the same attack that the original message that inspired this thread: a flood attack. There are actually several advantages to the approach of sending messages about messages, rather than the messages themselves: 1) The amplification effect is reduced. Thus it is very hard to overflow someone's available space with big messages, as opposed to small ones, where you are overflowing their display client. 2) Messages are stored once, instead of messages being stored multiple times. This would be useful, for example, for an mail server where a large attachment is sent to multiple recipients, such that the recipients were not all listed on a single message instance (if they were a single instance, the server could coelesce them anyway, and store only a single copy). 3) You could replace the storage with a flood-fill mechanism, using a cryptographic storage system, so that the data could be replicated (e.g. "usenet"). This would make it much harder to do any but traffic analysis. 4) You can delete messages after you have sent them. 5) You get notification of the message being retrieved, with no way for the recipient to avoid it (I guess this is what Dan *really* wants out of this... ;^)), but it's not enough to serve court papers. Is this the only way to get these advantages? Not really; off the top of my head, it's obvious that: o Technically, you could probably do #2 anyway, if the mail server were to coelesce stored copies by message ID and matching MD5 hash, so it's not that great a deal. o The storage mechanism is kind of irrelevant, since it could be used anyway, for maildrops, without introducing new SMTP/transport semantics. For example, there is already a mechanism in the form of a MIME-Type that is an HTML reference which could implement this. o Why not just implement a distributed database backing store that could be used by aritrary front-end IMAP4 servers that could present views on it, and then use IMAP4 as the access mechanism fo clients? There are also numberous disadvantages; here are a few: 1) The problem with display, sorting, etc. of messages on various criteria still exists. For this to work, you would either have to pass along *minimally* all header information you would normally have passed anyway, OR you would need to contact every sending server everywhere, each time you perform a display update (which is impossible). 2) One possible sorting criteria is "message content" (e.g. I do not want to see messages whose bodies contain one of "the seven words you cannot say on television"). This would mean a need to access the complete message. 3) If the sending server store is offline, the message is unavailable, for the duration. 4) It is possible to "rewrite history", by changing the message on the storage server, after it has been seen. Fixing this required including MD5 or other cryptographic hashes, and even then you can only prove that the message that's there now is not the message that was there, not the contents of the message that *was* there. 5) The deletion "feature" assumes the recipient did not store a local copy. I suppose you could use Palladium for this? In that case, it destroys non-repudiation, which would make email useless for legally binding transactions. 6) The connections are outbound from the client to the message stores. This removes a level of firewall protection against incoming connections. While this is technically not any different than Microsoft Outlook, which starts sending messages to its rendering engine before having received the entire message body, for other mail clients that were written by qualified software engineers wo understand encapsulation, it makes them vulnerable to all of the "OutLook bugs" that users were only risking if they ran OutLook or similar clients. It effectively lowers the security bar to the least common denominator. 7) Etc. (I could go on for a very large number of these). > There are lots and lots of really big questions that haven't been > answered about this kind of solution. This list (from the bottom of > this page) is just beginning to think about scratching the surface: [ ... list ... ] These are all "doable" today, with existing infrastructure, no changes necessary, if you accept that the messages being sent are minimally the RFC822 headers, just without the normal body contents. > Indeed, I'd be interested to know if there is a single analog > anywhere in the world for this kind of system. 1) Lotus Notes. 2) Usenet, with cryptographically protected messages that can only be read by their intended recipient(s). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E498175.295FC389>