Does anyone have an opinion about this?
In this case the new version dropped a major feature (ADSP), and the
result of this change would be that ADSP configuration file items would be
logged but ignored. Someone not checking logs and relying on ADSP to be
there might find out much later that a feature she was anticipating had
actually been removed. Personally I would rather deal with the failure
and know the current state of things than have important features quietly
go missing on me. Do others have an opinion here?
I would suggest that the package maintainer should've fixed the
configuration rather than simply replacing the binary, which is what
appears to have happened.
We would at least want to reject configurations for things that are
completely unknown, but have a period during we do log-but-continue for
settings that have been removed.
Any other suggestions?
-MSK
---------- Forwarded message ----------
Date: Thu, 26 Mar 2015 22:29:25 +0000
From: Kevin San Diego <ksandiego_at_users.sf.net>
Reply-To: Ticket 222 <222_at_bugs.opendkim.p.re.sf.net>
To: Ticket 222 <222_at_bugs.opendkim.p.re.sf.net>
Subject: [opendkim:bugs] #222 Enhance config file element handling for
unrecognized tags/parameters
____________________________________________________________________________
[bugs:#222] Enhance config file element handling for unrecognized
tags/parameters
Status: open
Group: 2.7.0
Created: Thu Mar 26, 2015 10:29 PM UTC by Kevin San Diego
Last Updated: Thu Mar 26, 2015 10:29 PM UTC
Owner: nobody
Seen in v.2.10.1:
Last an automatic overnight yum update run via cron upgraded opendkim milter
to v.2.10.1. This morning I noticed that mail stopped flowing and began to
investigate, noticing that the opendkim milter failed to properly restart as
it appears that an old "ADSPAction" tag still existed within
/etc/opendkim.conf:
$ sudo /etc/init.d/opendkim start
Starting OpenDKIM Milter: opendkim: /etc/opendkim.conf: configuration error
at line 82: unrecognized parameter
$ grep -n ADSPAction /etc/opendkim.conf
82:ADSPAction reject
In order to not impact system performance when a config tag is not
understood (i.e. deprecated, malformed, etc.), I'd suggest the application
log errors to stdout and to syslog upon daemon startup but otherwise start
if the config error is not completely fatal.
____________________________________________________________________________
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/opendkim/bugs/222/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
Received on Sun Mar 29 2015 - 07:37:36 PST