the mailboxAPI is centered around MimeMessage. this has disadvantages. one of which is that there is not easy way to associated meta-data with it.
my reading of RFC822 is that for internet transport, line endings should be normalised to CRLF. in other words, if a message is created on a platform which uses CR alone to indicate a line has ended then it needs to be normalised to CRLF. (hopefully people will jump in if i have any of this wrong.) many protocols (including IMAP) state that message should be normalised (use CRLF line endings) for output. ATM the most common method in the MailboxAPI is to simply replace every isolated CR and LF with a CRLF. given a MimeMessage, i do not know how to determine whether the lines have been corrected as per RFC822 or not. ATM the MailboxAPI assumes that the mssage has not been normalised. it then performs a conversion to determine the length of the normalised content but then stores the actual content. on the way out, the API performs an automatic conversion of all body line endings to CRLF. this seems wrong to me. AIUI a message which has been normalised for internet transport may contain LFs and CRs in the body but these are not intended to indicate new body lines. the multiple conversion and calculations required to maintain this information degrades performance. it adds complexity to data storage. i now wonder whether it might be better if the API insisted that mail submitted were already normalised for RFC822 - any line ending conversions required by RFC822 for internet transport should be performed before storage. opinions? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
