The following issue has been RESOLVED.
======================================================================
http://www.dbmail.org/mantis/view.php?id=262
======================================================================
Reported By: idk
Assigned To: paul
======================================================================
Project: DBMail
Issue ID: 262
Category: IMAP daemon
Reproducibility: have not tried
Severity: minor
Priority: low
Status: resolved
Resolution: fixed
Fixed in Version: SVN Trunk
======================================================================
Date Submitted: 25-Aug-05 20:18 CEST
Last Modified: 14-Feb-06 16:55 CET
======================================================================
Summary: When server could not parse a message body, server
may crash due a memory corruption
Description:
In rfcmsg.c[768] is
msg->rfcheadersize =
strlen("subject: dbmail IMAP server info: this message could not be
parsed\r\n")
+ strlen("from: [EMAIL PROTECTED]");
but some rows before is
strcpy(mr.field, "from");
GetConfigValue("POSTMASTER", "DBMAIL", postmaster);
strncpy(mr.value, postmaster, MIME_VALUE_MAX - 1);
I have configured postmaster address with two characters less than
[EMAIL PROTECTED], I don't want to try what there will happen with
larger addresses. Maybe nothing. But compute total string length with
proper parameters will be better, I mean ;)
======================================================================
----------------------------------------------------------------------
paul - 25-Aug-05 20:57
----------------------------------------------------------------------
Let me put this in perspective.
rfcheadersize is never used during normal operations. It is called into
action when the imap server cannot parse a message. And then it's only
used to tell the imap client about the rfc822 size of a message. So this
value may indeed be off, but will then only lead to confusion of the imap
client, *not* to stack smashing on the server-side.
In 2.1 this whole slew of code (dbmsgbuf.c/rfcmsg.c/mime.c) which
constitute both message-parsing *and* message-caching at the same time
(grrr) are being replaced with gmime code (as far as the parsing bit
goes). This is a slow process (small steps) by design (test-driven
refactoring). But this rfcsize part is already long gone. In 2.1 CRLF
conversion is done by setting a gmime-filter. Speed is not my primairy
concern here. Reliability is.
Dont hesitate to send me a patch (diff -ur) and I will apply.
PjS
Issue History
Date Modified Username Field Change
======================================================================
25-Aug-05 20:18 idk New Issue
25-Aug-05 20:57 paul Note Added: 0000881
25-Aug-05 20:57 paul Priority normal => low
25-Aug-05 20:57 paul Status new => acknowledged
25-Aug-05 20:57 paul Resolution open => no change
required
14-Feb-06 16:55 paul Status acknowledged => resolved
14-Feb-06 16:55 paul Fixed in Version => SVN Trunk
14-Feb-06 16:55 paul Resolution no change required =>
fixed
14-Feb-06 16:55 paul Assigned To => paul
======================================================================
