http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5662
------- Additional Comments From [EMAIL PROTECTED] 2007-12-17 06:52 -------
> I few issues I've spotted so far:
> - $scan->{dkim_key_testing} is always 0
Yes. Same as in 3.2.3 - I haven't touched it. The 3.1.8 didn't
even have it. All past versions only checked for a policy testing
flag, never for a public key testing flag.
Some time in 3.2 I split an internal variable dkim_testing into
its two components dkim_key_testing and dkim_policy_testing,
but kept the functionality unchanged. This is why it now became
more obvious that the dkim_policy_testing is always 0.
So, are you asking for a change there, or should the old behaviour
be retained for 3.2?
> - $scan->{match_in_whitelist_auth} could be named better
> so that it's not open to easy naming collision with development
> in other modules; perhaps just prepend "dkim_" to "match_in_whitelist_"
Sure.
> and what I'm really concerned about:
>
>- it's now impossible to use DKIM for whitelisting only by setting the scores
> for the DKIM rules to 0; this forces all DKIM signed messages to be
> processed... something that isn't exactly light-weight; many, many ESPs are
> extermely adverse to the crypto load incurred for (currently) no benefit
> (DKIM pass/verified/whatever doesn't currently get you anything without
> reputation or a whitelist) so not being able to restrict processing to
> whitelist eligible messages is not good and definitely something I don't
> want to see changed midway through a stable branch
This hasn't changed. In 3.2.3, the DKIM check is performed even if
DKIM_SIGNED, DKIM_VERIFIED, DKIM_POLICY_SIGNALL, DKIM_POLICY_SIGNSOME,
and DKIM_POLICY_TESTING are zero, as long as USER_IN_DKIM_WHITELIST
or USER_IN_DEF_DKIM_WL are nonzero - even if a sender address is NOT
found in a whitelist.
So are you asking to make it a new feature?
> Also... I'm not sure exactly how much the plugin has changed to accommodate
> the current SSP RFC, but with all of the recent debate about SSP issues on
> the DKIM list I'm hesitant to make major SSP related changes at this time.
No changes in that area. The SSP specs are still very much volatile,
and it will be a while before it comes to a more wide spread use.
Also the format has changed in the recent draft, and Mail::DKIM
hasn't adapted yet as far as I know.
> More also... while I'm thinking of it... we really need to revert the
> change to the DKIM_POLICY_SIGNSOME eval that causes it to use the default
> policy, rather than the explicit policy as the former is absolutely useless
> (at least without a way for rules to differentiate between the former and
> latter).
If SSP says the absence of a policy is equivalent to certain settings
of a policy, then signing domains which want to use such default settings
are free to either publish it or not publish it. Not publishing what is a
default must not be punished. It is not unusual that signing domains choose
not to clutter their DNS space with what is a default anyway, especially
as the SSP draft is still evolving.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
