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

From: Scott Kitterman <ietf-dkim_at_kitterman.com>
Date: Mon, 04 May 2015 16:16:36 -0400

On Monday, May 04, 2015 12:37:27 PM Murray S. Kucherawy wrote:
> 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?

In general, I think deprecate (with warnings) and then remove is a good
strategy.

Scott K
Received on Mon May 04 2015 - 20:16:47 PST

This archive was generated by hypermail 2.3.0 : Mon May 04 2015 - 20:18:00 PST