Alternate Java Client library to JavaMail?

Question

I'm running into a very strange issue. Basically what happens is that I'm using java mail to scan through a mailbox using IMAP, examining each email, looking for attachments and then reading the ones I'm interested in. The code works... Except on certain Windows 7 machines, but it works on most W7 machines.

What is strange is the exception (see below).

com.sun.mail.util.DecodingException: BASE64Decoder: Error in encoded stream: found valid base64 character after a padding character (=), the 10 most recent characters were: "am; name=9"
        at com.sun.mail.util.BASE64DecoderStream.decode(BASE64DecoderStream.java
:305)
        at com.sun.mail.util.BASE64DecoderStream.read(BASE64DecoderStream.java:1
44)
        at java.io.FilterInputStream.read(Unknown Source)

It seems that the base64 decode stream is trying to decode the attachement, but starts to read the base64 block at the part's header: the "am; name=9" in the exception seems to be the part in the header where the name of the file (starting indeed with "9") is defined.

Copied from the application's log: "Found attachement 90TXSJ.zip"

I've tried to find a hook into the mail code to get my hands on the InputStream to filter out the header some how, but that seems quite impossible.

So, is there another IMAP client implementation that does not use Java mail? Or does anyone know how I can get between the raw stream and the Base64 decoder?

Answer 1

An alternative that you probably didn't know about is Apache JAMES . Instead of polling an IMAP or POP3 email account, JAMES allows you to implement your own Mailet . A Mailet is the SMTP equivalent of an HTTP Servlet.

About a decade ago, I worked on a project that needed to integrate into the corporate infrastructure and auto-publish email content to a searchable database (opt-in, to make it easier to comply with reporting requirements). We initially attempted to go down the JavaMail path but we quickly ran into issues with scalability, security constraints, and robustness.

Installing Apache JAMES wasn't too difficult, and we could easily deploy updates to our mailet on the fly. In our case, we repackaged the incoming email into our own POJO and serialized that through a java message queue. We were able to distribute the actual processing load pretty well coming off of the queue.

The Mailet uses a Matcher which you define to determine if you want to process an incoming message or not. The Matcher makes its decision using the provided Mail object. If the matcher approves the message, it's sent to your mailet to process.

The Mail object contains access to the standard javax.mail.internet.MimeMessage which in turn has a getInputStream() for the decoded message and a getRawInputStream() to get the message as it was sent to the server. We maid use of these since we had to extract attachments, virus scan them, and then upload them to our searchable database associated with the right message.

I think you'll find a bit more freedom with this approach, as JAMES is an SMTP server and you don't have to hold mail in an inbox that needs to be periodically cleaned.