Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Mon, 18 Oct 2010 18:06:14 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John Levine Sent: Friday, October 15, 2010 7:14 PM To: ietf-dkim@mipassoc.org Cc: dcroc...@bbiw.net Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. OpenDKIM returns a syntax error in both cases. And to complete the picture, what does it do when verifying? -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Wednesday, October 20, 2010 3:52 AM To: DKIM Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. OpenDKIM returns a syntax error in both cases. And to complete the picture, what does it do when verifying? I'm not sure what you think both meant, but I meant it as when signing and when verifying. I don't know of any other DKIM operating modes. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
SM wrote: Hi Hector, At 09:28 16-10-10, Hector Santos wrote: From an IETF procedural angle. :) I'll comment on how I read what the WG Chairs said in general terms. If you believe that the process followed is not fair, you could discuss the matter with the WG Chairs. I'll quote a message from a WG Chair [1]: SM, I think you made a correlation I did not expect. But my question was: If 4871 does not speak of requiring the DKIM client of parsing merged TXT records to look for its specific inputs, then section 3.6.2.1 needs to make up for this dearth of verifier design information. I ask because in Murray's suggested text: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. I like it, but from an IETF standpoint, doesn't the last sentence imply a 'change of code' thing that we try to avoid here? There is, for example, a should in the text you quoted and some people may nit about it. Would the above text force a change of code in your implementation of DKIM? I think the way it is stated was design to avoid this. Right? Yes, it could be so. That is all I wanted to point out or ask about. My original text did not try to make any additional Verifier requirement even though I knew that that is what is required because DKIM failed or at least inadequately envision the mixed TXT issues. I'm not saying the text below should be used, but to point out it was addressed as a DNS management guideline. The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. I was trying to appease the IETF procedure here but not saying anything more about a verifier needs to do. But technically I do agree that we should be more specific and as Murray wrote Verifiers should expect this to occur and plan accordingly. I was just wondering is this was going to be a contentious point. Again, the posted issue was about the mixed TXT issue. I understood that DKIM was not specific regarding dealing with mixed TXT. What I don't know if that was on purpose, a presumption that was well understood a verifier will look for v=DKIM1 or just fell through the crack. In any case, I didn't want to post an issue that would add more requirements, but simply highlight for DNS management people to not make it difficult for DKIM adopters. But I think that might not be good enough and we might need to go ahead and add text about a verifier looking for the right string in a merged TXT response, just like SPF specification provides for its implementators. I am just wondering if you guys (the editors) recognize what appears to be a technical need conflicted with IETF procedure time lines to get this doc out the door. -- 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] ISSUE: 3.6.2.1 - Working with other TXT records
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John Levine Sent: Friday, October 15, 2010 7:14 PM To: ietf-dkim@mipassoc.org Cc: dcroc...@bbiw.net Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. OpenDKIM returns a syntax error in both cases. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
Hi Hector, At 09:28 16-10-10, Hector Santos wrote: From an IETF procedural angle. :) I'll comment on how I read what the WG Chairs said in general terms. If you believe that the process followed is not fair, you could discuss the matter with the WG Chairs. I'll quote a message from a WG Chair [1]: You're certainly welcome to file an appeal, if you think there's been a procedural problem. The first step, of course, is to bring the issue to the attention of the chairs (which you have), and the next is to discuss it with the responsible AD (Sean). That clearly states whom you can contact to discuss any IETF WG procedural problem. you can increase the chances that people will read your posts if you post clearly, concisely, and calmly (the three Cs?), and avoid invective and excess. That sounds like good advice. If we describe a problem clearly and concisely, it is easier for the readers to understand our arguments. It is easier to find a solution if we discuss the matter calmly. And quoting another message from a WG Chair [2]: I think it'd also be good if people could bear in mind that we're not saving or endangering the planet here - we're moving an RFC along the standards track by making very very minor changes and clarifications in a quite controlled fashion. (Most of which will be ignored by many coders;-) The first part explains the work this WG is trying to do. I gather that you do know that some of the advice in the RFC will be ignored whatever this WG says; the SHOULD will be reinterpreted to suit personal taste and some people will read the MUST as legal advice. But my question was: If 4871 does not speak of requiring the DKIM client of parsing merged TXT records to look for its specific inputs, then section 3.6.2.1 needs to make up for this dearth of verifier design information. I ask because in Murray's suggested text: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. I like it, but from an IETF standpoint, doesn't the last sentence imply a 'change of code' thing that we try to avoid here? There is, for example, a should in the text you quoted and some people may nit about it. Would the above text force a change of code in your implementation of DKIM? I think the way it is stated was design to avoid this. Right? Yes, it could be so. An issue similar to the one in the subject line was raised in 2008 [3]. Regards, -sm 1. http://mipassoc.org/pipermail/ietf-dkim/2010q4/015022.html 2. http://mipassoc.org/pipermail/ietf-dkim/2010q4/015063.html 3. http://mipassoc.org/pipermail/ietf-dkim/2008q2/010394.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
SM wrote: You can tell me if I am wrong here cause I am trying to make sure I It is not up to me to determine whether you are wrong. :-) From an IETF procedural angle. :) 1) Verifier TXT record parsing I checked for this, but did not find it, but was a quick scan. If the DKIM specs says that verifiers MUST be ready for different TXT records merged in the DNS Query response, it MUST parse for the string v=DKIM1 If this is the case, then I don't think we need to add anything. Its all good. That tag isn't always included in the DNS record for backward compatibility with DomainKeys. And it is optional. As you are doing a query for a TXT RR, expect garbage. However, in my personal engineering opinion, it probably should add a note for verifiers to be ready for multiple string responses. From RFC 3833: Much discussion has taken place over whether and how to provide data integrity and data origin authentication for wildcard DNS names. Conceptually, RRs with wildcard names are patterns for synthesizing RRs on the fly according to the matching rules described in section 4.3.2 of RFC 1034. While the rules that control the behavior of wildcard names have a few quirks that can make them a trap for the unwary zone administrator, it's clear that a number of sites make heavy use of wildcard RRs, particularly wildcard MX RRs. Regards, -sm The difference is that MX records are well structured fixed RR records, where merged TXT records have a multi-technology mix with multiple non-fixed structured definitions. So the client has to be aware of all of them or be savy enough to look for what for what it wants. But my question was: If 4871 does not speak of requiring the DKIM client of parsing merged TXT records to look for its specific inputs, then section 3.6.2.1 needs to make up for this dearth of verifier design information. I ask because in Murray's suggested text: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. I like it, but from an IETF standpoint, doesn't the last sentence imply a 'change of code' thing that we try to avoid here? I think the way it is stated was design to avoid this. Right? -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
support On Oct 15, 2010, at 1:58 PM, Barry Leiba wrote: On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? Barry, as chair ___ 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
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Oct 15, 2010, at 10:58 AM, Barry Leiba wrote: On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? I'm not sure whether wildcard records is relevant to the spec - that's more of a development, deployment and operations issue, I think. As a verifier implementor I'm not that interested in why someone is publishing bogus key records as I am in what I should do about them (fail if any are invalid, fail if there are multiple, check all of them and pass if any are valid...) - what's an appropriate response from the verifier in the case that the TXT records returned are unexpected. So the existing wording is harmless, and I'd support adding it, but something a little bit more prescriptive might be better. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Friday, October 15, 2010 01:58:07 pm Barry Leiba wrote: On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? Barry, as chair I'm neutral on the subject of covering this topic, but if we are going to cover it, this or similar text is good. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/15/2010 2:46 PM, Steve Atkins wrote: I'm not sure whether wildcard records is relevant to the spec - that's more of a development, deployment and operations issue, I think. The degree to which a processing environment is expected to be pure versus potentially noisy might well come into play during the specification phase. For example, it might be why a distinguishing label gets added. In this case, we've gone to some lengths to make the environment pure, by using the underscore branch. And then along come these pesky wildcards. 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] ISSUE: 3.6.2.1 - Working with other TXT records
At 08:25 14-10-10, Hector Santos wrote: I don't think I am suggesting to get into the bad DNS managements tools. But the section is short on what are possible error issues. One of them is making sure other TXT records don't conflict. I think that can be a general, generic statement that does not get into poor DNS management tools implementation. There are possible error issues which you won't find in the RFCs for DKIM. The wildcard in DNS is a known issue. You can catch it by looking for the DKIM1 tag in the DNS reply. If you are going to get into fixing the DNS side in the specification, you are opening the way to a new set of problems that are better addressed by a working group which is tasked to tackle DNS issues. You may, for example, encounter DNS failures because the primary is not in sync with the secondaries; or the backslash in the _domainkey DNS record; or assumptions that DNS queries should always be over UDP. At 09:22 14-10-10, Murray S. Kucherawy wrote: Seems OK to me. But doesn't EMAIL-ARCH talk about domain names and ADMDs and all that? Perhaps it's a better reference for this? That document is not a better reference as it is not about how DNS works. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/14/2010 12:22 PM, Murray S. Kucherawy wrote: Seems OK to me. But doesn't EMAIL-ARCH talk about domain names and ADMDs and all that? Perhaps it's a better reference for this? As much as I like to tout email-arch, the citation here needs to be specifically about the DNS and, for example, not about the DNS for mail. The fact that we hadn't even thought to include such basic citations in the original work on the draft provides good insight about the reader we are adding these for... 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] ISSUE: 3.6.2.1 - Working with other TXT records
The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. That text adds a requirement in an informative note. THat is the least of its problems. DKIM records go into a protected subbrance, given the underscore name. RFC 4871 discusses about DNS in various sections. Unfortunately, there is no reference to the DNS specifications. we've just fixed that during the current edits. 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] ISSUE: 3.6.2.1 - Working with other TXT records
On Fri, Oct 15, 2010 at 1:58 PM, Barry Leiba barryle...@computer.org wrote: On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? Does ADSP need to be mentioned? Otherwise +1. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Jeff Macdonald Sent: Friday, October 15, 2010 12:54 PM To: IETF DKIM WG Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records Does ADSP need to be mentioned? Otherwise +1. I don't think so. ADSP's built on top of DKIM, not the other way around. We could say the same thing in ADSP though if there's ever an ADSPbis (deity-of-your-choice help us...). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
SM wrote: This is just to jump start suggested text. Others can add/change whether they think helps: The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. That text adds a requirement in an informative note. SM, You can tell me if I am wrong here cause I am trying to make sure I understand the IETF angle to this but I also a product developer and have to look at the customer support angles as well. 1) Verifier TXT record parsing I checked for this, but did not find it, but was a quick scan. If the DKIM specs says that verifiers MUST be ready for different TXT records merged in the DNS Query response, it MUST parse for the string v=DKIM1 If this is the case, then I don't think we need to add anything. Its all good. This would be an implementation bug in our software if indeed that is what happening with invalid selector DKIM fails. 2) If #1 isn't part of the specs.. then I think there should be some note regarding working with other TXT records and to provide guidelines to DNS management software people to not enforce a wildcat only TXT record management solution for their customers. The note should not add a requirement for verifiers though (if this is going to an IETF RFC issue). However, in my personal engineering opinion, it probably should add a note for verifiers to be ready for multiple string responses. Note: For SPF, verifiers are already expecting and looking for the v=spfxxx strings in merged TXT records responses. This is required to support SPF and SENDERID. I see this as one of those things of an aged document drafted 4-5 years ago at the time where SPF was viewed as a competitive solution to DKIM and mentioning SPF or giving it credit for existing was probably not on editors mind. But today, SPF is real. Domain Hosting sites have tools to support it for the small to mid size market that are using their domain hosting name servers. DKIM should realize its wide presence from a DNS public key standpoint, not in a How to but to provide insight about the possible conflictive issues and I think its really just about those pesky wildcard DNS feature as Crocker put it. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/15/10 10:58 AM, Barry Leiba wrote: On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? +1 -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
In this case, we've gone to some lengths to make the environment pure, by using the underscore branch. And then along come these pesky wildcards. Even without wildcards, there's been a variety of broken key records. I would hope it would be obvious that you have to assume that any data you haven't previously verified is potentially hostile, either deliberately or by mistake. This refers to DNS keys, DKIM signatures, and the message you're trying to sign or verify. By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. R's from PHL gate F18, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Oct 15, 2010, at 7:13 PM, John Levine wrote: In this case, we've gone to some lengths to make the environment pure, by using the underscore branch. And then along come these pesky wildcards. Even without wildcards, there's been a variety of broken key records. I would hope it would be obvious that you have to assume that any data you haven't previously verified is potentially hostile, either deliberately or by mistake. This refers to DNS keys, DKIM signatures, and the message you're trying to sign or verify. By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? h=From with no From header is fairly well defined, I think. The message will be signed, and that signature will validate just fine, unless something in the message is modified - such as adding a From: field. I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. If it fails, it's broken, I think. There's nothing special about the From field, other than it having to be one of the signed headers. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
John Levine wrote: By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. For our DKIM implementation, it will fail to sign and fail to verify. -- 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] ISSUE: 3.6.2.1 - Working with other TXT records
Steve Atkins wrote: I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. If it fails, it's broken, I think. There's nothing special about the From field, other than it having to be one of the signed headers. The spec says 5.4. Determine the Header Fields to Sign The From header field MUST be signed (that is, included in the h= tag of the resulting DKIM-Signature header field). That means to me it MUST exist to be signed. -- 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] ISSUE: 3.6.2.1 - Working with other TXT records
On Oct 15, 2010, at 7:56 PM, Hector Santos wrote: Steve Atkins wrote: I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. If it fails, it's broken, I think. There's nothing special about the From field, other than it having to be one of the signed headers. The spec says 5.4. Determine the Header Fields to Sign The From header field MUST be signed (that is, included in the h= tag of the resulting DKIM-Signature header field). That means to me it MUST exist to be signed. h=From for a message that has no From: header when signed means that the message must have no From: header when the signature is validated, I think? And 5.4 just says you must include From in the h= tag, not that it must exist. A missing From: field makes the message not a 5322 message, but I'm not sure what that implies for DKIM. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/14/2010 12:45 AM, SM wrote: RFC 4871 discusses about DNS in various sections. Unfortunately, there is no reference to the DNS specifications. OMG. As in, wow. I propose changing from: section title=Introduction tDomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. to: section title=Introduction tDomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name xref target=RFC1034 / with the message. This can be an author's organization, an operational relay or one of their agents. ... Note that the sentence is slightly modified, which is the reason I'm running this past the wg. It defers reference to signing domain until later. 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] ISSUE: 3.6.2.1 - Working with other TXT records
to: section title=Introduction tDomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name xref target=RFC1034 / with the message. This can be an author's organization, an operational relay or one of their agents. ... Well, just to create a bit more of a rat-hole, is there any chance you'd like to add a definitional link for the word message as well? It seems to me that much of our other discussion swims around that meaning. Is it what is sent, is it what's signed, is it what shows up in the MUA... Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/14/2010 9:49 AM, Mark Delany wrote: Well, just to create a bit more of a rat-hole, is there any chance you'd like to add a definitional link for the word message as well? The easy and possibly sufficient answer is: RFC 5322. If more precision is required, then Section 3.5 of RFC 5322. Does anyone feel some other citation is necessary? Does anyone feel that the section number citation in 5322 is essential. (I only ask because adding a pure RFC citation to the opening sentence of the Introduction will be somewhat cleaner without it. section title=Introduction tDomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name xref target=RFC1034 / with the message xref target=RFC5322 /. This can be an author's organization, an operational relay or one of their agents. 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] ISSUE: 3.6.2.1 - Working with other TXT records
SM wrote: That text adds a requirement in an informative note. My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. There is an assumption that people managing DNS zones will have a basic understanding of DNS. I don't think that the DKIM specification should get into badly designed GUIs. RFC 4871 discusses about DNS in various sections. Unfortunately, there is no reference to the DNS specifications. I don't think I am suggesting to get into the bad DNS managements tools. But the section is short on what are possible error issues. One of them is making sure other TXT records don't conflict. I think that can be a general, generic statement that does not get into poor DNS management tools implementation. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Thursday, October 14, 2010 5:23 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records On 10/14/2010 12:45 AM, SM wrote: RFC 4871 discusses about DNS in various sections. Unfortunately, there is no reference to the DNS specifications. OMG. As in, wow. [...] to: section title=Introduction tDomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name xref target=RFC1034 / with the message. This can be an author's organization, an operational relay or one of their agents. ... Seems OK to me. But doesn't EMAIL-ARCH talk about domain names and ADMDs and all that? Perhaps it's a better reference for this? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote: At 17:31 13-10-10, Hector Santos wrote: My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. There is an assumption that people managing DNS zones will have a basic understanding of DNS. I don't think that the DKIM specification should get into badly designed GUIs. I agree, more generally, that the DKIM spec can't tell people the right way to manage their DNS records. DKIM already separates its TXT records with the _domainkey identifier, as SPF does with _spf. If, given that separation, people still merge the TXT records and whatnot, that problem's well beyond the scope of our work to fix. I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
Barry Leiba barryle...@computer.org wrote: On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote: At 17:31 13-10-10, Hector Santos wrote: My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. There is an assumption that people managing DNS zones will have a basic understanding of DNS. I don't think that the DKIM specification should get into badly designed GUIs. I agree, more generally, that the DKIM spec can't tell people the right way to manage their DNS records. DKIM already separates its TXT records with the _domainkey identifier, as SPF does with _spf. If, given that separation, people still merge the TXT records and whatnot, that problem's well beyond the scope of our work to fix. I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. Barry, as participant +1. Just as a note of clarification, SPF doesn't prefix TXT records, but I don't think that affects the analysis. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
Barry Leiba wrote: On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote: At 17:31 13-10-10, Hector Santos wrote: My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. There is an assumption that people managing DNS zones will have a basic understanding of DNS. �I don't think that the DKIM specification should get into badly designed GUIs. I agree, more generally, that the DKIM spec can't tell people the right way to manage their DNS records. DKIM already separates its TXT records with the _domainkey identifier, as SPF does with _spf. If, given that separation, people still merge the TXT records and whatnot, that problem's well beyond the scope of our work to fix. I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. I know you realize I was not advocating information on managing DNS records. But what happen today, is further evidence that even DNS administrators or software developers who are asked to write a WEB-BASED manager for their service to support SPF and now DKIM, are not aware of how mixing it is can be in conflict. All I ask is that possible a simple statement or sentence in that short section provide some insight regarding not mixing it up with other TXT records and that wildcards should not be used for other TXT records because this can fail the DKIM public key lookup. In this case, a customer is using Network Solutions and in their add TXT record, it doesn't allow a blank sub domain. The only way to do it is to have a subdomain: * (ALL OTHERS) domain: .xyz.com value: v=spf1 . Clearly, this a software bug and the customer called NS about how to get a non-wildcard SPF record because it was interfering with their new DKIM public and ADSP records setup. NS's (first level support) answer was (erroneous) - not possible. It doesn't work that way. So sure, this has to be fixed by NS, but what I am saying is that ISP people will also be reading the specs too perhaps to see what is required to implement Web-based DNS Records Management tools with DKIM and SPF support and what I am proposing is helpful insight on the design guidelines that would avoid conflicts. BTW, the customer (a government newsletter bulk spammer) had to delete his SPF record to get our DKIM implementation running with verifiable signatures. With the conflict, they were getting dkim invalid signatures with selector DNS errors. I'm sure they will be many customers who may not want to delete their SPF record in order to get DKIM working. So my suggestion is to help avoid these potential conflicts. It is not about going deep into DNS management issues. Just the basic DKIM public key integration issues with existing TXT records. If you don't think that is possible, ok. I think it is, but... :) -- 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] ISSUE: 3.6.2.1 - Working with other TXT records
Scott Kitterman wrote: +1. Just as a note of clarification, SPF doesn't prefix TXT records, but I don't think that affects the analysis. The Network Solutions DNS Records manager does not allow you to add a TXT record without a sub-domain, so to add one, you have to add * which when saved, it shows up as * (All Others) for the sub-domain column. For the new DKIM customer, we were assisting in adding the DKIM public key and ADSP records and this conflicted with the lookups return SPF records for all DKIM/ADSP record queries. Clearly, this is a problem with Network Solutions web tool. What I proposing is provide insight into potential conflicts with existing SPF (or other records) that might have a wild card associated with it. The audience will include ISPs that need guidelines as well and already have a SPF wizard or something or only allow * sub-domains to get a non-prefix domain query. These notes will help provide them and future implementations of DKIM DNS records support the insight to do it correctly. I hope DKIM is about catering to all sites small to large, not just large systems with DBA and DNS administrators. The insights should help adoptions without pains. -- 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] ISSUE: 3.6.2.1 - Working with other TXT records
Barry Leiba wrote: On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote: At 17:31 13-10-10, Hector Santos wrote: My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. There is an assumption that people managing DNS zones will have a basic understanding of DNS. �I don't think that the DKIM specification should get into badly designed GUIs. I agree, more generally, that the DKIM spec can't tell people the right way to manage their DNS records. DKIM already separates its TXT records with the _domainkey identifier, as SPF does with _spf. If, given that separation, people still merge the TXT records and whatnot, that problem's well beyond the scope of our work to fix. I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. I missed your statement above: ... as SPF does with _spf. SPF is a no prefix lookup. This is why it became a conflict because its possible domains are using wildcards and in at least in one case discovered today, Network Solutions does not allow you to add a TXT record without a sub-domain. You have to get around it with an asterisk (*) and it shows it as All Others. Maybe related, but I have not checked, does 4871 talk about parsing multiple records looking for the v=DKIM1 string? If not, then this is needs to be written about because if we don't want to see anything about wildcard SPF records, then we have implementations that will need to change their wares to only parse the v=DKIM1 string. -- 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.6.2.1 - Working with other TXT records
Folks, I know section 3.6.2.1 has this informative note: INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g., *.bar._domainkey.example.com) do not make sense in this context and should not be used. Note also that wildcards within domains (e.g., s._domainkey.*.example.com) are not supported by the DNS. But I think the section may need information about working with multiple or existing TXT records, i.e. SPF and the possibility that there could be a wildcard for other TXT records and this can provide a lookup error for DKIM public key records. This is just to jump start suggested text. Others can add/change whether they think helps: The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. Background reason: Today we got our 3rd field testers who ran into mixed up TXT records. All of them manage their DNS setup with ISP web based DNS managers for their small business but they are not DNS administrators. They did not understand how the DKIM public key TXT record is separate from other TXT records, like SPF. Two of them merged it with their existing SPF record and one of them had a wildcard SPF setup and this was always the result of DKIM public key lookups. When informed of this, he removed the wildcard setup for SPF but he merged his DKIM public key with his SPF record. My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. 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] ISSUE: 3.6.2.1 - Working with other TXT records
At 17:31 13-10-10, Hector Santos wrote: I know section 3.6.2.1 has this informative note: [snip] This is just to jump start suggested text. Others can add/change whether they think helps: The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. That text adds a requirement in an informative note. My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. There is an assumption that people managing DNS zones will have a basic understanding of DNS. I don't think that the DKIM specification should get into badly designed GUIs. RFC 4871 discusses about DNS in various sections. Unfortunately, there is no reference to the DNS specifications. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
