Re: [opendkim:bugs] #222 Enhance config file element handling for unrecognized tags/parameters

From: Murray S. Kucherawy <>
Date: Mon, 4 May 2015 12:37:27 -0700 (PDT)

On Sun, 3 May 2015, A. Schulze wrote:
>> A feature was removed. In this case it is better to fix the configuration
>> file instead of having the user believe that the feature will still be
>> working. How about printing a warning in the next version and failing in
>> versions after that?
> Yea, simply print a warning "option foo is deprecated and now ignored"
> that's exactly I would love to see in any software.

I believe you're saying we should have removed configuration items go
through a period of time where if they're present, they are logged as a
warning but otherwise have no effect on the filter. After that period of
time expires, they cause an error and the filter won't start.

Essentially we do that now except that period of time is zero, which
clearly errs on the side of being conservative. Whatever period of time
we pick -- minimum a month, minimum six months, one full release cycle,
whatever -- we're relying on sysadmins to check their logs or watch the
filter start at least once during that time to detect that they need to do
something. I'm not of the opinion that this is safe, because my recent
career experience is that people don't check logs until something has gone
wrong. (This all started because someone did "yum update" via cron and
wasn't happy with the result.) When it comes to security, by then it
could be far too late, and I don't want the blame for that to fall here.

However, if that's really what everyone wants, I'm willing to have a
command line flag that defaults to the current "harsh" behavior, but can
be set to do the warning thing. We need to document the obvious dangers
of enabling it, and come to some agreement on how long the grace period
should be.

So far though, we don't have consensus either way. I've seen two people
in favor (Andreas and SM) and two opposed (Steve and myself). What do
others think?

Received on Mon May 04 2015 - 19:37:51 PST

This archive was generated by hypermail 2.3.0 : Mon May 04 2015 - 19:45:00 PST