----- Original Message ----- From: "Barry Leiba" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, March 16, 2006 2:44 PM
> Now, z= was in IIM for that purpose, but in forming the DKIM > spec we decided to label it for diagnostic/tracing purposes, and not for > signature verification purposes. I fail to understand something here. Now you know this was incorrect and it needs to be an optional part of the specification to address these middle ware integrity issues. So what is the problem? I hope its not related to incompatible issues with the premature deploy base. IMO, DKIM-BASE is not ready for prime time without SSP protection and coherent set of operational procedures around it. Anyway, I asked related questions about Z= back in http://mipassoc.org/pipermail/ietf-dkim/2006q1/002375.html http://mipassoc.org/pipermail/ietf-dkim/2006q1/002408.html and only got 1 response. The way I view it is that software will need to be selective on what is hashed depending on where it is targeted. I use my AMEX on certain restaurants because it give me a "higher credentials" and I use MC/VISA on others. Same thing with DKIM. I am not going to use my most high-valued DKIM security domains in the public mail list. However, I might if I knew that the LIST SERVER will support it properly. So again, its about having upfront knowledge on where you are sending mail too. My MTA can have it all setup: Mail TO: CISCO.COM --> My signer will use HIGH-VALUE domain. Mail To: MIPASSOC.ORG --> No signing or a Relaxed Policy. I know that CISCO.COM will 100% honor the security. There is no guaranteed MIPASSOC.ORG will. And even if they did, I expect destructure of the original signatures and resigning of the distribution. So I have no choice but to provide a relaxed domain to him, even if they honors SSP or not. PS: I am willing to write a DRAFT I-D For "List Server DKIM Support Recommendations." Is that still desirable? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
