Perfect! That's exactly the philosophy that I believe we had agreed upon when
I was doing the rfcsize counting... I suggested inserting \r's if they were
missing, but we decided that the database should reflect exactly what we
receive over the wire and the display/output functions should be responsible
for correctly formatting the messages given their protocol. For example,
dumping to mbox format might involve *stripping* \r's to get UNIX-style
linebreaks.

Aaron


Ilja Booij <[EMAIL PROTECTED]> said:

> The problem with the extra '\r' is also solved. As it turned out, 
> db_dump_range() in dbmsgbuf.c added an '\r' for every '\n' that it 
> found. The code is now changed to only add the '\r' if there was no
> '\r' before the '\n'
> 
> CVS has been updated
> 
> Ilja
> 
> 
> Ilja Booij wrote:
> 
> > Hi,
> > 
> > I have tackled the problem.
> > 
> > The problem was that dbmail-smtp inserts '\n' as newline markers, while 
> > '\r\n' was inserted by dbmail-lmtp
> > 
> > There are two solutions to the problem:
> > Either we tweak the insertion functions to only put '\n' as an end of 
> > file marker into the database, or let the output functions be robust 
> > enough to handle both forms.
> > 
> > I've chosen for the latter.
> > 
> > mime_readheader() in mime.c now deals with both '\n' and '\r\n'. CVS is 
> > updated.
> > 
> > Other output functions still expect '\n', which is visible in the fact 
> > that I get the following output from a test script (python using imaplib):
> > 
> > 'Received: by test01.office.fastxs.net (Postfix, from userid 
> > 1000)\r\r\n\tid 528B019F30A; Tue, 16 Mar 2004 15:37:45 +0100 
> > (CET)\r\nTo: [EMAIL PROTECTED]: 
> > blaat\r\nMessage-Id: 
> > <[EMAIL PROTECTED]>\r\nDate: Tue, 16 
> > Mar 2004 15:37:45 +0100 (CET)\r\nFrom: [EMAIL PROTECTED] 
> > (Ilja Booij)\r\n\r\n\r\n\r\r\nbla\r\r\n'
> > 
> > Ilja
> > 
> > 
> > Ilja Booij wrote:
> > 
> >> Aaron,
> >>
> >> have you been able to find anything wrt the extra colons?
> >>
> >> Ilja
> >>
> >>
> >> Aaron Stone wrote:
> >>
> >>> I found that when I type messages directly into LMTP they get the 
> >>> extra ':'
> >>> colons. The common theme is that I never type in a decent header by 
> >>> hand.
> >>>
> >>> When I send mail through Postfix and using a mailer that puts on decent
> >>> headers, and Postfix send it through LMTP (finally got it working!) 
> >>> there are
> >>> no extra colons in the IMAP retrieval of the message.
> >>>
> >>> Aaron
> >>>
> >>>
> >>> Ilja Booij <[EMAIL PROTECTED]> said:
> >>>
> >>>
> >>>> I think we're ALMOST ready for rc4. Currently I'm working on the 
> >>>> problem of the insertion of ':' in message bodies, which was 
> >>>> mentioned in an earlier thread.
> >>>>
> >>>> I have not been able to reproduce the error that is mentioned by 
> >>>> Blake Mitchell in this thread. Perhaps it has something to do with 
> >>>> the distinction between headers and body not being made completely 
> >>>> ok. I'm suspecting that that may be the cause of the ':' being 
> >>>> inserted, and perhaps it gives some more problems.
> >>>>
> >>>> If those problems are out of the way, RC4 can be released, unless 
> >>>> anybody else has something they'd like to see fixed.
> >>>>
> >>>> Ilja
> >>>>
> >>>>
> >>>> Aaron Stone wrote:
> >>>>
> >>>>
> >>>>> Looking at the list of bugs in 2.0rc3, I think we're in good shape 
> >>>>> for 2.0rc4:
> >>>>>
> >>>>>    Before the final release of DBMail 2.0, there are some things
> >>>>>    we still need to resolve:
> >>>>>    - dbmail-lmtp has an error which sends it out of sync with the
> >>>>>      lmtp-client from the MTA after receiving more then 1 message
> >>>>>
> >>>>> Ilja figured out the parts of the LMTP RFC that I had 
> >>>>> misinterpreted, and I
> >>>>> wrote the patches to fix it.
> >>>>>
> >>>>>    - Connections with Mozilla are flakey
> >>>>>
> >>>>> Ilja figured this one out and fixed it; CVS has been working well 
> >>>>> for me.
> >>>>>
> >>>>>    - Some database queries and indexes have to be optimized
> >>>>>
> >>>>> I just got rid of half a dozen queries during message insertion :-)
> >>>>>
> >>>>>    - The MD5 calculation we use does not work on AMD Opteron systems
> >>>>>
> >>>>> Leif Jackson helped me to track down the wordsize and endianness 
> >>>>> problems.
> >>>>>
> >>>>> Was there anything else on anybody's mind that needed fixing? 
> >>>>> Especially given
> >>>>> my changes in the delivery/sorting layer and Ilja's changes to 
> >>>>> IMAP, 2.0rc4
> >>>>> should probably go out pretty soon to get some more user testing!
> >>>>>
> >>>>> Aaron
> >>>>>
> >>>>> _______________________________________________
> >>>>> Dbmail-dev mailing list
> >>>>> Dbmail-dev@dbmail.org
> >>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Dbmail-dev mailing list
> >>>> Dbmail-dev@dbmail.org
> >>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>
> >>>
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> Dbmail-dev mailing list
> >> Dbmail-dev@dbmail.org
> >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > 
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> 



-- 



Reply via email to