Scott Kitterman wrote:
I think basing a security decision based on a correct token in the
header/message is a mistake. I think you have to assume that a list of
'good' tokens would leak out and be forged. I think it needs to be
verifiable outside the message. It could be a list of IP addresses for
example.
The security stuff in the draft deals with the forged cases already.
I'm trying to address the concern of auto-configuration as much as is
practical in this draft.
So I'm not addressing the issue of security of the tokens here, but
rather the auto-training of an MUA about which ones to attempt to verify
and which should simply be ignored.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html