But what's the point? If you want to read RSS in your email, it's not particularly hard, so what would be the point of coming up with new formats and adapting newsletter software?
Here's an analogy for the current "way of things" in email-land: imagine if, instead of a web browser, you just had a database view into an HTTP cache: a list of URLs retrieved recently, each of which, when clicked, rendered as an HTTP "message." (Imagine a file-folder full of MHTML archives, basically.) At the top, there would be an address bar--but, when you entered an address into it, it would simply retrieve a new item into the cache, which you would still have to click into to look at. It wouldn't be very obvious at all how to build something like an AJAX web-app on top of this, because, although the protocol is compatible with it, the representation is too low-level.
As a user of a web browser--an abstraction over HTTP messages--you don't care about each individual HTTP response; you only care about pages. Sometimes an HTTP response will deliver you new pages; sometimes it will modify a page already loaded. Web browsers only still really use HTTP at all because the verb set (GET, PUT, POST, etc.) so closely aligns with the things people want to do on the web. It's an excellent protocol for generic RPC between machines, that also happens to be usable directly by humans to GET web-pages. Now, why doesn't anyone see that SMTP+IMAP are an excellent protocol for doing publish/subscribe between machines, where real humans happen to also be able to (and already do!) PUBLISH and SUBSCRIBE?
The advantages of making a protocol an abstraction over email are manifold:
1. the messages are stored in the receiver's email inbox--a universal resource that everyone has [and understands the purpose of!];
2. all messages can be processed using the same "utilities" we use for email (backup utilities especially);
3. the ports for SMTP, POP3 and IMAP are almost always open inside corporate firewalls, just like the ports for HTTP;
4. and all messages you send through those protocols will get passed through email infrastructure (which is big and robust and reliable, and, most important, already exists)--and, in the process, can get forwarded, multiplexed across mailing lists, thrown out as spam, and all the other convenient things riding on email infrastructure gives you for free.
As a user of a web browser--an abstraction over HTTP messages--you don't care about each individual HTTP response; you only care about pages. Sometimes an HTTP response will deliver you new pages; sometimes it will modify a page already loaded. Web browsers only still really use HTTP at all because the verb set (GET, PUT, POST, etc.) so closely aligns with the things people want to do on the web. It's an excellent protocol for generic RPC between machines, that also happens to be usable directly by humans to GET web-pages. Now, why doesn't anyone see that SMTP+IMAP are an excellent protocol for doing publish/subscribe between machines, where real humans happen to also be able to (and already do!) PUBLISH and SUBSCRIBE?
The advantages of making a protocol an abstraction over email are manifold:
1. the messages are stored in the receiver's email inbox--a universal resource that everyone has [and understands the purpose of!];
2. all messages can be processed using the same "utilities" we use for email (backup utilities especially);
3. the ports for SMTP, POP3 and IMAP are almost always open inside corporate firewalls, just like the ports for HTTP;
4. and all messages you send through those protocols will get passed through email infrastructure (which is big and robust and reliable, and, most important, already exists)--and, in the process, can get forwarded, multiplexed across mailing lists, thrown out as spam, and all the other convenient things riding on email infrastructure gives you for free.