RSS versus Email List Servers

1. Spam filters. Spam and the resulting overly aggressive spam filters are killing mass email.
2. Flaky mail service. Mostly related to the first point, but at least one of the largest mail service providers are silently dropping messages on the floor. I know Apple's .Mac has some sort of server-side spam filters going, but I'm unsure if they act the same way, or correctly return a SMTP-level "message not delivered" error.
3. Ease. Running an RSS feed is much easier than running a mailing list server. Essentially, if you have a public web site, you can have an RSS feed without any additional software. This is a big deal, especially since mailing list software is notoriously bad.

The downsides I see:

1. Not widespread (yet). The user experience isn't horrid, but it's definitely non-optimal. A newbie to RSS has to:
   1. Figure out what RSS is all about. Most folks that talk about RSS, myself included, wrongly assume their audience has a clue what RSS is and what benefits it offers.
   2. Discover what clients are available for their platform.
   3. Decide upon a client.
   4. Download and configured the client.

   While there are those who believe RSS readers will be (or should be) integrated into web browsers, I beg to differ. I think RSS fits the email client model ("subscriptions" map onto "mailboxes", "entry title" maps onto "Subject" while message body is a one-to-one) much better than the web browser model (pages and bookmarks). In any case, I predict this will be solved within a reasonable time.

2. More bandwidth usage. RSS desktop clients are in their youth, and still are growing up. Just until recently, my favorite RSS client requested a complete page download every time a subscription was polled. Now, HTTP HEAD and conditional GETs help out here. However, RSS is polling, and polling is — by definition — inefficient. (Little more on this below.)
3. Creates a traffic focal point. With list servers, you send out one message per subscriber per posting. Since you control the outgoing mail server, you can throttle your bandwidth as you see fit. In addition, the polling load (users polling their POP3 or IMAP accounts) is distributed among all your subscriber's mail servers.

   Such is not the case for RSS. All your subscribers are polling your server directly — you don't enjoy the polling buffer that is your subscriber ISP's mail server. In addition, you don't have much throttling options. While RSS (at least 0.92) includes provisions for "blackout" periods, you're still subject to potentially expensive surges of traffic.

4. Not appropriate for discussions (yet). While there are already protocol extensions in existence — without doubt more in the works — RSS is not appropriate for a discussion-style email list server.

Update: An interesting back-of-the-envelope calculation surprised me. FeedReader seems to be the most NetNewsWire-like RSS client for Windows. However, unlike NetNewsWire, FeedReader sets a default polling interval on all your subscriptions — it's set at 15 minutes. If your RSS file is 10K, and FeedReader doesn't do conditional GETs (or your server always vends a dynamically generated RSS file, like rentzsch.com currently does), that's 24 hours * 4 times per hour * 10K = ~1MB per day, per subscriber. Yikes!

Sunday, January 26, 2003
12:00 AM