bpmail is very rudimentary, and major changes are planned:

• Turn bpmail into a LMTP daemon with local batch SMTP generation and processing
  Turning bpmail from a simple tool that can only interact with external mail programs through standard input and standard output, into a proper LMTP server removes the dependency on Exim for batch SMTP generation and processing.
  • A single application also addresses DTPC's constraint on only having one topic available for an application. Since bpmail currently consists of two applications, this requires an awkward set up of topic IDs for two ends of a link.
  • After LMTP is supported, SMTP support may also be considered.
• Helpful logging with syslog support
  bpmail does not perform any logging apart from outputting some messages to standard error when encountering errors. At the same time bpmail is transformed into a LMTP server, logging should also be implemented.

Beyond software, a major conceptual issue bpmail faces is how can a receiving bpmail process trust that the sender did not modify the message? As explained in a comment in pull request #25, the current approach using IPN records does not scale. Trying to solve this at the DTN level seems like it would need to solve DTN infrastructure as well, which doesn't seem well developed yet. It may be more productive to find a solution that does not require trusting the sending gateway, but how that can be done is unknown to the developers.