Murray S. Kucherawy wrote:
Incorporated most of your suggestions. A new draft is coming shortly.
Charles Lindsey wrote:
Should we allow for the possibility of more than one <propspec>?
For example:
dkim=pass header(_dot_)i=sender(_at_)example(_dot_)com
header.t=1189079141
I might consider including "header.d", but really the intent of this
clause of the result is to indicate what sender or signer was
authenticated. "header.t" doesn't really make any indication of such.
this reminds me. auth-res as it stands now (or at least the last time i
read the
draft) conflates DKIM/DK signatures and SSP/policy. What I've done -- and
I've never been entirely happy about it -- is have two different
results, one for
the sigs if it doesn't match From, and every thing else. What occurs to
me is that
I too was conflating DKIM and SSP.
Here's what I think we need to have (approximately):
dkim-sig=foo(_at_)example(_dot_)com; dkim=pass|fail;
perhaps we might also want to have a new field for what header(s)
(From, Sender, List-Id...) it matches too. Note no neutral. It simply
doesn't make any sense at all to have neutral for sig verification.
Next:
ssp=pass|fail|neutral;
and perhaps we even want to say whether it's fail/strict or fail/all ala the
new SSP draft.
This seems a *lot* better. Things that really only care about SSP or
other policy things can just scan for that. Things that care about third
parties, etc, etc would need to parse the whole enchilada.
One last thing: we should probably tailor each of these to the individual
protocol it's returning results for. As in, let's not try to be heroic
about
grand unified theories.
Mike
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html