Hi Thomas,
if you figure out that dkimproxy is not using the conf files
/etc/dkimproxy/dkimproxy_*.conf than you can change the certificate paths
accordingly. Other than this, it uses the "wrong/default" certificate files
and the signature and dns entry does not match and you always get
dkim=hardfail.
I did not notice that the bug is because of a typo in the init script as
you have mentioned, it was not in the debian bug list. This bug makes the
package unusable for the ones that did not notice this bug in terms of
successful signing of mails, *but i agree, the package is usable if you
change cert paths*.
2012/9/28 Thomas Goirand <tho...@goirand.fr>
>
> Hi,
>
> On 09/28/2012 05:03 AM, R. Tolga Korkunckaya wrote:
>
>> Severity: grave
>> Justification: renders package unusable
>>
>
> I can't agree that this "renders package unusable". I've been using
> dkimproxy in hundreds of servers without problem. I don't think this is an
> RC bug (eg: severity normal would be more appropriate).
>
> init script of Debian package of dkimproxy do not parse/read
>> /etc/dkimproxy/dkimproxy_out.**conf to override default settings,
>> it reads /etc/default/dkimproxy file only. However, this is not
>> written in Debian.README file of the package.
>> In dkimproxy docs these overrides are addressed to the
>> /etc/dkimproxy/dkimproxy_in.**conf and /etc/dkimproxy/dkimproxyoutn.**
>> conf
>>
>
> I believe the problem you are facing is that the init script
> uses --conf_file ${DKOUT_CONF} when it should really be using:
> --conf_file=${DKOUT_CONF} (eg = sign instead of space). This has already
> been fixed in the SID version, only the stable version of this package
> doesn't have the fix, but it certainly does not "renders package unusable".
>
> Cheers,
>
> Thomas
>
