ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-ietf-dkim-threats-00 Overlooking a practical solution while also recommending a highly unfair solution

2006-01-25 03:55:47

Doug, Eliot,

In an earlier post in this thread Doug did suggest some text:

> The text should be:
> : As it is impossible to know whether the email-address associated
> : with the signature or just the email-address associated with the
> : RCPT TO: caused the replay abuse, one approach may be to develop
> : a strategy that always holds the receiving domain accountable
> : for exposing the signature and allowing a recipient within the
> : domain to either act alone or in conjunction with the sender to
> : perpetrate message replay abuse.

So I think we could just see if that (or some variant) is
supported or not without going into all the background.

(I assume the proposal here is for this to be additional text
and not to replace the existing stuff.)

Personally, it strikes me as very odd to be trying to hold
the receiving domain accountable for anything.

But maybe what you're arguing for is really more like
traitor-tracing assuming the receiving domain's inbound MTA
is not colluding in the replays.

Whether or not that can work (in this context) is difficult to
say absent a (clear;-) proposal.

The taint of DRM that traitor-tracing sort-of brings with
it may also be problematic.

Stephen.


_______________________________________________
ietf-dkim mailing list
http://dkim.org