http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5662
------- Additional Comments From [EMAIL PROTECTED] 2007-12-17 12:42 -------
Uh crap, it seems my memory is failing me lately. :o
(In reply to comment #11)
> (In reply to comment #10)
> > - it's now impossible to use DKIM for whitelisting only by setting the
> > scores
> > for the DKIM rules to 0;
>
> Daryl, can you explain this? Are you saying it's possible to run DKIM checks
> even if the rules are set to 0 scores? because I'd prefer that wasn't the
> case;
> 0-scoring is the "standard" way to disable a set of rules, after all.
You have to disable the WHITELIST_FROM_DKIM rule (and the DEF_ one), too, to
completely disable DKIM checks. I had been supplying a patch to some ESP
customers that only ran the DKIM check (do the crypto and DNS checks) if the
address appeared in the DKIM whitelist config. It makes a significant
difference it processing time (at least wall clock wise). I thought I had
merged this into our codebase, it turns out I never did. Sorry for the
confusion.
> > this forces all DKIM signed messages to be
> > processed... something that isn't exactly light-weight;
>
> "processed" in what way? do we not already perform some lookups?
Processed as in running the message through Mail::DKIM. Crypto and blocking DNS
lookups are expensive -- but don't actually change with the proposed patch.
(In reply to comment #12)
> > 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?
OK, I see you made that change in r515298. I had just applied the patch and
then reviewed the resulting version by comparing it to how I remembered it was
before (apparently that wasn't a great idea!). The conditional on something
that is always 0 threw me off. In any case you can disregard this concern too.
> 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?
Sure, for 3.3. I honestly thought I had merged that into 3.1 way back, sorry.
Ignore this concern too.
> > 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.
OK, I'm confused by your "Reworked whitelisting to match the new documentation
and expected use as per SSP draft" statement in comment #0. Could you elaborate
on that? Pointing out, in comment #5, that RFC 5016 has been published led me
to believe that there was something of substance to your initial comment.
> > 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.
There's no punishment of senders by not causing an informational rule that
scores ~0 to fire on damn near every email received. The only punishment is to
the receivers who it annoys the hell out of. I'm not saying that internally we
shouldn't observe a default policy when its appropriate to do so, just that we
don't need to add a rule in every email received (that the sender doesn't define
a different policy or doesn't even use DKIM) telling the recipient what the
defaults of some RFC is.
I propose that we restore the SIGNSOME rule to where it only fires on an
explicit sign some policy and add a new rule called DKIM_POLICY_SIGNSOME_DEFAULT
(or whatever) and have that fire when a default sign some policy is assumed.
This way you can retain whatever benefit of this rule is perceived by what I'm
sure is a small minority and everyone else can disable it. Perhaps it should
even be disabled by default as I really don't understand what the use of this
functionality is and nobody's suggested a use yet. It's not like we fire
SPF_NEUTRAL (the default policy) in lieu of an explicit SPF record and nobody's
asked us to do so going back to 3.0.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
