Douglas Otis wrote:
DKIM offer no protection without annotations. DKIM
Designation should be annotated differently than messages
where the 2822.From address and the signing domain match.
Do we already have this in the requirements ? At some point
you could probably say that it's "obvious", but documenting
it explicitly is clearer.
The problem of look-alikes will only grow worse and is not
prevented by taking away everyone's freedom.
Some of them are receivers, we want a common subset of DKIM
functions working similarly for receivers supporting SSP, and
others not supporting SSP. Unilateral delegation is odd.
John's comparison with a Turing-complete path registration
scheme comes to mind: Limited to at most 10 lookups it's in
practice harmless, and limited to CIDRs + mx (without colon)
+ a (without colon) + include + all it would be perfect.
But as soon as folks are forced to "emulate include" (because
the relevant ISP has no policy) things start to get messy as
far as that's possible within the overall limits. "Emulate
include" (SPF) is very near to "unilateral delegation" (SSP).
[...]
One might assume this process also applies a block-list of
known problem addresses as a best practice.
The dnsbl draft is in limbo at the moment, from an "IETF last
call" POV block-lists might not exist "officially". Maybe we
could adopt the ASRG draft and publish it as DKIM document (?)
Sorry, many ISPs may decide to ignore DKIM altogether.
No problem, a minor point in the security considerations of an
authentication header field RFC. MUAs might need to know what
they get.
Perhaps the i= syntax should be revisited or something.
The i= syntax is apparently fine, unless you want a mandatory
local-part with default postmaster (?). The i= semantics is
less clear.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html