Chris Adams

Mac Net Journal notes an amusing comment in the Eudora beta changelog:

One of the more humorous comments from the release notes: "Support for receiving Apple's made-up-we-don't-need-no-stinkin-standards x-folder"

I too found this humorous but for different reasons: the Eudora developers have a history of making snide remarks about other programmers' work but for some reason all they've produced after years of effort is a buggy, unreliable, ugly program which requires a great deal of user training - both for the cruft-heavy interface and how to ignore or workaround the bugs you'll encounter on a regular basis. It is particularly amusing that the Eudora developers had the chutzpah to criticize anyone else for not following standards given that I had to spend time earlier this week writing a short Perl program to clean up Eudora mailboxes so we could import them cleanly into Maildirs for our IMAP server:

Eudora omits fields like Date or Message-ID from sent or FCCed messages. Both of those field were defined in RFC 822 back in 1982 - Date is even a mandatory field.

Eudora nominally uses the mbox format (which dates back to 1976 and the release of AT&T; Unix Version 6) for saved mail but even that has problems - the From separators use a bogus address (???@???) instead of the actual from address in the message and there are occasional oddities in the date format, too.

Finally, Eudora likes to strip attachments out of the original message (which complicates migration, backups and the use of multiple clients - the entire point of using IMAP) and it frequently corrupts the messages by stripping the MIME separators while leaving the multipart headers intact - sometimes even leaking portions of the MIME separators into the body of the message. Amusingly, this produces a message which will display in every mail client I've tried - Mail.app, Mozilla, and mutt - except Eudora. I'm very pleased to see we're getting something for our license fees...

It turns out that using multipart/x-folder to attach entire directories to a message isn't original to Apple - it dates back at least to NeXTSTEP 3.3 and it's compatible with the standards - quite unlike, say, Eudora. RFC 2045 specifically allows proprietary subtypes as long they're prefixed with X- to prevent conflicts with future standards:

  Beyond this syntax, the only syntactic constraint on the definition
  of subtype names is the desire that their uses must not conflict.
  That is, it would be undesirable to have two different communities
  using "Content-Type: application/foobar" to mean two different
  things. The process of defining new media subtypes, then, is not
  intended to be a mechanism for imposing restrictions, but simply a
  mechanism for publicizing their definition and usage. There are,
  therefore, two acceptable mechanisms for defining new media subtypes:

  (1)  Private values (starting with "X-") may be defined
     bilaterally between two cooperating agents without
     outside registration or standardization. Such values
     cannot be registered or standardized.

  (2)  New standard values should be registered with IANA as
     described in RFC 2048.

Somehow I'm having difficulty working up much sympathy for the programmer who whines about a rarely used vendor extension they chose to support but hasn't managed to find a few minutes during the last 15 years to make their program compatible with two of the most widely used standards in computing...