-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Fawcett wrote:
>
> the patch seems ok, but does not solve the issue. The
errors I
> reported are with the above patch already done.
>
> I cannot work it out at the moment why some message are
ok
> others are not. For some reason I think the return path
with
> <> round the email address is not working as it
should.
>
> John
ok, I've done some more debugging and have found one part of
the problem:
the values in the GRelation which stores the headers/values
relations
are being corrupted by the call to g_mime_message_set_header
in
dbmail_message_set_header.
I printed them before and after that call and they are
different:
I used this code which is the same as the code which will be
used
later for reading the headers to be inserted.
GTuples *values;
unsigned char *raw;
unsigned i;
values =
g_relation_select(self->headers,header,0);
for (i=0; i<values->len;i++) {
raw = (unsigned char
*)g_tuples_index(values,i,1);
TRACE(TRACE_DEBUG,"raw value
[%s]",(char*)raw);
}
in the case of xxxxxx.log (where two headers were inserted,
one correct
and one blank) these are the values before and after the
g_mime_message_set_header call:
before: raw value [<xxxxxx gufonero.com>]
after :raw value [^A]
the [^A] value eventually gets sanitized to ""
which is why a blank
header gets inserted into the dbmail_headervalue table. It
looks like
the call to g_mime_message_set_header is deallocating some
memory
which the GRelation structure points to.
in the case of xxxx.log (where there was a duplicate entry)
before: raw value [<xxxxgufonero.com>]
after :raw value [xxxxgufonero.com]
so it looks as though the call to g_mime_message_set_header
has
overwritten the previous memory with a new value but kept
memory position the same.
The code then goes on to add a new Return-Path header
xxxxgufonero.com
as specified by the command line parameter -r, so that's
why we end up with two Return-Path headers which are the
same.
There is clearly a duplicate header problem to solve, but
this is
compounded by undefined side effects on in memory headers
after the call to g_mime_message_set_header.
There is also an additional problem with
g_mime_message_set_header
which is that it does not add a header if it is missing
but only change the value of an existing header, so I am
getting
message that come in without a return-path being stored
without
a return-path.
These are my packages on opensuse 10.3
gmime-2.2.1-10
glibc-2.4-31.1
We can spend time trying to get this to work, but I'm just
wondering
whether we need to use g_mime_message_set_header at all.
Seeing as
in the end we must have only one Return-Path header in the
delivered
message and we are trying to update an existing header,
maybe it
would be easier to ignore existing return-path headers and
just
add our own: that way we also avoid duplicate Return-Path
headers in the in-memory structure which is the fundamental
issue.
John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHzmzud4I3jTtt9EIRAqsZAJ9cUG0v7kEQmdN4KeLJ0NIjDj0DQwCe
OC04
wbTv4QhwM3fkl/3Ccmt4a+Y=
=CTiK
-----END PGP SIGNATURE-----
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
|
>>
>> Thanks
Sjoerd
_______________________________________________
DBmail mailing list
DBmail