On Wed, 2006-08-09 at 13:53 -0700, Michael Thomas wrote: > Scott --- > > Scott -- I think it's both explicit and specific in other requirements > that the protocol must publish that data, and some of those are MUST > strength. I really don't see why we need to restate that here. > > That and I don't think there is any explicit or implicit proscription > here on when the protocol ought not be invoked. The restriction on was > forcing new behavior for a DKIM verifier, not on how the protocol > could be used. > > Mike > > Scott Kitterman wrote: > > >*** 574,580 **** > > blacklist repository.] > > > > 9. The Protocol MUST NOT be required to be invoked if a valid first > >! party signatures is found. > > > > 10. [PROVISIONAL] A domain holder MUST be able to publish a Practice > > which enumerates the acceptable cryptographic algorithms for > >--- 581,594 ---- > > blacklist repository.] > > > > 9. The Protocol MUST NOT be required to be invoked if a valid first > >! party signatures is found, [PROVISIIONAL] but the Protocol SHOULD > >! support publishing Practices for First Party DKIM signatures. > >! > >! [INFORMATIVE NOTE: the provisional requirement to support First > >! Party Practices is intended as an aid to the receiver. While > >! SSP lookups aren't required for First Party DKIM signatures, > >! there may be utility to receivers to determine Practices > >! associated with First Party DKIM signatures.] > > > > 10. [PROVISIONAL] A domain holder MUST be able to publish a Practice > > which enumerates the acceptable cryptographic algorithms for > >*************** > > > >This addition is suggested for a couple of reasons... > > > >1. Completeness. I think there is some value in providing a reasonably > >complete list of Practices. There will likely be effective uses for policy > >information by receivers that we haven't thought of yet. An incomplete set > >of practices may hamstring this kind of innovation. > > > >2. RFC 2821 discovery - This is the requirement change a alluded to > >yesterday > >in the signalling DKIM support before DATA thread. I won't rehash that here.
It is not clear from the definition for first party signature whether this includes a match where the d= parameter represents a parent of the first party address. There might be value in checking policy for whether the parent has been excluded as being authoritative for the first party address. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
