[ietf-dkim] Let's avoid "opaque"
ops.lists at gmail.com
Mon Feb 9 08:17:33 PST 2009
On Mon, Feb 9, 2009 at 9:33 PM, Eliot Lear <lear at cisco.com> wrote:
> Can someone please explain how something can be opaque and yet processed in
> g=, as SM has pointed out?
Opaque to OTHERS. As long as the g= and i= strings match, that's just
fine. I see no reason why the receiver must do other than a string
match to see that the two are the same.
g= Granularity of the key (plain-text; OPTIONAL, default is "*").
This value MUST match the Local-part of the "i=" tag of the DKIM-
Signature header field (or its default value of the empty string
if "i=" is not specified), with a single, optional "*" character
matching a sequence of zero or more arbitrary characters
("wildcarding"). An email with a signing address that does not
match the value of this tag constitutes a failed verification.
The intent of this tag is to constrain which signing address can
legitimately use this selector, for example, when delegating a
key to a third party that should only be used for special
purposes. Wildcarding allows matching for addresses such as
"user+*" or "*-offer". An empty "g=" value never matches any
Suresh Ramasubramanian (ops.lists at gmail.com)
More information about the ietf-dkim