[exim-dev] [Bug 1019] New: DKIM multiple signature generatio…

Góra strony
Delete this message
Reply to this message
Autor: Uwe Doering
Data:  
Dla: exim-dev
Nowe tematy: [exim-dev] [Bug 1019] DKIM multiple signature generation does not work (dkim_domain list), [exim-dev] [Bug 1019] DKIM multiple signature generation does not work (dkim_domain list), [exim-dev] [Bug 1019] DKIM multiple signature generation does not work (dkim_domain list)
Temat: [exim-dev] [Bug 1019] New: DKIM multiple signature generation does not work (dkim_domain list)
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1019
           Summary: DKIM multiple signature generation does not work
                    (dkim_domain list)
           Product: Exim
           Version: N/A
          Platform: x86-64
        OS/Version: FreeBSD
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Transports
        AssignedTo: nigel@???
        ReportedBy: gemini@???
                CC: exim-dev@???



Created an attachment (id=401)
--> (http://bugs.exim.org/attachment.cgi?id=401)
DKIM multiple signature generation bug fixes for Exim 4.72

Hi there,

first of all, I use Exim 4.72, but when filing this bug report the "version"
selector on the bugzilla web form offered only "4.71" and "4.73", the latter of
which has not even been released at this point. It looks like this might be a
bug in bugs.exim.org's configuration. Anyway, I set the selector to "N/A"
rather than to a wrong version.

Now for my original bug report. The new code in 4.72 implementing
"dkim_domain" as a colon separated list instead of just a single domain is
unfortunately broken, and I attached a patch with the necessary fixes.

The details:

1. Instead of appending the signatures for the domains in the list the code in
4.72 instead allocates a new buffer with each loop iteration so that only the
signature header for the last domain survives. I looked around in the sources
how things are done in other parts of Exim and then replaced the buffer
handling with something more appropriate in my eyes.

2. Said last signature turns out the be for an empty message, though. This is
because there is an lseek() to the start of the message file missing inside the
loop. Currently, the caller of dkim_exim_sign() does the lseek() once, but
this of course works only for the first loop iteration. In my patch there is
an lseek() inside the loop, so it would now be okay to remove the initial
lseek() on the caller level. However, this is a suggestion and not part of the
attached patch.

3. The signature buffer cleanup is broken in that it releases the buffer (by
restoring the original value of "store_pool") even in case of success, that is,
when the caller level still has to read the string from that buffer. While
this may work in the current code, reading from an already released buffer is
certainly bad programming style. So the buffer now gets released only in case
of failure (return of NULL pointer), in a safe way that I took from
string_cat() in "string.c".

With the attached patch applied, things work as I think they were supposed to
originally. For testing purposes and perhaps as a suggestion for the docs here
is my way of compiling the domain list:

dkim_domain = <, ${lc:${filter{<, ${map{<,
${return_path},$h_from:,$h_sender:}{${domain:${item}}}}}{def:item}}}

This line grabs all addresses and therefore domains that the Exim server may
have a DKIM key for. "map" extracts the domains from the comma separated list
of email addresses, "filter" eliminates empty items in the list and "lc" makes
sure that we can subsequently deal with the domains case-independently.

This in fact even works if the message contains multiple "From:" and/or
"Sender:" lines because Exim's "$h_" mechanism is smart enough to concatenate
them with additional commas as separators.

Hope that this gets fixed in 4.73 so that I can get rid again of that local
patch. ;-)

Best regards,

Uwe


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email