access mbx files?

[David Isaac]

Should I be able to access mail messages in Mahogany mail's mbx

format using the Python mailbox module? If so, can someone

please post a working example? If not, can you please

point me to documentation of the file format or better yet

Python code to parse it?

Thanks,

Alan Isaac

 

[David Isaac]

Should I be able to access mail messages in Mahogany mail's mbx
format using the Python mailbox module? If so, can someone
please post a working example? If not, can you please
point me to documentation of the file format or better yet
Python code to parse it?

OK, from what I have been able to learn (not a lot),
my original question may boiled down to:
has anyone wrapped the cclient library for Python?

The answer to that appears to be yes:
http://freshmeat.net/projects/python-cclient/

Will I need to pursue this, or is this functionality
somewhere in the mailbox module. (And if not,
can someone please explain why not?)

Thanks,
Alan Isaac

 

[Donn Cave]

Quoth "David Isaac" <[email protected]>:
| |> Should I be able to access mail messages in Mahogany mail's mbx
|> format using the Python mailbox module? If so, can someone
|> please post a working example? If not, can you please
|> point me to documentation of the file format or better yet
|> Python code to parse it?
|
| OK, from what I have been able to learn (not a lot),
| my original question may boiled down to:
| has anyone wrapped the cclient library for Python?
....
| Will I need to pursue this, or is this functionality
| somewhere in the mailbox module. (And if not,
| can someone please explain why not?)

In the end it depends on what you want to do. But to simply read the
messages out of an MBX format folder, without necessarily accounting
for concurrent access from other applications, c-client is overkill.

If you look at the folder file - after the 4K header (2K? I forget),
the structure is <1-line-header><message>, and the header doesn't
carry a lot of information that's of supreme importance. The one
thing you want to extract from it is the length field, which allows
you to index to the next header. The message data is <CR><LF>. As
far as I can recall, that's all there is to it.

I suppose it isn't supported by the mailbox module basically because
it isn't all that commonly encountered. It may be more common on mail
servers, but there it's email net protocol data, POP or IMAP. If
Mahogany has been using this format for `local' folders (i.e., via
filesystem), I think that may have been kind of poor judgement on the
part of its developers.

Donn Cave, (e-mail address removed)

 

[David Isaac]

Donn Cave, (e-mail address removed)

I suppose it isn't supported by the mailbox module basically because
it isn't all that commonly encountered. It may be more common on mail
servers, but there it's email net protocol data, POP or IMAP. If
Mahogany has been using this format for `local' folders (i.e., via
filesystem), I think that may have been kind of poor judgement on the
part of its developers.

I cannot judge that, although I think I recall the choice was made
for reasons of speed. What do you see as the downsides?
Just that it is uncommon (and thus questions like my original
questions arise)?

Thanks,
Alan Isaac

 

[Donn Cave]

Quoth "David Isaac" <[email protected]>:
| Donn Cave, (e-mail address removed)
|> I suppose it isn't supported by the mailbox module basically because
|> it isn't all that commonly encountered. It may be more common on mail
|> servers, but there it's email net protocol data, POP or IMAP. If
|> Mahogany has been using this format for `local' folders (i.e., via
|> filesystem), I think that may have been kind of poor judgement on the
|> part of its developers.
|
| I cannot judge that, although I think I recall the choice was made
| for reasons of speed. What do you see as the downsides?
| Just that it is uncommon (and thus questions like my original
| questions arise)?

That's one problem, it's inaccessible to a wide variety of email
software you might want to run. Maybe worse, it's fragile. It
has, for no particular reason, a header full of NUL bytes, which
some editors will through away. Any change to contents without
the corresponding change to the header destroys the folder past
that point. Etc. And for all that, it doesn't buy you much.

Donn Cave, (e-mail address removed)