http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5662
------- Additional Comments From [EMAIL PROTECTED] 2007-10-02 04:14 -------
svn -m 'revise r580453, accomodating some of the concerns
in bug 5662#1 for Plugin::DKIM' ci
Sending lib/Mail/SpamAssassin/Plugin/DKIM.pm
Committed revision 581122.
There are two problems in the 3.2.3 DKIM which my changes are fixing:
- whitelisting first-party signatures based on a wildcarded domain
does not work, e.g.:
whitelist_from_dkim [EMAIL PROTECTED]
This is because the identity as stored in a whitelist is '*.cam.ac.uk'
and does not literally match a signing identity e.g. 'department.cam.ac.uk'.
For checking first-party signatures a check must me made against the
specific originator address in a mail which matched the wildcard address
(first parameter in whitelist_from_dkim).
- the matching on identity (second parameter) was too permissive in case a
local part is non-empty. The subdomain matching logic was inappropriately
also used in a local part. An example of an inappropriate match:
the:
whitelist_from_dkim *.example.com [EMAIL PROTECTED]
also matched a signing identity [EMAIL PROTECTED]
> The change unnecessarily removes functionality
I have now restored matching on subdomains in a signing identity, e.g.
whitelist_from_dkim [EMAIL PROTECTED] example.com
now works for signing identities @sub.example.com and @example.com.
> removes useful debugging info,
It is questionable how useful is a debug along the lines of:
'what would be if the message were slightly different'. For testing
purposes a user could just as well supply a valid signature. And why
stop walking the whitelist at a first match, it might be useful to see
what other entries match... Nevertheless, I put back the debugging in
the spirit of original code (which makes code somewhat more compliceted,
but never mind).
> has overly verbose (and thus confusing) documentation,
> uses a number or real domains in examples (and those
> domains don't even support DKIM), references SSP which
> is still in limbo.
Dropped the 'BRIEF INTRODUCTION TO TERMINOLOGY' section
from a man page, changed examples, changed refs.
> and possibly hides something I've missed in the massive change
> of $scanner to $scan all over the place.
10 routines used $scan, and 3 used $scanner for the same object.
It was confusing to read - a change for consistency.
> My biggest issue is with only allowing for an exact match of the provided
> optional signing identity. At the very least you need to allow for
> sub domain globing.
Done, where the second parameter (identity) is provided.
An empty second parameter now implies first-party signature,
which needs to follow rules in RFCs.
It is compatible with the expected usage and with some example lists
that were posted on SA-user mailing list on two or three occasions.
> Additionally, when an optional signing identity is provided there
> shouldn't be any fallback to using the originator identity.
You are quite right. Fixed.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
