Re: [ietf-dkim] Output summary - Communicating Results
I'm starting a separate thread for the considered intro text discussion. This response attempts to provide DKIM in-scope justification why two additional outputs should be part of a more DKIM Complete Output summary. Murray S. Kucherawy wrote: That's probably true, but that is also completely different from necessitating a change to the mandatory output. Maybe this is about DKIM Output Complete rather to redundant burn in of what is mandatory. Everyone already knows SDID is a mandatory output for trust based assessor. The proposed text did say other outputs are possible, but I believe there is a minimal set of in-scope outputs that we know are useful bits of information because of what implementators are showing. Let me use ODID (Originating Domain Identity) to help describe this. I believe we have four minimal in-scope outputs that is consistent with the DKIM Service Architecture (RFC5585), Identity Assessor Layers and Reporting recommendations. RCODE result code) SDID d=, described as a MUST for (trust) assessors AUID i=, described as a MAY for assessors ODID Domain part of From: address. There is nothing new here and I believe satisfies IETF protocol design, bis work and DS considerations. It reflects current implementations, doesn't change code and definitely helps future implementors. Justifying ODID is simple: The ODID is an optional requirement in the complete software engineering design described in the DKIM Service Architecture [RFC5585]. While ODID is an optional consideration for implementors to support the Checking Signing Practices (ADSP) module, it is nonetheless part of the RFC described DKIM Service Architecture. Therefore for RFC4871bis to be consistent with RFC5585, it needs to explicitly expose the ODID as part of the DKIM Complete Output. Justifying AUID is simple as well. Dave's MLM shows an A-R (using Thomas's list post): Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=m...@mtcc.com It only shows the AUID. This suggest existing implementations are using the DKIM recommended A-R reporting method and needs the AUID as part of a DKIM Complete Outputs. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
Murray S. Kucherawy wrote: -Original Message- But what it did most of for me (yesterday) was highlight the confusion with AUID with the lack of an official DKIM label for an Originating Domain Identity. I guess I was moving forward the past year with integrating DKIM into our mail products and I see now I was mistakenly labeling the AUID as the FROM domain when its not officially defined as the From domain. That's unfortunate, but it's also the first case I've heard of someone mistaking the AUID for the From: field. To be more precise, may erroneous labeling of AUID as the author or user DOMAIN in the From: address for ADSP purposes. Its been an ongoing debate with what AUID (i=) is. Just see the recent threads with Fenton's proposal to remove it and some suggested to keep with refinements like i= should be the From address. This is why Barry's message is important here (got to find it) because if I can correctly recall, he showed both CON and PRO logic on how/why an undefined i= can be assumed to be the From and and the From.domain for ADSP purposes. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. We already have a name for that: RFC5322.From. We don't need a new name for something old. If we want to say From.Domain is an identity, fine by me. I don't see any ambiguity here that needs fixing, unless there are lots of people that want to come forward now and admit they had the same misunderstanding you did. There is plenty of archive evidence old and new regarding i= (AUID) ambiguity, including whether it should be a USER identity as the definition ambiguously says Agent or User. Who/What is an Agent? Undefined? Who is the User? I presume the RFC5322.From? No? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
John R. Levine wrote: What's your counter-proposal to Alessandro's proposal to modify 9.1.1? Oh, that. Replace all of sec 9.1 with: As noted in Section 4.4.5, use of the l= tag enables a variety of attacks in which added content can partially or completely changes the recipient's view of the message. I don't think we actually understand all the ways that l= allows you to shoot yourself in the foot, so I would prefer not to give the impression that if people avoid a few cases we describe, they're safe. +1 Unfortunately, if you do a global search in the document where l= is mentioned, you will see sentences with inferences for an expectation it is present and/or should be added. These sentences need to be reworded to indicate it is an option and not an expectation. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] New Introduction Text
Murray S. Kucherawy wrote: How will you state it? How about: 1. Introduction [...] 1.1. DKIM Architecture Documents Readers are advised to be familiar with the material in [RFC4686] and [RFC5585] and [RFC5863], which respectively provide the background for the development of DKIM, an overview of the service, and deployment and operations guidance and advice. 1.2. Signing Identity [...] +1 Perfect. Very good! I like it! Now if we can just be more DKIM Output Complete and be z-order compatible with the excellent section 1.1, I think I can die and rest in peace. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
Dave CROCKER wrote: In other words, DKIM has nothing to do with the rfc5321.From field, and therefore it is entirely inappropriate -- that is, out of scope -- for the specification to suggest dealing with it. At least, please show working group rough consensus support for doing what you suggest. Dave, All I am trying to do is show the inconsistencies in RFC4871bbis not matching current implementation needs and it is incomplete in what RFC5585 describes. I didn't write RFC5585 but if I did, I would not have added the Checking Signing Practice and titled it as DKIM Service Architecture because the concept was removed from DKIM. But you did and the Deployment Guide has an entire section on ADSP. The archive is my evidence, I have stated if you don't want ADSP then don't reference it any DKIM related document. But it was done in in the Deployments Guide and explicitly added as part of the DKIM Service Architecture, not stated it is an Extension or any one shown to be not part of the architecture. Its right there as a large part of the software engineering design. What do you expect people to think? So I suggest reasonable people taking this documents will clearly see policy, signing practice, adsp or whatever you wish to call, its part of the DKIM design and architectural consideration and RFC4871bis does not prepare anyone for that DKIM architecture design. IETF BIS work should be, at least I thought it was, about codifying current implementation and they match RFC5585, not RFC4871bis. Is that a problem? I think so. You seem to think not. All I am saying is with the window of opportunity we have now, connect the dots and be consistent with the RFC described DKIM Service architecture. Finally, you keep saying: DKIM has nothing to do with the rfc5321.From field (Well, I think you meant RFC5322.From. Right?) This is not technically correct. 1) It is the only single requirement for binding to the signature and there again, the archive evidence will show where I have stated on many occasions if we want the above statement to be true, then we need to relax the specs to remove this single mandatory binding signature requirement. 2) The binding of 5322.From is inherently associated with the SDID responsibility claim for the bits that are signed. So for anyone to use SDID trust, it is to both technically and ergonomically (UI) claim the author is trusted whether or not the signer had any association with the author or not. Again, its about protocol consistency. So maybe I should ask the chairs for: Consensus needs to be reevaluated -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
On 01/May/11 06:18, John R. Levine wrote: What's your counter-proposal to Alessandro's proposal to modify 9.1.1? Oh, that. Replace all of sec 9.1 with: As noted in Section 4.4.5, use of the l= tag enables a variety of attacks in which added content can partially or completely changes the recipient's view of the message. I don't think we actually understand all the ways that l= allows you to shoot yourself in the foot, so I would prefer not to give the impression that if people avoid a few cases we describe, they're safe. -1, I agree we don't know all the ways DKIM can be fooled. Neither we actually saw real attacks in the wild. We don't even state how to react to multiple Froms. Presumably, the wider the DKIM deployment, the more we'll learn on handling attacks. However, hiding the few things we know doesn't seem to be a good start toward such watchful cooperative deployment. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
I don't think we actually understand all the ways that l= allows you to shoot yourself in the foot, so I would prefer not to give the impression that if people avoid a few cases we describe, they're safe. -1, I agree we don't know all the ways DKIM can be fooled. Neither we actually saw real attacks in the wild. We don't even state how to react to multiple Froms. Presumably, the wider the DKIM deployment, the more we'll learn on handling attacks. However, hiding the few things we know doesn't seem to be a good start toward such watchful cooperative deployment. The message should be don't use l= if you care about your signature. I don't think we yet have consensus to take out l= but it is quite clear that the problems it causes are far greater than whatever problems it might solve. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
Dave CROCKER wrote: On 4/30/2011 9:10 PM, Hector Santos wrote: So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. Oh heck, let's just declare that the DKIM Signing module MAY output anything it wants. That's what 4871 did. Manifestly it worked just fine. We had a tremendous number of interoperable implementations. The procrustean insistence that there be a single output has not helped interoperability one iota. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
On 4/30/2011 11:43 PM, Murray S. Kucherawy wrote:
I'd like to leave in MIME and HTML exploits as examples if people agree that
wouldn't be harmful, such as this updated text in 4.4.5:
tINFORMATIVE IMPLEMENTATION NOTE: Using body length
limits enables an attack in which an attacker
modifies a
message to include content that solely benefits the
attacker. It is possible for the appended content to
completely replace the original content in the end
recipient's eyes, such as via alterations to the MIME
structure or exploiting lax HTML parsing in the MUA,
and to defeat duplicate message detection algorithms.
To avoid this attack, signers should be wary of using
this tag, and verifiers might wish to ignore the tag,
{DKIM 2} perhaps based on other criteria./t
I'm worried that without this, a neophyte won't see what the attack is.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
Alessandro Vesely wrote: On 01/May/11 06:18, John R. Levine wrote: What's your counter-proposal to Alessandro's proposal to modify 9.1.1? Oh, that. Replace all of sec 9.1 with: As noted in Section 4.4.5, use of the l= tag enables a variety of attacks in which added content can partially or completely changes the recipient's view of the message. I don't think we actually understand all the ways that l= allows you to shoot yourself in the foot, so I would prefer not to give the impression that if people avoid a few cases we describe, they're safe. -1, I agree we don't know all the ways DKIM can be fooled. Neither we actually saw real attacks in the wild. We don't even state how to react to multiple Froms. Presumably, the wider the DKIM deployment, the more we'll learn on handling attacks. However, hiding the few things we know doesn't seem to be a good start toward such watchful cooperative deployment. It appears to me, the current practical use case for l= is for systems like an non-DKIM aware MLM that is not stripping and replacing signatures. The idea of a non-tampered mail passthru concept. This at least should be stated. For DKIM aware MLM that are resigning, the l= concern is gone as long as the ODID (Originating Domain Identity) accepts the independent MLM DKIM resigning role. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
Michael Thomas wrote: Dave CROCKER wrote: On 4/30/2011 9:10 PM, Hector Santos wrote: So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. Oh heck, let's just declare that the DKIM Signing module MAY output anything it wants. That's what 4871 did. Manifestly it worked just fine. We had a tremendous number of interoperable implementations. The procrustean insistence that there be a single output has not helped interoperability one iota. Its just really odd that the we need to hide the facts in RFC4871bis but not in RFC5585 (DKIM Architecture) and RFC5863 (DKIM Deployment Guideline)? Ok, we got it! We need to isolate the signer domain for some future market place. I'm saving my pennies for this. Mission Accomplished. But in the mean time, implementors are not listening. They are looking at other things especially the author thing we must burn into the signature. Why is it so hard to document these facts in the new revised manual? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
Hector Santos wrote: Murray S. Kucherawy wrote: Hector stated: I think this message by Barry in March 2009 summarizing a conference call between Pasi, Stephen and Barry nicely captures the upper/lower layers, ADSP, i= and outputs conflicts that continue today: http://mipassoc.org/pipermail/ietf-dkim/2009q1/011314.html I think that message doesn't say a single thing about layers. It looks entirely procedural to me. Darn it. I copied the wrong link and now I can't find it. :( Let me search again.. Quick search failed. I'll search deeper later if you still want me to. I will find it at some point just to have it in my DKIM notes. Here is the correct message link: Status and direction http://mipassoc.org/pipermail/ietf-dkim/2009q1/011194.html For all and intent and purposes, this message can be reposted today and still bee relevant, covering the final issues we are still dealing with. Note the chairs recommended move forward items, in particular #4 which is what I believe we are trying to help with in this WGLC: 4. *Aim 4871bis at incorporating what we've learned since 4871.* If that results in a document that can and should move to Draft Standard, we'll do that. If it does not, then 4871bis will go to Proposed Standard, and it will take another round of work to move up the standards track. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
On 4/30/11 10:37 PM, Murray S. Kucherawy wrote: -Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: Saturday, April 30, 2011 9:10 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity But what it did most of for me (yesterday) was highlight the confusion with AUID with the lack of an official DKIM label for an Originating Domain Identity. I guess I was moving forward the past year with integrating DKIM into our mail products and I see now I was mistakenly labeling the AUID as the FROM domain when its not officially defined as the From domain. That's unfortunate, but it's also the first case I've heard of someone mistaking the AUID for the From: field. I think this missed Hector's concern. Perhaps it would have been clearer indicating confusion was in respect to i= parameter now called the AUID which can be a copy of an address that was within the From header field. The domain can differ whenever the AUID is a subdomain of the ODID when allowed by the key rr. Section 3.5 had stated the following omitted information: INFORMATIVE DISCUSSION: This document does not require the value of the i= tag to match the identity in any message header fields. This is considered to be a verifier policy issue. Constraints between the value of the i= tag and other identities in other header fields seek to apply basic authentication into the semantics of trust associated with a role such as content author. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the i= value and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence reliance on the use of these options should be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the i= options. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Sunday, May 01, 2011 4:51 PM To: Michael Thomas Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Its just really odd that the we need to hide the facts in RFC4871bis but not in RFC5585 (DKIM Architecture) and RFC5863 (DKIM Deployment Guideline)? I've lost track of how many times and how many different ways it's been explained that nothing is being hidden. I'm going to give up now. But in the mean time, implementors are not listening. They are looking at other things especially the author thing we must burn into the signature. Which implementers, and why aren't they saying anything? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
Is this new text for section 9.1 Misuse of Body Length Limits (l= Tag)?
Murray S. Kucherawy wrote:
INFORMATIVE IMPLEMENTATION NOTE: Using body length
limits enables an attack in which an attacker modifies a
message to include content that solely benefits the
attacker. It is possible for the appended content to
completely replace the original content in the end
recipient's eyes, such as via alterations to the MIME
structure or exploiting lax HTML parsing in the MUA,
and to defeat duplicate message detection algorithms.
To avoid this attack, signers should be wary of using
this tag, and verifiers might wish to ignore the tag,
{DKIM 2} perhaps based on other criteria.
I'm worried that without this, a neophyte won't see what the attack is.
I'm fine with the proposed simplification of 9.1, and I
think at least Dave and JD have +1'd it already as well.
Is that acceptable?
+1.
Small note if you are concern about neophytes. There are sentences
where l= is referenced where it sounds like the tag is expected to
be there or needs to used. So maybe an addition sentence can be
appended to above:
Signers do not need to add the l= tag to the signature
if they are signing the entire body.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
-Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: Sunday, May 01, 2011 5:33 PM To: Murray S. Kucherawy Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Here is the correct message link: Status and direction http://mipassoc.org/pipermail/ietf-dkim/2009q1/011194.html That message (a) was sent six months before ADSP was published, and (b) was written at a time when ADSP still made use of i=. If you take the time to read the text in RFC5617, it doesn't use i= at all. For all and intent and purposes, this message can be reposted today and still bee relevant, ...except that it doesn't cover what the working group actually published. covering the final issues we are still dealing with. Note the chairs recommended move forward items, in particular #4 which is what I believe we are trying to help with in this WGLC: 4. *Aim 4871bis at incorporating what we've learned since 4871.* If that results in a document that can and should move to Draft Standard, we'll do that. If it does not, then 4871bis will go to Proposed Standard, and it will take another round of work to move up the standards track. Sounds like precisely what we've done. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] WGLC version of drafts posted
Hello all, As you know WGLC for our two open drafts closed yesterday. The MLM draft hasn't changed in this round, so the -08 version can be considered the output of the WGLC for that draft. I'm in the process of posting an -09 for RFC4871bis, which I believe is the WGLC output for that draft. There are three open tickets remaining which were either controversial or did not appear to garner enough consensus support to include them. Of course, the Chair is the final authority on those points. Thanks all for the input and lively discussion. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
Murray S. Kucherawy wrote: -Original Message- Its just really odd that the we need to hide the facts in RFC4871bis but not in RFC5585 (DKIM Architecture) and RFC5863 (DKIM Deployment Guideline)? I've lost track of how many times and how many different ways it's been explained that nothing is being hidden. I'm going to give up now. If nothing is being hidden, then why not explicitly add AUID and ODID (or RFC5585.From.Domain) to the Output Summary? Whats the danger? Maybe its not a Output Summary? Here are some definitions for a summary [1]: A summary, synopsis, or recap is a shorter version of the original. Such a simplification highlights the major points from the much longer subject, such as a text, speech, film, or event. The purpose is to help the audience get the gist in a short period of time. An abstract or a condensed presentation of the substance of a body of material; concise, brief or presented in a condensed form; Performed speedily and without formal ceremony etc. What you are proposing is just the redundant Mandatory Output information, and not a DKIM Output Complete summary that reflects current implementations. But in the mean time, implementors are not listening. They are looking at other things especially the author thing we must burn into the signature. Which implementers, and why aren't they saying anything? Well you, I did and many in the archives has say things, and many have stated very clearly the ODID is considered a very fundamental part of DKIM. RFC5585 reflects how signing practices is part of the expected DKIM Architecture. The two open source APIs: OpenDKIM ALT-N has support for signing practices. Systems using A-R to report DKIM results are using AUID, such as Dave's MLM. And I know our DKIM product has direct support for the design described in RFC5595 including A-R with all four outputs (status, SDID, AUID, ODID) as well as the ADSP extensions. The biggest software company, Microsoft, has announced ADSP support and that means ODID output is required. How can that be not significant? Yes, it is getting tiresome because it is real hard to understand why adding the obvious to the Output Summary is a problem. What harm is there? None that I can see. Why isn't there any mediated compromise to settle these 5-6 years conflict? In my view, your proposed section 1.1 DKIM Architecture Documents and with adding the AUID and ODID as part of the output to make all the documents protocol consistent will settle the issue, in my view, for all parties. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com [1] http://www.google.com/search?rlz=1C1CHMG_enUS291US310q=define:summary ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
Murray S. Kucherawy wrote: -Original Message- Here is the correct message link: Status and direction http://mipassoc.org/pipermail/ietf-dkim/2009q1/011194.html That message (a) was sent six months before ADSP was published, and (b) was written at a time when ADSP still made use of i=. If you take the time to read the text in RFC5617, it doesn't use i= at all. Since day one POLICY anchored off the ODID in the same way Domainkeys, which has inherent support for POLICY, anchored off the ODID. There were suggestions as Barry noted due to the ambiguity (which remains today) for what i= should be and that included i=From and thus possibly it could be the feed for policy. But we also talking the ideas of extension modeling and outputs to pass to them. It was the beginning of reducing it to one only - signer and only for trust purposes, excluding the needs for ADSP. For all intent and purposes, this message can be reposted today and still bee relevant, except that it doesn't cover what the working group actually published. Exactly, which is why we still have the issues today. 4. *Aim 4871bis at incorporating what we've learned since 4871.* If that results in a document that can and should move to Draft Standard, we'll do that. If it does not, then 4871bis will go to Proposed Standard, and it will take another round of work to move up the standards track. Sounds like precisely what we've done. I take the position that 4871bis does not incorporate what we have learned since 4871. If it did, these concerns would not be on-going. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Issue: 3.9 Output Requirements - missing RFC5322.From
The new section 1.1 DKIM Architecture Documents advises reading RFC5585 (DKIM Service Architecture) and RFC5863 (Deployment Guideline). The new 3.9 Output Requirement does not provide the essential piece (RFC5322.From) explicitly described by the advised DKIM related RFC documents. A simple change will fix this in 3.9 last sentence: The output MAY include other signature properties or result meta- data, including RFC5322.From, PERMFAILed or otherwise ignored signatures, for use by modules that consume those results. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
On 5/1/2011 6:36 PM, Murray S. Kucherawy wrote: I've lost track of how many times and how many different ways it's been explained that nothing is being hidden. I'm going to give up now. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
Dave CROCKER wrote: On 5/1/2011 6:36 PM, Murray S. Kucherawy wrote: I've lost track of how many times and how many different ways it's been explained that nothing is being hidden. +1 Good. So there should not be a problem *not* hiding an explicit identity definition required to complete the DKIM Service Architecture in RFC5585: 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. INFORMATIVE IMPLEMENTATION NOTE: The ODID and SDID are inputs for the optional Checking Signing Practices component as described in the DKIM Service Architecture [RFC5585] If something like this is not added or anything close to it, I don't know any other way it can be described but an intentional neglect to mention anything closely related to it. I would like to ask the chairs if we can get Consensus Reevaluated. From the limited WG participants providing input, it appears we have Rough Consensus for this identity to be included in RFC4871bis. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
