Android Question MailParser overwriting text blocks

[drgottjr]

i've read through posted issues regarding the MailParser. i didn't spot one which corresponds to what i've encountered:

if the mail has more than 1 text block (eg, in a multipart message), the last block processed with overwrite any previous block processed.

the HandlePart() sub of the parser, for example, is passed a block of data (Body as string) for processing.

... If Regex.Matcher2("Content-Type:\s*text/html", _
Regex.CASE_INSENSITIVE, Headers).Find Then
Msg.Body = Body

(Msg is the object which is ultimately returned to the main part of the app.)

as a result, in cases where there is more than one instance of a text block, the last block processed with overwrite any previous block processed. in my case, i changed the assignment shown above to:
msg.body = msg.body & "<br>" & Body

which did the trick. for text/plain, i use CRLF to join multiple blocks. i'm wondering if anyone else has encountered the problem. and if anyone might want to suggest a better one to handle it. thanks in advance.

-go

 

[Erel]

Your solution looks good. If there were many text blocks then it would have been more efficient to use a StringBuilder. However for a few text blocks it doesn't matter.

 

[drgottjr]

yeah, thanks. instead of stringbuilder maybe a list, as was done for attachments.

for what it's worth, i've also added a date field and an id field to the message object. the id field allows me to delete mail at my convenience rather than having to commit one way or the other before downloading the messages. sometimes i want to leave a particular message on the server to deal with it later on my desktop where i can type a reply more easily. i understand i could just as easily leave everything on the server until i get to my desktop.

one other matter - if anyone is curious about this sort of thing - i believe the mailparser incorrectly calculates the size of the text blocks under certain circumstances.
this gives rise to truncating the end of the block. presumably this could also affect attachments.

there is a reference to a magic number 4 in the ParseMultipartBody() sub:
If nextPart - 4 > index Then
do something
end if

there's the "if" that doesn't have an "else", so i'm trying to follow the code to see how it falls through when the "if" block isn't true. I realize the parser has little choice but to look for the boundary designator between blocks the hard way, but it looks like it assumes that the message boundary line is supposed to be preceded by something: one or more cr/lf sequences? they're often there, but when they're not, it may cause the parser to back up too far.

in my case, i am seeing messages with the last 4 characters of the missing. in stepping through the mailparser i see the characters are already missing by the time HandlePart() receives the block from ParseMultipartBody(). as mentioned above, it's in ParseMultipartBody() that the length of the text block is calculated.

-go