Does anyone has the specification of the NeXTMail format used by Mail.app ?
It seems to be based on MIME, but I'm not sure..
I remember seeing it somewhere a few years ago when people were trying to make it work with Gmail and ended up setting some crazy MS Exchange mirror that sat between the NeXT system and Gmail's servers.
Beyond that the url eludes me.
I did some investigation about 20 years ago and found NeXT Mail to be a uuencoded tar file. You'd probably have to write something custom to interoperate with it today.
I had it in my memory that it was a RFTD file, tarred, compressed and uuencoded. Compressed using compress (which makes .Z files). Or, you may think of it as a .rtfd.compressed.uu file where .compressed = .tar.Z).
However, the structure of .mbox directories on my NextStep 3.3 install CD appears to be:
(1) a table_of_contents file. As far as I remember, this is just a cache (index) which is automatically rebuilt if missing.
(2) a mbox file. This is a mbox format file containing all the messages. It contains all the mail messages (with headers) in ASCII text format appended together. A line beginning with the 5 characters "From " marks the beginning of a new mail message.
(3) Optionally, some directories named *.attach.
A NeXTmail appears to be a message with no body (blank body) and a header of the form
Next-Reference: <dirname>, 1/1
or sometimes
Next-Reference: <dirname>, , 1/1
<dirname> is one of the directories mentioned in (3) named *.attach. Its structure is that of a RTFD directory (i.e. an index.rtf file and any other "attachment" files it references). It contains the corresponding NeXTmail.
The 1/1 suggests that this field may sometimes be n/m where n and m are integers with 1≤n≤m, and the two commas suggest that other parameters may occur in those positions, but I don't have any such messages handy nor do I know if indeed other values were allowed there, or whether they were intended to be allowed in a future extension.
I'm now puzzled as to where my memory of tarring, compressing and uuencoding comes from. Presumably this must have been done before passing the message to sendmail as a single stream, or maybe this memory comes from .mboxes on earlier (pre-3.3) versions of NeXTstep. Perhaps someone else remembers.
NeXTmail/RFTD was a great and very simple mail message format, well fit for purpose and NeXT's Mail.app was a great app which always just worked. None of which can in my opinion be said of MIME/HTML/Apple Mail.app.
FYI, Mail.app on Mac OS X 10.6.8 does not open NeXTmail messages properly — they show as a blank message, presumably because Mail.app no longer understands the Next-Reference header. I'm not sure at what point this functionality was lost.
NeXTMail uses both formats.
When sending over internet it uses the uuencoded and compressed rtfd.
While doing the transfer from the system mailbox file in normal unix mbox format (with all attachmements still in the mbox file in uuencoded format) to the user mbox (NeXT format = directory) the NeXT attachments are extracted to the .attach directories and the message gets written to the mbox file inside the NeXT-mbox without the uuencoded part.
On the other hand mime attachments aren't treated that way. They are always kept in their base64 encoded format in the mbox file of the NeXT mbox.
Thanks to all for these information, I'getting closer.
Searching in maillist (which are NeXTMailBoxes)stored in the Files Section , I've also found a script in the MiscKit archives:
http://www.nextcomputers.org/NeXTfiles/Docs/Usenet/mailinglists/misc-kit/MiscKitArchive.tar.gzThe mail has the following subject: NeXT Mail from the Command Line
This script allow to create a NeXTMail with attached files.