------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1019
--- Comment #5 from Michael Haardt <michael.haardt@???> 2010-09-17 11:31:52 ---
> A single domain in the list for which the server doesn't have a key causes
> dkim_exim_sign() to abort the loop and return an empty string. When there was
> just one domain possible prior to 4.72 this made sense, but now it is no longer
> appropriate.
Good idea.
> 1. Instead of jumping out of the loop to label CLEANUP when we don't have a key
> for the current domain we now continue with the next iteration. Only at the
> end of the loop, when all went well and there was no failure, we assign "rc"
> either the pointer to the signature buffer or an empty string in case there are
> no signatures (sigbuf is NULL). This is compatible with the buffer cleanup
> code at the end of the function.
Good.
> 2. I added cleanup code for the "seen_items" buffer, too.
>
> 3. I misunderstood the meaning of the global variable "store_pool". Saving it
> at the start and restoring its original value at the end of the function has
> nothing to do with releasing allocated memory. Instead, "store_pool" just
> determines which memory pool we want to allocate buffers in. In the code of
> 4.72, saving and restoring that variable was basically a no-op because there
> was nothing in dkim_exim_sign() that changed the contents of "store_pool". I
> now reintroduced the saving and restoring code and additionally set the
> variable to POOL_MAIN at the start of the function. This pool is for
> short-lived memory, the lifespan of which is only the current message.
Is it neccessary to release the memory? Exim uses pools to avoid leaks
already and I am glad about each line of code I don't need. I suggest
to remove the calls to store_release().
Michael
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
