applies those signatures. Taken together, these will assist
receiving domains in detecting (or ruling out) certain forms of
spoofing as it pertains to the signing domain.
I suggest replacing the last sentence with something more generic, to avoid
the
debate about how much any of this pertains to spoofing, per se. Perhaps
instead
have a value proposition statement derived from the one in the Overview
abstract:
These mechanisms permit email receivers to make additional assessments
about
messages.
It's been an ongoing complaint of mine (and of others) that
re-charters are hard to review, because a new charter is usually
thrown at us with no indication of what's changed. With that in mind,
I wanted to make this one easier for folks to review. So I structured
it this way:
1. Explanation of the working group. For this, I changed the two
paragraphs that are there as little as possible, only changing the
tenses from future to past. I intend to mark them as "unchanged from
the original", so it's easier on the reviewers. Also, this text was
already approved, when we were first chartered.
2. Explanation of the current state. That's the list of work items
already done (the "history", as Dave puts it).
3. Plan for the future.
(And then 4. What's still out of scope.)
Because I want the working-group description to be unchanged to the
extent possible, I'd rather leave the text as is. On the other hand,
I certainly agree with Dave's suggestions, so if consensus is to make
the change, I'll do so. I'd like to hear other comments about it.
Isn't the second sentence incorrect? Doesn't DKIM mandate treated a failed
validation the same as no signature present?
That's not what that sentence means. It means that the specifications
don't tell you to do anything particular to the message in that case.
The intent was to point out that we don't say, "If the signature fails
to validate, be suspicious of the message," or "delete the message,"
or anything like that.
Do re-charters usually contain all this history?
I thought it was useful to include it. If there's consensus not to,
or if Pasi thinks it's clutter, I'll remove it.
Barry (as participant, editing new charter)
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html