On 3/26/18 5:40 PM, Brotman, Alexander wrote: > So, we'd need to create a new Service Type (I see only * and email > currently), correct? Could we alternately use the "n=" field and require > that the note be set to "tlsrpt"? If we do add this, and the receiving party > is unable to find the appropriate s= or n= for the key, should they then > discard the report?
In RFC 6376, the description of n= begins, "Notes that might be of interest to a human (qp-section; OPTIONAL, default is empty). No interpretation is made by any program." You're describing interpretation that would be made by a program, so using n= would be the wrong approach. Adding a service type involves putting an IANA consideration in the draft saying that the specification requests that some value be added to the DKIM Service Types registry. Shouldn't be hard to do, and it is the Right Thing (IMO). The s= for the key comes as part of the DNS response with the public key, so there can't be a situation where you can retrieve the key but not the service type. The default is "*", so if s= isn't there, you should accept the report. If s=email (only) is there, yes, you should discard the report, since eliminating that sort of abuse is the reason for doing this in the first place. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
