http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5662
------- Additional Comments From [EMAIL PROTECTED] 2007-12-18 13:10 -------
The current model in SSP is to have three possible settings:
DKIM=unknown (Signature Optional)
DKIM=all (Signature Required, Any party)
DKIM=strict (Signature Required, 1st party only)
and the 'testing' flag in SSP seems to be going away.
Besides, there is a new "handling=process" vs. "handling=deny"
attribute of the SSP.
This means that:
- DKIM_POLICY_TESTING is redundant (will always be false);
- DKIM_POLICY_SIGNSOME is redundant (is always true);
- there is no equivalent rule to test for DKIM=strict,
which is the most useful setting (allowing to block
with a high spam score) - although nobody uses it yet.
For the future, rules like the following might be desired:
- DKIM_POLICY_STRICT (most needed)
- DKIM_POLICY_DENY (useful when combined with DKIM_POLICY_STRICT)
- DKIM_KEY_TESTING (or DKIM_SIGNATURE_TESTING) (rarely useful)
- DKIM_VALID (replacing a misnomer DKIM_VERIFIED)
- DKIM_VALID_AUTHOR (contains a valid first-party signature)
- DKIM_VALID_3RDPARTY (contains a valid 3rd-party signature)
- DKIM_VALID (replacing a misnomer DKIM_VERIFIED,
where its value could be an OR of the above two,
or just a synonym for DKIM_VALID_AUTHOR)
> Processed as in running the message through Mail::DKIM.
> Crypto and blocking DNS lookups are expensive.
The current version of Mail::DKIM runs 8 times faster than previously
(I needed that speedup too, and invested some time in optimization).
It turned out that the expensive part was passing small strings
through a chain of subroutine calls. The crypto part was pretty
much insignificant. But yes, the DNS lookup still takes wall-clock
time, although (along with a dozen of RBL lookups), but it does
not reduce achievable throughput, just to contributes to latency.
Fetching a SSP policy adds another DNS lookup. Considering the
current state of SSP usefulness (useless), considering that
Mail::DKIM does not currently implement fetching of SSP
according to any of its drafts (still uses rfc4870 rules,
waiting for dust to settle), I'd like to repeat a suggestion
I made some time ago:
The score for all three SSP-fetching rules should be set to 0:
(DKIM_POLICY_SIGNALL, DKIM_POLICY_SIGNSOME, DKIM_POLICY_TESTING).
This disables one redundant DNS lookup, and avoids the clutter
the DKIM_POLICY_SIGNSOME rule makes.
> 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.
I fully agree.
> OK, I'm confused by your "Reworked whitelisting..."
> Could you elaborate on that?
Will do (later).
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
