Re: [ietf-dkim] [dkim] #11: 2.5 SDID minor nit

Dave CROCKER wrote: > I think that that's entirely the wrong question. > > For this stage of the document, the questions are: > > 1) What problems have been documented as being due to this wording? > 2) What technical errors does this text clearly represent. > > In both cases, the answe

Re: [ietf-dkim] [dkim] #11: 2.5 SDID minor nit

Murray S. Kucherawy wrote: > I think it's redundant to refer to a signed message, since that's what the > entire document is defining; if the message isn't signed, the document > doesn’t apply in the first place. > > So the question to me is more like: Is an intermediary adding a signature > g

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements

On Fri, 15 Apr 2011, Douglas Otis wrote: > In addition, verifiers MUST > ensure the presence of multiple singleton originating header fields > do not provide a valid signature result. > --- > > Not including this additional requirement removes recipient assurances a > sender may have expected to be

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements

> DKIM's design is predicated on valid input. Therefore, signers and > verifiers SHOULD take reasonable steps to ensure that the messages > they are processing are valid according to [RFC5322 > ], [RFC2045 > ], and > any other

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

> Instead, conversion to A-label form, or any other special encoding > required by a particular name-lookup protocol, should be done only by > an entity that knows which protocol will be used (e.g., the DNS > resolver, or getaddrinfo() upon deciding to pass the name to DNS), > rather than by genera

Re: [ietf-dkim] [dkim] #11: 2.5 SDID minor nit

On 4/15/2011 2:51 PM, Murray S. Kucherawy wrote: > So the question to me is more like: I think that that's entirely the wrong question. For this stage of the document, the questions are: 1) What problems have been documented as being due to this wording? 2) What technical errors does

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements

http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-3.8 ,--- DKIM's design is predicated on valid input. Therefore, signers and verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322 ],

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

On 4/13/11 12:23 PM, Dave CROCKER wrote: > On 4/13/2011 12:21 PM, John R. Levine wrote: >>> i'm also tempted to suggest using months in a different language, >>> with enero or >>> Januari... >> >> If you're going to change it, change it to 一月 or يناير > > not after i just got done trying to avoid

Re: [ietf-dkim] [dkim] #11: 2.5 SDID minor nit

> -Original Message- > From: dkim issue tracker [mailto:trac+d...@zinfandel.tools.ietf.org] > Sent: Friday, April 15, 2011 2:48 PM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: [dkim] #11: 2.5 SDID minor nit > > #11: 2.5 SDID minor nit > > http://mipassoc.org/pipermai

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Hector Santos > Sent: Friday, April 15, 2011 1:15 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3 > > Exactly.

[ietf-dkim] issue: 2.5 SDID minor nit

In Section 2.5, the text identity claiming responsibility for introduction of a message into the mail stream. seems to be odd and as stated technically untrue. Isn't SDID identity the responsible signer? SDID has no technical responsibility for either the creation of the message since

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

Murray S. Kucherawy wrote: > All of that discussion belongs in the deployment document or some > unwritten specs about policy or reputation (which is all semantics), > not in the base specification (which is all syntax). Exactly. +1. It is about syntax and not about unwritten specs for reputa

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Murray S. Kucherawy > Sent: Friday, April 15, 2011 12:11 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3 > > Al

Re: [ietf-dkim] [dkim] #10: Error in Appendix C. Creating a Public Key

Sure there is. There is an unwritten if condition for it to be incorrect or correct. Add the condition and then there is "nothing to fix" further. It could be as simply as adding: The following assumes you already have a zone file for _domainkey. The thing is WINDOWS DNS admins are goin

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Hector Santos > Sent: Friday, April 15, 2011 11:59 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3 > > > As for

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

Dave CROCKER wrote: > > On 4/15/2011 8:50 AM, Murray S. Kucherawy wrote: >> I'd suggest further than the definition as presented simply declares, and >> gives examples of, the kinds of things the RFC means when it uses the word >> "Identity". That simple definition doesn't imply (or exclude) any

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

Barry Leiba wrote: >> My proposed text attempts to inject the idea that at least one >> identity is an author authorized signer distinct from what is already >> stated as an independent trusted identity. > > But I don't think the actual "author" (in the case of this message, > me, the guy who's wr

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

On 4/15/2011 8:50 AM, Murray S. Kucherawy wrote: > I'd suggest further than the definition as presented simply declares, and > gives examples of, the kinds of things the RFC means when it uses the word > "Identity". That simple definition doesn't imply (or exclude) any particular > application.

Re: [ietf-dkim] [dkim] #10: Error in Appendix C. Creating a Public Key

On 4/15/2011 8:51 AM, Murray S. Kucherawy wrote: > Also, there's precedent in the RFC series for referring to the BIND zone file > format (RFC1034), so including an example of that seems appropriate. Meta-point: We should not be trying to fix hypothetical weaknesses in the document. We shou

Re: [ietf-dkim] [dkim] #10: Error in Appendix C. Creating a Public Key

> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Friday, April 15, 2011 8:26 AM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] [dkim] #10: Error in Appendix C. Creating a Public > Key > > Agree with Murray, there's nothing to f

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

> -Original Message- > From: barryleiba.mailing.li...@gmail.com > [mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba > Sent: Friday, April 15, 2011 6:05 AM > To: Hector Santos > Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] [dkim] #1: Suggesti

Re: [ietf-dkim] [dkim] #10: Error in Appendix C. Creating a Public Key

Agree with Murray, there's nothing to fix here. On Thu, 14 Apr 2011, Murray S. Kucherawy wrote: >> -Original Message- >> From: dkim issue tracker [mailto:trac+d...@zinfandel.tools.ietf.org] >> Sent: Thursday, April 14, 2011 7:04 AM >> To: Murray S. Kucherawy >> Cc: ietf-dkim@mipassoc.org

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

> My proposed text attempts to inject the idea that at least one > identity is an author authorized signer distinct from what is already > stated as an independent trusted identity. But I don't think the actual "author" (in the case of this message, me, the guy who's writing it) is involved in any

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

Murray S. Kucherawy wrote: >> -Original Message- >> #1: Suggestion to change text in section 2.3 >> [...] > > Consensus so far (pulling in pre-WGLC comments on the same topic) is to keep > the text as-is, and so far I concur with that position. I don't believe any > of > the proposed c