Saving the content of the message (using getInputStream) without the headers
for the message is going to make it difficult to interpret the content later.
If you want to save the message, you should save the entire message using
the writeTo method. You don't need to create a new MimeMessage object,
although doing so has the side effect of using the writeTo method to "pipe"
the original message into the new message.
Note that the MimeMessage implementation was intended to handle two cases:
- parsing and reading an existing message
- constructing and sending/saving a new message
You're mixing the two cases together by "editing" an existing message and
trying to save it. I've made a number of improvements in the MimeMessage
implementation over the years to better handle this case, but if you
discover things that aren't quite working right, I won't be surprised. :-)
xoot123_at_yahoo.it wrote on 04/30/13 03:40:
> But correct me if I'm wrong: I'm always saving the message content getting the InputStream with MimeMessage.getInputStream().
>
> If I want to save the message again after having removed the attachments, must I create a new MimeMessage?
> Because it seems that getting again that InputStream (after the attachments have been removed) skips all the message
> headers and only writes the remaining parts - I get this
> in the table column:
>
> ------=_Part_4_1516214451.1367317248379
> Content-Type: multipart/related;
> boundary="----=_Part_5_1642009847.1367317248383"
>
> ------=_Part_5_1642009847.1367317248383
> Content-Type: multipart/alternative;
> boundary="----=_Part_6_1507160325.1367317248415"
>
> ------=_Part_6_1507160325.1367317248415
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
> [text content is here, part closing markers follow]
>
>
>
> Thanks again.
>
> M. R.
>
>
>
>
> ----- Messaggio originale -----
>> Da: "xoot123_at_yahoo.it" <xoot123_at_yahoo.it>
>> A: "users_at_javamail.java.net" <users_at_javamail.java.net>
>> Cc:
>> Inviato: Marted́ 30 Aprile 2013 10:02
>> Oggetto: Re: removing attachments from locally stored message
>>
>> T hank you very much!
>>
>>
>>
>> M. R.
>>
>>
>>
>>
>>> ________________________________
>>> Da: Bill Shannon <bill.shannon_at_oracle.com>
>>> A: xoot123_at_yahoo.it
>>> Cc: "users_at_javamail.java.net" <users_at_javamail.java.net>
>>> Inviato: Luned́ 29 Aprile 2013 20:52
>>> Oggetto: Re: removing attachments from locally stored message
>>>
>>>
>>> xoot123_at_yahoo.it wrote on 04/29/13 11:33:
>>>> Hello,
>>>> My application offers the possibility to save emails from IMAP accounts
>> to a
>>>> local database.
>>>> Later on, the user can remove the attachments from those saved
>> messages, with
>>>> two options:
>>>> a) remove the original message;
>>>> b) keep the original message.
>>>>
>>>> The whole original message is saved locally, meaning that an
>> OutputStream is
>>>> used to write the message (writeTo()) to it and from that an
>> InputStream is
>>>> obtained that populates a BLOB column.
>>>>
>>>> The problem is, in case (b) I can only create a MimeMessage from the
>> saved
>>>> stream, with new MimeMessage(null, myInputStream).
>>>> The new message is passed to a method that removes all its attachments.
>>>> I saw that when removing the attachments (and precisely when
>> saveChanges() is
>>>> called) all the MimeMessage internal stream references are nullified,
>> so that a
>>>> call to getSize() returns -1.
>>>>
>>>> Since I need to store the message size on the database, along with
>> other
>>>> informations, the only solutions I found to make JavaMail give me that
>> is to
>>>> create a new MimeMessage from the attachments-removed MimeMessage.
>>>>
>>>> So, to sum it up: <database column> -> msg = new
>> MimeMessage(null, myIS) ->
>>>> removeAttachments(msg) -> newMsg = new MimeMessage(null, msg).
>>>>
>>>> Are all those steps necessary or is there a more efficient way to do
>> this?
>>>
>>> It would be very complicated to keep track of the final size of a message
>>> after each of those "edits" to the message, so JavaMail
>> doesn't even try.
>>>
>>> The technique you're using is implemented by "serializing" the
>> entire message
>>> to a MIME byte stream, then deserializing the message to create a new
>>> MimeMessage object. If all you want is the size, a more efficient approach
>>> is to serialize the message (using writeTo) to an OutpuStream that does
>>> nothing with the data but counts how much data is written. After writeTo
>>> is done, ask the stream how much data was written.
>>>
>>>
>>>
>>>
>>