On Tue, 2006-03-07 at 09:23 +0200, html wrote: > Hello, > > I need to implement a search feature directly into the database. > from the search results(messages) I need to offer access to attachments. > > Basically I try to recreate an attachment from blocks, > from the table "dbmail_messageblks". > > I remove the message body and other delimiters from the > blocks(if there is only one attachment I clean only the first and the last > block).
Don't leave out the message headers, too, which you'll need for proper mime decoding. > Then I have decoded(64) the blocks and write them together to a file. But > the resulting file is not the correct attachment. > > My questions are: > - where can I find more information(docs?) about the message blocks? The message blocks are just the original message, saved to the database in smaller pieces. There is an is_header flag that marks messageblocks which contain headers (vs. the message body). Retrieve all the blocks for a message in order, concat them together, and you should have the original message. > - how do you proceed: > do you split the attachment in blocks and do you encode EACH block or do yu > encode the attchment and after that you split in blocks? Dbmail does no encoding itsself, it saves the original message. The original message is usually going to be mime-encoded, which can have many levels of nesting, and isn't just a straightforward base64_decode(). Your best bet is probably to find a library that supports mime for whatever language you're using to write your program, and use it to decode the message. (There is a libdbmail now-a-days; I have no idea what's in it and if it could be leveraged for your use.) There are also various command-line tools to work with mime messages, if you're using a scripting language. > - do I need to do other processing except 64 decoding? Yes. As noted, most messages are in mime format. > - when do you plan to keep the attachments separated? There's been discussions on this in the past, and I believe the current consensus is that there are no plans to do that. > Thank you. > -- Jesse Norell - [EMAIL PROTECTED] Kentec Communications, Inc.
