On Oct 19, 2005, at 2:22 PM, Earl Hood wrote:
On October 19, 2005 at 10:29, Douglas Otis wrote:
This opportunistic approach can be improved by specifying the role of
the signer, such as:
- Originating
- Resending (remailing)
- Verifying
Is "Resending" only for entities that "re-submit" a message into
the transit system? Would pass-thru forwarders be under
"Resending"?
Assuming that replay must be dealt with, then it would be valuable to
have a signature added when the MTA changes channel characteristics
perhaps as noted by the EHLO name or perhaps your RCPT TO hash
technique.
I'll even assume replay becomes a real problem. Imagine several
flags returned from a reputation query. One may be not to trust the
IP address at all. Another may be the domain can be trusted to sign
for other domains as a remailing signer. The default may be to limit
the trust to their own domain. Imagine that a list-server will sign
in the role of remailing signer, and may nullify the Originating
signature after verifying it was valid. The accountability baton is
thus passed, and the list server also retains a reputation for
protecting signatures.
Perhaps all large providers will resign with a Verifying signature
when accepting messages for delivery to the mailbox and nullify all
other signatures that verify. If they do not verify, the signature
header is removed and replaced with some diagnostic header. Perhaps
signature parameters are simply replaced with "*verified*... " or
"*invalid*... "
While there may be a day when third-party signing is not allowed,
unless what is considered an originator is also compliant with
RFC-2822, that day may be many more years way, if ever.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org