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
