Re: sense of _FFR ?

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Thu, 27 Sep 2012 00:55:19 -0700 (PDT)

On Thu, 27 Sep 2012, Andreas Schulze wrote:
> - ADSP_LISTS
> which problem does it solve?
> [...]

Have a look at the FEATURES file. There's a description of each of them.

In some cases (like this one), I can't remember the exact problem that was
meant to be solved. If nobody's using it, it's a candidate for removal.

> - ATPS
> add an info "my mail is also valid if signed by ..."
> is there a HowTo?

Generally not for FFRs.

You can get the general idea from the RFC that defines it, which is
RFC6541. When enabled, a setting is added for a data set called
"ATPSDomains" that will add an "atps=" tag if the From: domain is in that
data set. This causes some DNS activity that can be used to confirm
authorization of a third-party signer. We add additional
Authentication-Results data when this is the case, but don't take any
other filtering action.

> - IDENTITY_HEADER
> add an i=user_at_domain to the signature. What is it good for compared to
> i=_at_domain added without extra configuration?

That's not something specified by DKIM. It's between the signer and the
verifier to decide what value the extra information carries.
>
> - RATE_LIMIT
> Is somebody using it?

No idea.

> Where is the difference to reputation?

It was a precursor to the current reputation code. It can probably be
removed now if nobody's using it.

> btw: looks like RATE_LIMIT is only available if IDENTITY_HEADER is enabled.
> -> a bug?
> ... opendkim/opendkim-conf.h:
> #ifdef _FFR_IDENTITY_HEADER
> #ifdef _FFR_RATE_LIMIT
> { "FlowData", CONFIG_TYPE_STRING, FALSE },
> { "FlowDataFactor", CONFIG_TYPE_INTEGER, FALSE },
> { "FlowDataTTL", CONFIG_TYPE_INTEGER, FALSE },
> #endif /* _FFR_RATE_LIMIT */
> { "IdentityHeader", CONFIG_TYPE_STRING, FALSE },
> { "IdentityHeaderRemove", CONFIG_TYPE_BOOLEAN, FALSE },
> #endif /* _FFR_IDENTITY_HEADER */

Fixed.

> - REDIRECT
> redirect incoming, invalid mail to a separate address.
> Anybody using it?

No idea. It's almost three years old. If nobody's using it, it should
go.

> - REPLACE_RULES
> It's from old dkim-milter days. I found no usage example.

This one does get some occasional inquiries, and solves a
sendmail-specific signing problem. I'd leave it in for now.

> Maybe the some _FFR could declared official or be removed?

I usually poll the lists to see who's using which ones, making them
candidates for conversion to supported code, and which ones have garnered
no interest, making them eligible for deletion. Looks like you did a few
of them for me here. :-)

So does anyone have any they'd like to see activated into production code?
Do any of the ones discussed above seem like bad candidates for removal?

The current FFR list is:

         atps [+]
         adsp_lists [-]
         db_handle_pools
         default_sender
         diffheaders [+]
         dkim_reputation (the older stuff)
         identity_header
         ldap_caching
         lua_globals [+]
         postgresql_reconnect_hack
         rate_limit [-]
         rbl [+]
         redirect
         replace_rules [+]
         reputation [+] (the newer stuff)
         resign [+]
         sender_macro
         socketdb [+]
         stats [+]
         vbr [+]

[+] candidate for promotion
[-] candidate for deletion

-MSK
Received on Thu Sep 27 2012 - 07:55:47 PST