On Feb 13, 2008, at 3:58 PM, Jim Fenton wrote:
Douglas Otis wrote:
Jim,
The service type that could be noted in the key does will not work
as there are no defined key locations. The policy scope needs to
be within the policy record or reflected in the label used to
locate the record.
I'm not depending on the key; I'm simply noting that since there is
extensibility of DKIM signatures beyond SMTP and that it may be
desirable to have similar extensibility of SSP.
Understood, but this does not help much. This does not prevent
negatively rating unsigned messages traversing a protocol not covered
by the DKIM policy assertion. It may also be that new protocols will
also introduce use of DKIM policies. When messages are being merged
by various protocol gateways, the correct policy should be applied at
the point of ingress. A restriction on the SSP record as being
limited to SMTP may mean messages emerging from this mailing-list
could become non-compliant with a From domain's "all" assertion. This
non-compliance might be forgiven by a mailing-lists favourable DKIM
signature rating, and the policy would not be applied against the non-
SMTP protocol.
Depending upon the label works well, but then there might be a
desire to signal "cease and desist" when there are multiple
policies. The "cease and desist" state can be generally defined
as the presence of the policy record with the absence of the
discovery record.
I don't know what a "discovery record" is.
The discovery record is how the transmitter discovers the receiver.
In the case of SMTP, this can be defined as being an MX record when
policy is published.
Why can't the practices for these other services be located at the
same place?
Domains are unlikely to apply DKIM in all possible places at once.
Conflicting assertions may therefore result when not scoping the
protocol coverage of the policy record.
It seems unlikely that we will ever have that many services using
RFCx822 for content that we'll run out of record space.
You mean space to scope protocols within the policy record? Agreed,
and assuming a default scope of SMTP also seems appropriate. Using
different labels rather than a scope parameter providers greater
flexibility. The protocol used to accept the message should be known
by the verifier. (See authenticated-results header.)
Feel free to quote me widely when I'm wrong about that.
It might be good to scope protocols within the key as well, but
frankly that seems less of a problem. You can quote me as well. : )
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
