JavaMail/MimeBodyPart question

[Martin Gregorie]

I have a JavaMail problem that has me stumped. I'm trying to build and
send a MIME message containing:
1)a text/plain part containing text describing the following part
2)a message/rfc822 part containing a complete mail message which
can be MIME or plain text.

The message is being built and dispatched OK - I can read it with
Evolution, see the plain text and open the attachment, but the latter is
somewhat mangled. Here's the code I'm using the assemble the part.
'headerText' contains the headers for the message that will form the
attachment, 'bodytext' contains the complete MIME body of the message
and 'name' contains the name to be used for the attachment (its actually
the subject line). The body and headers are separated because that was
the easiest way to retrieve them from a JavaMail Message. Here's the
method that builds the part:

public boolean addMessagePart(String headerText,
String bodyText,
String name)
{
boolean success = true;
MimeBodyPart b = null;
StringBuffer s = new StringBuffer();
String mt = new String("message/rfc822");
String fn = null;
String cv = null;


if (name.length() == 0)
{
fn = new String("no_name.eml");
cv = new String(mt);
}
else
{
fn = new String(name + ".eml");
cv = new String(mt + "; name=\"" + fn + "\"");
}


try
{
s.append(headerText);
s.append("\n\n");
s.append(bodyText);


b = new MimeBodyPart();
b.setText(s.toString());
b.setDisposition("attachment");
b.setFileName(fn);
b.removeHeader("Content-Type");
b.addHeader("Content-Type", cv);
body.addBodyPart(b); /* body is a class member */
msgReady = true; /* msgReady is a class member */
}
catch (MessagingException e)
{
error = e.getMessage() + " adding message part";
success = false;
}
return success;
}

However, when I look at the attachment with Evolution it is displayed as
plain text, not an attached mail message. This is evidently due to
additional headers that have been injected somehow. Here's what I get on
the receiving end:

------=_Part_0_26953436.1190840435551
Content-Type: message/rfc822; name="Revision to Your Alibris E-mail
Address.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Revision to Your Alibris
E-mail Address.eml"

From:
Date: Wed, 26 Sep 2007 22:00:50 +0100
Subject: No Subject

>From Alibris Customer Service <[email protected]>: From Alibris

Customer Service <[email protected]>
.........

Analysing this part of the message, which is the start of the part
containing the attached message:
- The first block (lines 1-5) are what I'd expect: the MIME part
headers as I intended them to look.
- The second block (lines 7-11) were not output by my code.
- The third block is the first header line in the message
forming the contents of this MIME part.

The message id in the second block, which contains the hostname of the
laptop I'm reading the mail on, indicates that this block was injected
somewhere between my Postfix MTA and my Evolution MUA. The transfer path
is JavaMail -> Postfix -> Dovecot -> Evolution. So, what I'd appreciate
help with are the following:

- what has added these headers?

Postfix isn't doing it: I've looked at the message (captured by
an 'always_bcc' instruction in Postfix). The 2nd block of
headers isn't present in the BCC copy.

Some time back I tested this code and then put it to one side.
It used to work correctly. About all that has changed since then is
that Dovecot has been upgraded. I have not upgraded Java, JavaMail
or Evolution during this period.

- is there anything I could/should be doing to the MIME part to prevent
downstream processes from mutilating my attachment?

Is there a way to encode the attachment so that it doesn't look like a
message (e.g Base64 encoding) but that will still allow a mail reader
to view it inline? If so, I'd like to know the name of the Java class
and package.

 

[Roedy Green]

String mt = new String("message/rfc822");

write that as
String mt = "message/rfc822";

see http://mindprod.com/jgloss/newbie.html
;

 

[Roedy Green]

fn = new String(name + ".eml");

write that simply as
fn = name + ".eml";

 

[Roedy Green]

s.append(headerText);
s.append("\n\n");
s.append(bodyText);

Don't do this. Use JavaMail methods to put the message together.
You are mixing low and high level code.

See http://mindprod.com/products1.html#BULK
for sample code.

 

[Martin Gregorie]

Don't do this. Use JavaMail methods to put the message together.
You are mixing low and high level code.

Good idea, but it does raise a few problems.

It looks as if I can get the complete message, which is what I want, by
extracting the content with getContent() and storing in in a BYTEA
(Postgres BLOB) via a Blob object. That process can easily be reversed
to make it into a MimeBodyPart attachment with setContent().However, I
also need to search the message body when its in the database. Can a
BYTEA be searched in SQL, e.g. with a LIKE or ILIKE search term? The
Postgres manual implies that you can't.

If I used a Clob (as suggested by Peter Forneau in a slightly different
context) I could map it to a TEXT, which would then be searchable, BUT
there seems to be no easy way to store a byte array, which is what
MimeMessage.content is, other than first converting it to a String.

Have I missed anything here?

 

[Lew]

It looks as if I can get the complete message, which is what I want, by
extracting the content with getContent() and storing in in a BYTEA
(Postgres BLOB) via a Blob object. That process can easily be reversed
to make it into a MimeBodyPart attachment with setContent().However, I
also need to search the message body when its in the database. Can a
BYTEA be searched in SQL, e.g. with a LIKE or ILIKE search term? The
Postgres manual implies that you can't.

If by "implies" you mean "states that LIKE operates on strings", then yes, it
does, since BLOBs are not strings, as explicitly stated by the pg manual:

Binary strings are distinguished from character strings by two characteristics:
First, binary strings specifically allow storing octets of value zero and other
"non-printable" octets (usually, octets outside the range 32 to 126).
Character strings disallow zero octets, and also disallow any other octet values
and sequences of octet values that are invalid according to the database's
selected character set encoding. Second, operations on binary strings process
the actual bytes, whereas the processing of character strings depends on locale
settings.
Continuing:
If I used a Clob (as suggested by Peter Forneau in a slightly different
context) I could map it to a TEXT, which would then be searchable, BUT
there seems to be no easy way to store a byte array, which is what
MimeMessage.content is, other than first converting it to a String.

Have I missed anything here?

You've missed that a String is not just a sequence of bytes, it's a sequence
of /encoded/ bytes. You have to play games with character encoding to make a
String properly hold binary data. It's not recommended.

Since LIKE is a character operation, it won't work on BLOBs in any SQL dialect.

 

[Roedy Green]

an a

BYTEA be searched in SQL, e.g. with a LIKE or ILIKE search term? The
Postgres manual implies that you can't.

see http://mindprod.com/jgloss/sql.html#TEXTSEARCH
The catch is SQL is not a rigid standard. You have to dig in your
implementation manuals for how to pull it off.

 

[Martin Gregorie]

You've missed that a String is not just a sequence of bytes, it's a
sequence of /encoded/ bytes. You have to play games with character
encoding to make a String properly hold binary data. It's not recommended.

No, I'm aware of that. Likewise that a mail message is a string of bytes
that matches a specific character set. Do you know if the sequence:

MimeMessage.content (byte array) -> String -> pg.TEXT field -> String ->
MimeBodyPart.content

is likely to leave me with identical byte arrays?

It looks like the easiest way of doing this is to extend MimeMessage by
overriding getContent() to return a String, which is loaded into the
TEXT field. Retrieval would be to a String which is converted to a byte
array and loaded into a MimeBodyPart via the InputStream constructor.

As always, what have I missed here?