Received an email yesterday from a user who wasn't able to get Mail::Transport::Dbx to work. It turned out that the mailbox he wanted to parse was created with Outlook Express on a Macintosh and he tried to process it on a different machine running RedHat.
On installation time, the module figures out the machine's byteorder and then uses either -DDBX_LITTLE_ENDIAN or -DDBX_BIG_ENDIAN when compiling the underlying C-library.
So the poor chap ended up with a module compiled for a little-endian machine trying to process a file in big-endian byteorder (I assume that Outlook Express writes them that way on a Mac). If that eventually turns out to be the reason for the failure, I have again some work to do: Making the byteorder conversion configurable at run-time which means that I can no longer use my convenient C-macros for it.
The lesson to learn from that: There's always at least one case a programmer wont anticipate. It might be as esoteric as it gets...it's still going to happen after a while.
Maybe not so exotic? (Score:1)
(For what it's worth: "Entourage", the successor of OE, at least implemented a "drag and drop to mbox" feature.)
Re:Maybe not so exotic? (Score:1)
Well, M::T::Dbx is supposed to work with these proprietary files. It expects to see files with the
But your point isn't totally invalid. Whenever I receive mails like that, I never exclude that the user made something wrong. It's usually the first thing I try to rule out in the following mail co