Re: anti-RFE

From: SM <sm_at_resistor.net>
Date: Sun, 27 Jun 2010 14:13:25 -0700

Hi Daniel,
At 22:06 26-06-10, Daniel Black wrote:
>Early on, in dkim-milter/opendkim features were added for probably
>some not so
>common causes. This has increases our user base at the expense of code
>complexity. The additions of lua, dataset abstraction and
>SigningTable/KeyTable has created a very generic interface. The generic
>interfaces can do some of what has already been added as features earlier.
>
>I propose that we look through the less significant features we have
>an replace
>them with lua script if possible, and if not, look at expanding the lua
>interfaces in a generic way to support them.

Agreed.

>Increasing the simplicity of the code make it more appealing to use.
>Even some
>of the below items I've suggested moving to a lua script will be
>more readable
>as an lua script that a config option I suspect.
>
>As a first rough cut:

[snip]

>AllowSHA1Only - is this still needed?

Yes. Keep it in the code.

>AuthservIDWithJobID -needed as option? can this just default to true?

It's false over here. If I recall correctly, someone asked for that feature.

>POPDBFile - with luadb access this could be done in lua. Seems like an
>advanced option to me.

Keep it in the code for now.

>RemoveARFrom - is this is still desired? remove_header is missing from lua.

Yes, it is silly useful.

>Reputation* - is this something that is advanced scripting? While there is an
>add_header function is adding a AR header a worthy function to introduce?

It could go into a Lua script.

>SelectorHeader/SelectorHeaderRemove - seems like advanced functionality

This was a RFE.

>SenderHeaders - what was the purpose here?

I don't recall.

>SubDomains - sounds like something that can be done with regex

Yes.

>VBR* - seem like Reputation* as an advanced selection criteria.
>a generic DNS interface and async callback is probably desirable

Put it in a Lua script.

Regards,
-sm
Received on Sun Jun 27 2010 - 21:22:39 PST