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
