+1 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Murray S. Kucherawy Sent: Tuesday, June 16, 2009 5:53 PM To: Cullen Jennings; [email protected] Cc: [email protected]; [email protected] Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)
> > <t>This update resolves that confusion. It defines > > additional, semantic > > labels for the two values, clarifies their nature and > > specifies their > > relationship. More specifically, it clarifies that the > > identifier > > intended for delivery to the assessor -- such as one that > > consults a > > white list -- is the value of the "d=" tag. However, this > > does not > > prohibit message filtering engines from using the "i=" tag, > > or any > > other information in the message's header, for filtering > > decisions. > > </t> > > Look, this is clear as mud - What I am getting is that the old > document was unclear if you should use the d= or the i= and this > document clarifies it to be you should use, uh, I'm totally lost here, > I use the d= for white lists, which are a form a filtering, but I can > also use the i= for filtering. > > I'm just unclear on what one is supposed to use and when. And honestly > it does not matter if I am confused in the slightest, but it does > matter if people implementing this stuff are unclear on this. > Evidently there is enough confusing about this that it is worth > writing an RFC to fix it - that I believe. However, people outside the > WG other than me seem like they too have a hard time reading this and > figuring out how this clarifies what to do. This does seem like a bit > of a problem. Think about it in terms of an API specification. The intent here, I believe, is to specify that "d=" is mandatory output of a DKIM verifier module. "i=" (and everything else, frankly) is optional. Thus, a compliant verifier implementation will give you a yes/no on the signature and the name of the domain in "d=". There may be other stuff there, but that's what you need for minimal compliance and interoperability. A consumer of such a minimal specification could conceivably interchange DKIM implementations and still keep working as before. However, there are no guarantees if such a consumer decides to try to make use of optional stuff like "i=" or "x=" or "l=" or whatever, because some other DKIM verifier implementation might not give that to you. But if you code for yes/no and "d=" only, then any compliant verifier will give you what you need to interoperate. If you as a consumer of such an API feel that you'd rather use "i=" for particular applications or types of messages, then either create or use an implementation that makes that value available. There's nothing wrong with that either. (If any of that language resolves the concern, feel free to use it.) -MSK _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
