From: "Eric A. Hall" <ehall(_at_)ehsco(_dot_)com>
To: Tony Hansen <tony(_at_)att(_dot_)com>
The information about the mbox format being anecdotally defined is
incorrect. The mbox format has traditionally been documented in the
binmail(1) or mail.local(8) man pages (BSD UNIX derivatives) or mail(1)
man page (UNIX System 3/5/III/V derivatives).
I checked each of those and none of them seem to adequately describe the
message or database format.
Do you have a specific URL to a specific man page that you think would be
appropriate and authoritative?
There are plenty of man pages and documentation for UNIX mbox formats.
Outfits such as Netscape have figured the stuff out (painfully simple
as it is) to make libraries to deal with local mailboxes.
However, that seems irrelevant unless an auuthority ceeds change control
for the UNIX mbox format to the IETF. Never mind that the notion of
an authority that could exercise any authority over any UNIX mbox
format other than in its own source trees would be crazy. There's no
law that says Dragonfly, NetBSD, FreeBSD, OpenBSD, Linux, IRIX, HP/UX,
AIX, etc. and so forth and so on must have a common mbox format or
that they cannot switch to something better, not withstanding things
like that Netscape library. The old mbox formats are fine for a VAX-750
or 3B2, but are very bad ideas for more than a few hundred messages.
The most you could do is define your own interchange mbox format that
would by coincidence be extremely similar to one format such as the
System V or 4.3 BSD (I think I recall small differences between those
two), and tell implementors of your MIME type to convert into and out
of your format.
There is an overriding question. Where is the market demand for
an IETF standards track RFC defining a UNIX mbox interchange type?
Who would use it?
I can imagine "importing" and "exporting" mboxes, but not via SMTP.
Is anyone thinking about new code to convert among Netscape, Exchange,
and UNIX mbox mailboxes? Doesn't enough of that code already exist,
and doesn't all of it use transport mechanisms other than SMTP?
Isn't the IETF supposed to be about on-the-wire bits and keep its
noses out of host data structures?
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
Ietf mailing list