It was a buffer overrun which has now been fixed to the best of my
abilities.
I've done another round of coverity analysis on the master branch, and
this doesn't trigger any new warnings with regard to mentioned fix which
is also in the dbmail_3_1 branch.
I've just tagged and thereby released 3.
CAUTION
3.1.16 at least has a regression in case of the commit below
that's a different problem and the testmessage with downgrading
is reconstructed proper
http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214ae1d120581740020f4e73c3cf8d3a6c0
however, the mime-part-id problem is still
Hi Paul
i would love a additional column in the message table containing the sha1 sum
of the message before it get splitted in mime-parts or maybe better a own table
with message-id and checksum and ignore that functionality if this table don't
exist
that would offer a option for dbmail-util
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I can't believe this passed the tests, since this exact message is
part of the test-suite. Seems the test itself was broken :-(
I just pushed a fix. *Please* test!
On 20-07-14 14:12, Reindl Harald wrote:
> CAUTION
>
> 3.1.16 at least has a regressio
I will give it a try after back at home
if the other reconstruct problem under load still exists i try to get back
release version to release version until it is away and want the commits after
upwards
that sort of regressions was solved for sure because we both spent a lot of
hours last yea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If you can, test the master-HEAD. It contains all coverity fixes I
could find. I will not run coverity against 3.1
On 20-07-14 19:06, Reindl Harald wrote:
> 77d17ca7724c32dba27eb187d4abfa129ccf6c4e is *way better* but still
> not error free, can you
Am 20.07.2014 20:47, schrieb Paul J Stevens:
> If you can, test the master-HEAD. It contains all coverity fixes I
> could find. I will not run coverity against 3.1
the problem is that i can't push MASTER to production and the
problems are affecting dbmail 3.1 stable
i did not mean fix anything
besides that the first message at least should contain the
messageid to have a change kill the mail without force
debug-mode and dig through tables i'm unsure about the
others below
dbmail_message_cache_envelope should just strip the
data to the maximum length, that are most likely
broken messages
