Tim Bray on TEN-like Solution

In "Another Whack at Spam", Tim Bray describes a solution similar to my Trusted E-mail Network (TEN) idea (also read "Fixing E-Mail") – via Dave whose blog I read before Tim's blog.  He arrived at the solution while talking about spam at Foo Camp with Jeremy Zawodny, Dave Sifry, and Doug Cutting.

He also thinks digital signing should be done by mail servers instead of users.  But his thinking differs from mine in how the trusted network of mail servers should be organized and the network's relationship with mail servers outside the network.  I believe the network should be backed by a business entity in charge of issuing and revoking certs to member mail servers, maintaining and providing trust rating information on mail servers and mail users, etc.

While I like loosely-coupled peer network as much as anyone, I believe PKI and responsiveness requirements call for a central authority.  Under Tim's solution, each mail servers are given too much room for misbehavior and removal of a rogue mail server takes too much time.  What I want is the ability to shutdown a rogue user or mail server within hours, not days.

Update #1 – 10/13/2003 11:15AM PST

Liz Lawley raised some key concerns that reminded me to fill in some missing pieces of the TEN model.

Open Source

Since there is nothing proprietary about TEN servers, there will be plenty of open source TEN-enabled mail servers and TEN-enabling patches for popular open source mail servers.  So TEN servers will be very affordable.

Private E-Mail Network

TEN servers should be able to use multiple PKI.  This means each TEN server will have multiple certs to sign e-mails with depending on the source and the destination of each e-mail.

If the mail exchange is completely within an organization, the message can be signed with a self-signed cert after checking to see if the sender meets the private TEN's trust rating requirement.  For mail sent outside the private TEN, a public TEN cert assigned to that TEN server should be used but only if the mail sender has sufficiently high TEN rating.

Free or Subsidized

A Private TEN does not have to charge fees.  For example, American universities can form a national private TEN, with each university or department running their own TEN server, that allows students and staffs from any of the member universities to exchange e-mail with each other without a fee.  Some universities could even sponsor some percentage of the fee for e-mails sent outside the University TEN.

Global Trusted E-Mail Network

While anyone can run a TEN server, not everyone will be able to get a Global TEN cert that enables e-mails to be trusted by anyone world-wide.  There are three ways to get a Global TEN cert:

  1. Implicit Trust – you are trusted without doubt or reserve
  2. Bonded Trust – you put up money to be trusted
  3. Sponsored Trust – you are trusted by someone with a Global TEN cert.

Implicit and bonded trusts are obvious so I won't go into details about them unless someone asks.  Sponsored trust means a there is relationship between the sponsoring organization and the sponsored.  Each trusted mail sent from a sponsored organization affects both organizations if a complain is lodged against the mail.

For example, if a Stanford physics student sends out a mail with virus to someone, trust rating of Stanford Physics Department's TEN server and Stanford's TEN server will be degraded because the school sponsored the department.  If Stanford is a member of American University TEN, then the American University TEN's trust rating is degraded.

Berkeley DB XML License

I have been thinking about using Sleepycat Software's Berkeley DB XML (BDBXML), the speedy open source XML database behind Kimbro Staken's XPath-happy prototype blogware, Syncato.  BDBXML license was confusing to me, particularly the word "redistribution", so I contacted them yesterday to find out if I could use it for free.

My situation is a common one in that I will have a single server driving several websites and web services, some of which will be commercial.  More servers might be added later, but still located at a single data center (ServerMatrix).  BDBXML license allows free use under this situation.  But the software that runs on my server(s) is being written at home which is in a different state.  Since my development machine is in California and my production server(s) are in Texas, I am in fact redistributing whenever I upload my software to the server(s), violating free use under BDBXML license.

Liz Pennell, Account Executive at Sleepycat Software, confirmed this but, recognizing that this might discourage developers from developing software based-on their new product, they graciously granted me free license.

Hi, Don,

I'm sorry for the delay in responding to you, but I wanted to discuss your case with some of my colleagues here.

In fact, if the development is at your home address and the hosting server is at a different postal address, the use you contemplate would typically be considered a redistribution event under the terms of our public license. As such, in the interests of applying the rules even-handedly across our user base, we'd need to specifically permit that use rather than just wink at it, if that makes sense.

However, I agree with you that this sort of use at least in spirit comports with the public license terms, as the software is only installed and performing useful work at a single physical site. It's also true that DB XML is still a young product, and we'd like to do what we can to promote its wider adoption.

Therefore, in this specific case given all the circumstances as detailed, I'd be willing to grant you a limited single-site exception to clause 3 of Sleepycat's public license, and permit your use, as described below, at no charge.

Since I knew my situation is far from unique, I asked Liz whether this exception was a general exception (?!?).  Her reply was:

I'm reluctant to commit to making this exception broadly into the future, but it's not something you need to keep secret. If an individual web site developer came to us at this point in the product's life, and described the kind of use that you're considering, we would be very likely to make the same call for the same reasons.

However, it wouldn't be prudent to assume that this will always be so, and we'd need to make the explicit judgment on a case-by-case basis every time.

There you have it, a Selective Early-Bird Special of sort.  If you are a developer in a similar siutation as me, you know what you should be doing right now.  Here is the e-mail address.

I have a feeling that Sleepycat's mailboxes will be full by Monday.  Sorry to wake you, Sleepycat.  Heehee.

Update – 2004/02/19:

Here is an update from Liz on the license which made a lot of sense to me:

Since nothing ever dies on the Net, I thought it was important to get back to you on the subject of qualification for free use of our software under Sleepycat's public license. My interpretation of the public license when you and I had our original e-mail exchange was actually too strict.

In fact, "redistribution" happens when a copy of Berkeley DB is installed *for actual use* on more than one physical site. In practice, this means that developers may build apps at multiple sites, or at a different site from where the application will be installed, because during the development cycle the application is not installed for actual use. If the application is installed for actual use at a single physical site, it qualifies for free use of Berkeley DB under the public license, regardless of where it may have been developed.

Thumbs Down on Red Hat 9

I spent a good part of today trying to setup mail server on my remote Red Hat 9 machine.  It came with sendmail which everyone agrees is a bloated sloth so I replaced it with Postfix using the instruction given in this document which probably represents the daily life of a Linux user.  No problem there.  I have heard that Maildrop and Courier IMAP combo was a good match for Postfix, so I looked for the RPMs via Red Hat's up2date.  Nothing.

I managed to find the source for Maildrop and tried to configure the build.  Nope.  cpp, C preprocessor, was not installed.  Again, not available via up2date.  Got it via rpmfind.com and installed OK.  Back to configuring Maildrop.  OK again.  Now build fails because g++ is missing.

Earlier, I had to install gcc-compat package because my server came without gcc installed.  Funny.  Apparently, that gcc-compat package didn't include g++.  Latest gcc-compat available on RH9 was an old version of gcc also.  So I considered whether to replace gcc-compat with the latest gcc package from gnu.org.  gcc-compat is an ominous name.  It implies that regular version of gcc is not compatible for some reason.  I punted and rigged Postfix to forward mail to my personal e-mail account with my ISP [1].  Urgh.  I didn't even get to Courier IMAP.

Red Hat distributions seems to have, in general, oddities that cause problems with many packages out there despite being the most popular Linux distribution.  Versions of packages bundled in Red Hat distributions or available for download via up2date are often much older than the latest.  Sometimes this can be dangerous.  For example, latest OpenSSL package available by up2date was 0.9.7a which has serious bus including the ASN.1 bug.  Red Hat 9, in particular, is a bundle of trouble because it uses NPTL library unlike other versions and distributions.

Stay away from Red Hat 9 everyone.  If possible, stay away from other versions as well.  Whatever performance NPTL brings, I can make it up more than enough by getting another cheap Linux box.

PS: Only bright spot in all this is the joy of using Webmin.  It really is great although documentation sucks.  There are so many great Webmin modules out there that one can only smile with satisfaction.

[1] One stupid Linux trick I learned was that in order for 'luser_relay' setting to work, you have to define 'local_recipient_maps' to be nothing.  Leaving it commented out is not the same.  What kind of talented idiots write sh*t like this?

Hangul: Invented 557 Years Ago Today

Thanks to James for reminding me that today is Hangul Day, the day Hangul was invented by Sejong-Daewang (King Sejong) in 1446.  Hangul is an awesome language from an engineer's point of view.  More on the history of Hangul can be found at the Sigma Instutude.

Thanks to the Internet, Hangul is changing today.  Young Koreans are morphing and evolving the language to fit the their needs and taste as they communicate in Hangul online.  Some say they are destroy the language, I think otherwise.  I believe some characters from English and other languages should be added to Hangul so one could write like this:

Otherwise, Hangul version of Very Much end up sounding like Berry Match.

Addition of the new characters to Hangul will start a chain reaction of exciting/frightening changes, starting with the spoken language (Korean), brain that uses the language to think and dream in (Korean mind), and the society that uses it (Korea).

Yes, I am saying that brains of people who speak different languages are wired differently.  What I think and feel in Korean is different from what I think and feel in English.  If this is not true in general, at least it is true with me.

Update #1 – 10/11/2003 10:25AM PST

What I like about Hangul is the neat design.  Each Hangul 'word' has exactly one vowel.  A word consists of starting consonant (), a vowel (), and optional ending/connecting consonants ().  To stress a consonant, double up (i.e. vs. ).   means Flesh and means Rice.  Vowels can also be combined to get the sound made with mouth shaped somewhere between the mouth shapes of the two vowels used in combination like this:.

Hangul keyboard has consonants grouped on the left side and vowels on the right side so that Hangul typing alternates between hands.  It's the end sound complicates things a bit.  End sound of a Hangul word can use up to two consonents to represent a wide variety of sounds.  Since the end sound is followed by the starting sound of the next word, one can get confused about how to divide up the consonants.  I often mess up this part.

Isn't Hangul neat?  King Sejong is my favorite geek.

No More AdSense

Since I got Google AdSense, I enjoyed watching a small pile of money build up.  It wasn't much but it was enough to offset my webhosting expenses.  Thanks to the Gag clause recently added to AdSense T&C by Google, I removed AdSense from this blog.  According to AdSense FAQ, this effectively cancels the account.

Dave wrote:

Google ad bar is a huge disclaimer saying "I can't talk about Google."

I agree.

Open Source Java Projects

I visit Carlos E. Perez's Manageability blog about once a week because he occasionally posts useful list of open source Java projects along with terse yet revealing comments.  I thought it might be useful to list the lists.

Carlos is a bit heavy on the Java cheerleading, but these gems are worth the visit.

Sonoma and TEN

I used to frequent Sonoma coast and Napa when I was single.  Monterey too.  It's not that I liked the scenery.  Being young and hot blooded doesn't leave much room for the scenery.  I usually went there with girls I dated so I can score.  Dating is fun, but waiting is not.  It's silly to travel somewhere and sleep in two rooms.  So a yes was a meaningful yes, oh yeah.  Sometimes I miss being a shallow bastard with a one-track mind.

Tim Oren is back from his Sonoma run and makes some nice suggestions on places to go there.

Tim also comments on my Fixing E-Mail post and my response to his metadata rant.  Tim points to Postini, champ of his portfolio, as an example of new e-mail technologies that will rescue us from spammers.  Cool.  I wonder where they got the name Postini?  Houdini?  'Ini' is a bit too addictini IMHOini.

Here is a bit more on the trusted e-mail network idea:

A Trusted E-mail Network (TEN) is a PKI network of mail servers.

Every message sent is signed by the originating TEN server to identify the sender.  Performance degraded by crypto operation is offset using crypto hardware and meaningful application of mail priority.  Ultimately, slower means more protection against spammers.

Only TEN users can send e-mail from a TEN network.  Anyone can receive a TEN e-mail.

Every TEN user is identified and the user's profile is maintained actively by at least one TEN service provider.  Each complaint against the user affects the user's profile as well as the profile of the organization sponsoring the user and the TEN service provider.  Variouis types of penalties affecting the quality of service are applied to the offending user or organization according to their profiles.  TEN service providers that fail to maintain required level of service are ejected from TEN.

Quality of identity is maintained by payment.  New subscribers start at the ground level.  A side benefit from time-based quality of identity is reduced turnover within the network, that is they can maintain their quality of identity only if they change service within the network.

That's it for now.  I am still thinking about TEN, but I had to spew just now because I need a refreshing drink of peer criticism.  You wouldn't give TEN a Ten, would you?  Heh.  When I briefly dug into sendmail, I was surprised to find it almost ready for TEN.  With a bit of codeworks and a load of capital, TEN could be Visa for e-mails.

Update #1: 12:26PM

TEN differs from S/MIME-based solutions because it doesn't require the sender to have a user cert which must be issued, installed, revoked, and checked, the nightmare that brought down lofty dreams of PKI.  With TEN, all that requires is for the sender to add a SMTP server to his e-mail client because it's the user's TEN server that signs the e-mail, possibly in S/MIME format.

To the receiver, it doesn't really matter who signed the e-mail as long as someone trustworthy did.  Non-repudiation can be provided as a value-added TEN service that requires stronger authentication methods.  Receipient feedback to the originating TEN server can be done in several ways including attaching a message-specific URL to the end or a Click Here to Kickass hyperlink.

A typical TEN user will have two SMTP accounts, a TEN account and a junk-mail account.  Because e-mails sent via TEN account is fee-based, the user will use the junk-mail account for unimportant messages and subscribing to mailing lists.  For important e-mails though, the user will choose to use TEN.

A TEN account should cost around $20 to open so everyone can get a TEN account just in case.  There will be a low monthly maintenance fee with reasonable monthly traffic allowances.  traffic-overflow can be sold per message or by bulk.  Spammers can't abuse the system because bulk e-mail is trickled initially, giving enough time for complaints to flow back to the TEN server, squashing the remainder and slapping the sender around.