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
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. S
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:
DomainKeys Identified Mail (DKIM) permits a person, role, or
organi
> to:
>
> title="Introduction">
>
> DomainKeys Identified Mail (DKIM) permits a person, role, or
> organization to claim some responsibility for a message by
> associating a domain name target="RFC1034" /> with the message. Th
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 5
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 a
> -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 rec
On Thu, Oct 14, 2010 at 12:45 AM, SM 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
"Barry Leiba" wrote:
>On Thu, Oct 14, 2010 at 12:45 AM, SM 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 existin
Barry Leiba wrote:
> On Thu, Oct 14, 2010 at 12:45 AM, SM 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
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 sa
Barry Leiba wrote:
> On Thu, Oct 14, 2010 at 12:45 AM, SM 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
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Barry Leiba
> Sent: Thursday, October 14, 2010 11:49 AM
> To: IETF DKIM WG
> Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
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, somethin
On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos 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
support
On Oct 15, 2010, at 1:58 PM, Barry Leiba wrote:
> On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos 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.
>>>
>>>
On Oct 15, 2010, at 10:58 AM, Barry Leiba wrote:
> On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos 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.
On Friday, October 15, 2010 01:58:07 pm Barry Leiba wrote:
> On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos 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.
> >>
>
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 c
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
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 exa
>> 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
On Fri, Oct 15, 2010 at 1:58 PM, Barry Leiba wrote:
> On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos 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.
> -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
> record
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 conflic
On 10/15/10 10:58 AM, Barry Leiba wrote:
> On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos
> 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.
> >>
> >>
>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 ha
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
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
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 o
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 spe
Hi Hector,
At 13:04 15-10-10, Hector Santos 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. :-)
>1) Verifier TXT record parsing
>
>I checked for this, but did not find it, but was a quick scan.
>
>If the DKIM specs
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
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 C
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 quot
> -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 - W
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
> -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
&g
38 matches
Mail list logo
