> > > At least part of the reason I am advocating a separate headers table is > > > that I don't see how the header flag would work. I am guessing that you > > > are suggesting adding a flag to the message_blks table that says "this > > > row has headers in it" that is fine but under the current design, a > > > client such as webdbmail would still have to parse that message block to > > > figure out where the headers begin and where the message body begins. > > > Perhaps a hybrid idea would be to add the header flag and then have > > > dbmail only put headers into any row that has that flag set. That way > > > you still get the clean delineation between headers and body and not the > > > intrusive change to the table structure. > > > > This last part is already done - message headers go into the first > > messageblks row, the message body is in all subsequent rows - so that's > > exactly what the flag would do. It would also allow you to have more > > than one messageblks row that contained headers, which if I understand > > correctly, cannot be done right now (so if you had a huge amount of > > headers (and the rfc's place no limit on that), it would currently > > break, but with adding a flag for them, it could be made to work). > > Being able to handle oversized headers is important to maintain compliance > with an implication of the RFC; there indeed is no limit on headers. > > The header cache table would not be a replacement for the headers in the > messageblks table, though. I've suggested calling the table "fastheaders" > because its primary purpose would be holding the headers in heavily indexed > columns for fast searching. > > Copying the headers into the fastheaders table would necessarily modify them, > stripping out the order in which they were received and possibly some of the > line breaks, tabbing and spacing (although these last two should be minimized, > they are likely to occur at some level). > > When the message is viewed, the headers that are in the messageblks table > would be used because they are in entirely unmodified form. > > Aaron >
What if a solution was proposed in which the order and the formatting of the headers could be preserved. A documented method to deconstruct and construct the headers, and working code to be included in db.c. Then a flag in the messageblks row that would indicate if the header is either only, also, or not in the fastheaders table. i suggest we call the table pair message_headers and header_labels. ed Security on the internet is impossible without strong, open, and unhindered encryption.
