On 11/3/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > 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 >
I'm not very familiar about the emails in the 'wild,wild internet', but as we want to return strictly correct messages, we have to convert the line endings, and it is better to convert once, before storing it. So I'm with you :-) Zsombor
