The base64-decoder doesn't work on 64-bit big-endian architectures:
mhstore and co. write files of the correct length but which consist
only of \0s.
The culprit is uip/mhparse.c, which contains a pretty ugly base64
decoder (in two places). that thing allocates a "long int" as a
container for the 24 bits that you get from four base-64 chars. the
container is then accessed both as a single entity and as a byte
array, which naturally depends on how wide the long int is and in what
order things end up in there.
The code distinguishes between big- and little-endian systems but
wrongly assumes that sizeof(long int) == 4, which isn't universally
true (quel surprise...).
The attached patch fixes the issue, but in the long run we should
insist on posix and use a64l().