> From: "Eric A. Hall" <ehall@xxxxxxxxx> > To: Tony Hansen <tony@xxxxxxx> > > 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@xxxxxxxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf