Douglas Otis wrote:
> _You_ have suggested in the past, the message replay abuse
> problem could be resolved with SenderID when used in
> conjunction with DKIM.
Did he ? Somehow I missed that. DKIM security based on PRA
would be a quite interesting point, to put it mildly. It's
possible if we're up to "fixing" (modifying) 2476bis 8.1 and
2822, some "minor" details like re-charter DKIM left out. ;-)
> At the least, there should be an attempt to explain how
> message replay abuse will not affect the acceptability of
> the sign-domain, the basis for your Low impact rating.
Is that the basis of 4.1.4 ?
> Why should major issues should be left unresolved, if only
> in theory? This is not the protocol draft.
Sorry, a statement like "don't even think about DKIM without
PRA" sounds like a death sentence for me. For starters the
PRA is not necessarily (one of) the 2822-From address(es).
> The message path as described by SenderID
JFTR, SenderID merely offers a normative reference to SPF for
this purpose. It contains no separate "description" of these
SPF-details except from "use spf2.0/TBD instead of v=spf1" and
the theoretical concept of "positional modifiers" (in practice
not one positional modifier exists so far).
Four letters of one wannabe-backwards-compatible "spf2.0/TBD"
are the subject of an IAB appeal. It makes no sense to base
DKIM security on PRA, neither technically nor procedurally.
> (when mediators are blocked)
When they're blocked the replay attack wouldn't work, so that
is no problem with the idea to use PRA as a defense for DKIM.
Bye, Frank
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html
