> -----Original Message-----
> From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-bounce_at_lists.opendkim.org] On Behalf Of Steve Jenkins
> Sent: Friday, July 22, 2011 6:02 PM
> To: opendkim-dev_at_lists.opendkim.org
> Subject: Default opendkim.conf options
>
> 1) I'm really tempted to make the default Mode sv, but since someone
> could potentially install this RPM on a production machine, there's
> the possibility they'd be sending out signed mail before they have a
> chance to update their DNS zone file with their public key, meaning
> anyone who is verifying on the receiving could refuse delivery. I'd
> love some opinions here - is v the best default mode?
My preference is always to have a default that has the least impact on a mail stream when the switch is turned on. In this context, that means not signing (for the reasons you cited), and verifying with no settings enabled that could cause a message to be temp-failed or rejected.
> 2) I'm wondering why the default group in UserID is "mail." Since
> we're creating the opendkim user AND group, any good reason to not
> have UserID be opendkim:opendkim? Also, can I just comment this line
> in the default conf?
Seems fine to me. And commenting the line is also fine if the start script does a "su" to the new user and group, since opendkim by default keeps the user and group(s) of the process that started it.
> 3) I almost want to remove the commented Socket line altogether, and
> just leave the uncommented "inet:8891" line so that it's not
> confusing. Anyone who knows enough to know that they want something
> different can easily read the docs and make this change themselves.
Sounds fine to me.
> Also, is 8891 the preferred port for a reason? I'm using 20209 on my
> RedHat boxes (not sure I can remember why).
Back when I worked at Sendmail, we assigned our filter products to use port numbers starting at 8895. I went up from there as I created new products, but at one point started going downward from there for non-commercial work. OpenDKIM's antecedent, "dkim-milter", got that port number, and I kept it here for backward compatibility.
Ideally we'd use a default that's registered for IANA, but I'm probably dreaming there. :-)
> 4) I'm OK leaving the Domain, Selector, and KeyFile lines commented,
> but I'm wondering about including a commented KeyTable line, too. I
> think quite a few people may want to sign for multiple domains.
I think that's a good idea.
> 5) Should there be a default trusted-hosts file created on install
> with 127.0.0.1 in it? If so, I'll put that in the default conf file
> (and reference it for ExternalIgnoreList and InternalHosts).
It's the default for both of those. You could include it for illustration I suppose.
> 6) Should "X-Header Yes" be added by default? I think it would help
> with troubleshooting, and OpenDKIM evangelizing. :)
As above, I prefer to have defaults that cause only necessary, low-impact changes. Adding an "X-DKIM" field isn't really necessary (and, as an aside, deprecating "X-*" fields are a topic of discussion at IETF right now), so I don't like the idea of defaulting it to "Yes" myself, but this is your project. :-) Plus, it's not like this is a very impactful change.
> 7) I use AutoRestart in my personal conf file, but is that potentially
> problematic for new users? Is it worth including in the default? Maybe
> just included and commented out?
I'd be fine with including it enabled if you also set AutoRestartRate to limit how many times or how fast it restarts before giving up. You want to enable a fork() loop when startup fails each time.
> 8) Should there be any ADSPAction or ADSPNoSuchDomain options in the
> default?
Definitely not. Common wisdom right now is that ADSP is fairly dangerous because it's too easy to get wrong and has ugly side effects.
> 9) Should we set some liberal default "On-" options such as:
>
> On-Default accept
> On-BadSignature accept
> On-DNSError tempfail
> On-InternalError accept
> On-NoSignature accept
> On-Security tempfail
I think those are the defaults, actually. The man page and/or sample configuration can confirm this. You could include them explicitly if you like, but I think the documentation spells them out.
> 10) I'm going to compile with --enable-stats, so I'll put a
> "Statistics" option in the conf file, but commented. The README will
> explain how to enable it. Murray - do you want the README to just say
> to email you? Or do you want to set up some semi-automated method on
> your website?
I think the README should point people at stats/README from the source tarball, or to
http://www.opendkim.org/stats.html which says largely the same thing (though the versions need to be updated).
Thanks for all this work!
-MSK
Received on Sat Jul 23 2011 - 05:36:22 PST