Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Eliot Lear wrote: > The real question for me now is simply this: will those people who > are writing the overview now commit to updating it after SSP is > complete? And I for one want to see SSP complete quickly. Irrespective of whether we publish something now or not, the authors of the overview document have always been committed to publishing a version that includes SSP information *at the same time as the SSP protocol specification*. From the charter: Nov 2007WG last call on SSP protocol Nov 2007WG last call on overview document What we've been exploring in this little debate here is whether we should publish a version earlier without much SSP information in it. Tony Hansen [EMAIL PROTECTED] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Hallam-Baker, Phillip wrote: It is sufficient to have last call on the policy requirements. Well, it would be if we got some last-call comments. Can I ask folks to read ssp-reqs and send their comments please. Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Eliot Lear wrote: Hi, Given two sets of RECEIVERS: RECEIVER-A: Legacy DKIM-BASE system. Supports DKIM-BASE only RECEIVER-B: Updated to support DKIM-BASE+SSP and given a DOMAIN that has determined that it "better" to use SSP than not use SSP, therefore it uses a strong SSP policy for signing. then who do you think the BAD GUY will target? Simple: RECEIVER-A RECEIVER-A will bare the blunt of the premature decisions. The DOMAIN reputation will be harmed because there exist a legacy of DKIM-BASE only systems that bad guys will target. First, I'm not sure how DOMAIN comes into this equation. I suspect that RECEIVER-A will maintain a list of domains, either manually or out of band, that it knows signs messages, and may then weight messages from those domains with invalid signatures somewhat toward spam. The only issue is that RECEIVER-A may not be able to make an easy decision about a message with an invalid signature from a domain that has no SSP record. Perhaps it doesn't sign any mail. Right, or the DOMAIN signs all mail and Bad Guys (BG) target legacy systems, including RECEIVER-A DKIM-BASE only systems with no signature mail purportedly from this DOMAIN BGs will stay away from RECEIVER-B type systems. So using the word "break" is not a term I would use. But I would say that the promotion and recommendation that it is SAFE to use DKIM-BASE without any helper technology is in my strong opinion, a very poor engineering decision because it HARM receivers and domains. I just don't see this. Fair enough, it is just a consequence of the above which is not much different than today with BGs targetting legacy systems. Receiver-A, including non-DKIM ready system will feel the blunt of the exploitation. The unsuspecting domains, who unbeknowst to them, their domain is being used in vain at these sites (spoofed, phished), are harmed. No different than it is today. I'm just hoping that we don't begin march into a new era with the same mistakes of opening new holes due to incomplete considerations. Of course, RECEIVER-A would have to upgrade and I believe that is question Mr. Lear was poising to Mr. Powers. Will systems upgrade at a later point? No, my question was directed at Dave Crocker and Tony Hansen about whether they would be willing to revise the overview document. My apology. Rereading your message, I misread it to mean you were asking Mr Powers if they would upgrade (software) since he showed an urgency to get an operation going now. My bad, I read you wrong. Sorry. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Fwd: Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On Wed, 14 Mar 2007 15:20:28 -, Powers, Jot <[EMAIL PROTECTED]> wrote: It has come to my attention that perhaps I confused the discussions with "fixing" -base due to the FWS stuff, and overview. And speaking of the FWS stuff, I demonstrated that an actual BUG existed in base, and Frank confirmed that, but there has been no response from anyone in a position to fix it. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email:[EMAIL PROTECTED]: 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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On Thu, Mar 15, 2007 at 04:07:32AM -0700, Dave Crocker wrote: > The view that -base is sufficient presumes a) quite a high level of > expertise, I believe, and b) quite a high level of effort. Most managers > and decisions makers, out in the larger Internet, do not have either. You seem to be saying that a top to bottom strategy is needed. For that to happen you need to target Direct marketing publications. Writing an overview doc posted on the net probably won't be read by upper management. > Consequently, none of the folk in this working group are representative of > that larger community. (Dare I note that even within the working group, > there is often disparity on basic point about DKIM, which -overview ought > to be useful in settling? So who is overview really for? Management or implementors? -- :: Jeff Macdonald | Principal Engineer, Messaging Technologies :: e-Dialog | [EMAIL PROTECTED] :: 131 Hartwell Ave. | Lexington, MA 02421 :: v: 781-372-1922 | f: 781-863-8118 :: www.e-dialog.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Michael Thomas wrote: I think this touches on the important question about all of this: what are we trying to accomplish right now? My feeling is that we want as quickly as possible to fertilize the fields with as many DKIM signers as possible. This is a very straightforward proposition and -base provides the necessary blueprint on how to do that. This is concisely stated. I think it gets to the core view that many folk hold. And, yes, I disagree with it. But it's almost refreshing to disagree with such a clearly stated view. I tend towards viewing wide-spread adoption as difficult. Can't imagine where that perspective comes from... Successful adoption of brand new IETF work usually entails quite a bit of post-standards marketing, as in "educating". Getting folks on the same page about what to say is important and difficult. The view that -base is sufficient presumes a) quite a high level of expertise, I believe, and b) quite a high level of effort. Most managers and decisions makers, out in the larger Internet, do not have either. Consequently, none of the folk in this working group are representative of that larger community. (Dare I note that even within the working group, there is often disparity on basic point about DKIM, which -overview ought to be useful in settling? 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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Hi, I am more confused than ever, I suppose: Are you suggesting that deploying SSP will break dkim-base? Could you explain how, if so? Yes and No. The answer to your question depends on many factors, but it is really quite simple. This scenario is not new. Code Red and similar threats is based on the premise that there exist of market of old and legacy systems. Given two sets of RECEIVERS: RECEIVER-A: Legacy DKIM-BASE system. Supports DKIM-BASE only RECEIVER-B: Updated to support DKIM-BASE+SSP and given a DOMAIN that has determined that it "better" to use SSP than not use SSP, therefore it uses a strong SSP policy for signing. then who do you think the BAD GUY will target? Simple: RECEIVER-A RECEIVER-A will bare the blunt of the premature decisions. The DOMAIN reputation will be harmed because there exist a legacy of DKIM-BASE only systems that bad guys will target. First, I'm not sure how DOMAIN comes into this equation. I suspect that RECEIVER-A will maintain a list of domains, either manually or out of band, that it knows signs messages, and may then weight messages from those domains with invalid signatures somewhat toward spam. The only issue is that RECEIVER-A may not be able to make an easy decision about a message with an invalid signature from a domain that has no SSP record. Perhaps it doesn't sign any mail. So using the word "break" is not a term I would use. But I would say that the promotion and recommendation that it is SAFE to use DKIM-BASE without any helper technology is in my strong opinion, a very poor engineering decision because it HARM receivers and domains. I just don't see this. Of course, RECEIVER-A would have to upgrade and I believe that is question Mr. Lear was poising to Mr. Powers. Will systems upgrade at a later point? No, my question was directed at Dave Crocker and Tony Hansen about whether they would be willing to revise the overview document. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On Mar 14, 2007, at 6:42 PM, Hector Santos wrote: We are not talking about DAY 1 of the Internet here. But 35+ years, and we have enough knowledge and insight to know today that if you can recognize the creation of a potential problem, then it would be neglectful if a) you didn't bring it up and b) if you continue to pursue such a course to allow it to happen. DKIM represents a change in how message content can be identified. Placing information at the domain helps in preventing false-positive filtering of valid messages and allows more aggressive filtering of phishing attempts. DKIM does not include any means to determine whether a transmitter is controlled by an affiliated entity, or whether there is a chance a message is part of campaign expending the signer's clout with abusive replays. Perhaps a lower false-positive rate with a means to assure email-addresses is more than good enough. DKIM serving as a basis for white-listing also depends on who is allowed to utilize the signing-domain. Unless each person obtains their own signing-domain, DKIM signature abuse will likely preclude the general public from obtaining enhanced deliverability. : ( When everyone obtains their own signing-domain, tracking reputations will be difficult. Everyone will also be in jeopardy of having their signature besmirched by replays of perhaps innocent messages, as tolerance for abusive replays may become wickedly low. Bad actors are obtaining millions of new domains every day. How many bad emails will it take before a signing-domain ends up on someone's do-not-accept list? This could be worse than an IP address black- hole listing, as DKIM requires the signing-domain match that of the assured email-address. Someone's email-address could easily become forfeit as a result of the abuse DKIM policy does not offer a means to control. Not even your version SSP helps with this type of problem either. While the Internet has been around for a while, the next few years will be bringing in many changes. The only thing that remains the same is change. It seems there are many possible scenarios ignored with your policy categorizations. Bad actors are good at leveraging weaknesses that few thought would become a problem at the time. However, Edward Murphy is seldom wrong. : ) -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
--On March 14, 2007 8:11:11 AM -0700 Dave Crocker <[EMAIL PROTECTED]> wrote: Eliot, you are, of course, correct. But that rather misses the point. The point is what will facilitate adoption. (Why is it that the IETF works so hard to ignore adoption issues, as we think merely publishing a document is the end of the task?) The Overview document, approximately in its current form (IMO), can be extremely helpful for the rest of the community, to understand DKIM and make deployment and use decisions about it. I'm not saying that having some sort of overview document is a good thing for assisting with adoption. I am saying that it doesn't need to be an RFC. It can be just a draft, or (horrors) a non-IETF document. I *am* saying that taking the time and effort to get WG consensus, go through Last Call, IESG Approval, and the RFC Editor queue is just overhead for now. Wait until we have the whole thing before we go through the expense of formalizing it. eric ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Wietse Venema wrote: Hector Santos: This is exactly the same problem that the industry evolved to over the past two decades and what has brought us together here. The problem is dealing with the legacy market of old SMTP systems and how the bad guys use this to gain entry into systems. If that wasn't the problem then we would have FULL control of all anonymous transactions. Indeed. The evolutionary approach does not work. It has saddled us up with a series of legacy systems that we need to cope with. Instead, we need to get things right the first time. Therefore we need to discourage deployment until we have achieved the complete and perfect solution. After that point has been reached, the world will be perfect forever and nothing will ever need to be changed. Of course, that is silly so I don't know why you brought it up. Nonetheless, there is nothing wrong with having a "Getting right the first time" approach to design. Its a QA thing, not an ABSOLUTE and if you do some research, you will find this old mantra is once again growing in engineering, management and QA circles. The goal? To minimize duplicity of rework, potential problems for you and customers and hence cost. We are not talking about DAY 1 of the Internet here. But 35+ years, and we have enough knowledge and insight to know today that if you can recognize the creation of a potential problem, then it would be neglectful if a) you didn't bring it up and b) if you continue to pursue such a course to allow it to happen. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Hector Santos: > This is exactly the same problem that the industry evolved to over the > past two decades and what has brought us together here. The problem is > dealing with the legacy market of old SMTP systems and how the bad guys > use this to gain entry into systems. If that wasn't the problem then we > would have FULL control of all anonymous transactions. Indeed. The evolutionary approach does not work. It has saddled us up with a series of legacy systems that we need to cope with. Instead, we need to get things right the first time. Therefore we need to discourage deployment until we have achieved the complete and perfect solution. After that point has been reached, the world will be perfect forever and nothing will ever need to be changed. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Steve Atkins wrote: On Mar 14, 2007, at 1:28 PM, Hector Santos wrote: I could be wrong, but I believe he was referring to backward compatibility issues with a new legacy market of DKIM-BASE only systems vs DKIM-BASE PLUS SSS systems. Are you suggesting that deploying SSP will break dkim-base? Could you explain how, if so? Yes and No. The answer to your question depends on many factors, but it is really quite simple. This scenario is not new. Code Red and similar threats is based on the premise that there exist of market of old and legacy systems. Given two sets of RECEIVERS: RECEIVER-A: Legacy DKIM-BASE system. Supports DKIM-BASE only RECEIVER-B: Updated to support DKIM-BASE+SSP and given a DOMAIN that has determined that it "better" to use SSP than not use SSP, therefore it uses a strong SSP policy for signing. then who do you think the BAD GUY will target? Simple: RECEIVER-A RECEIVER-A will bare the blunt of the premature decisions. The DOMAIN reputation will be harmed because there exist a legacy of DKIM-BASE only systems that bad guys will target. So using the word "break" is not a term I would use. But I would say that the promotion and recommendation that it is SAFE to use DKIM-BASE without any helper technology is in my strong opinion, a very poor engineering decision because it HARM receivers and domains. Of course, RECEIVER-A would have to upgrade and I believe that is question Mr. Lear was poising to Mr. Powers. Will systems upgrade at a later point? Of course, I think the answer is YES if such systems realize that its better to upgrade. But we can only hope it is sooner than later so that we minimize the number of legacy of DKIM-BASE only systems. Hope this helps --- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On Mar 14, 2007, at 1:28 PM, Hector Santos wrote: Dave Crocker wrote: The real question for me now is simply this: will those people who are writing the overview now commit to updating it after SSP is complete? And I for one want to see SSP complete quickly. Whether the current document is "updated", or a new document is written, or an overview section in the SSP specification itself is added strikes me as a decision to make at the time we need the additional writing. I could be wrong, but I believe he was referring to backward compatibility issues with a new legacy market of DKIM-BASE only systems vs DKIM-BASE PLUS SSS systems. Are you suggesting that deploying SSP will break dkim-base? Could you explain how, if so? Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Dave Crocker wrote: The real question for me now is simply this: will those people who are writing the overview now commit to updating it after SSP is complete? And I for one want to see SSP complete quickly. Whether the current document is "updated", or a new document is written, or an overview section in the SSP specification itself is added strikes me as a decision to make at the time we need the additional writing. I could be wrong, but I believe he was referring to backward compatibility issues with a new legacy market of DKIM-BASE only systems vs DKIM-BASE PLUS SSS systems. I'm certainly happy to commit to putting in the effort to make sure there is text of an overview style for SSP. Well, IMO, you talk about independent, value-added assessment services in a futuristic manner anyway, why SSP wasn't there or included in the first place speaks volumes about the true nature of the problem here. FWIW, I am prime example of a target audience member your overview attempts to address. I would probably be asking "what are these independent, value-added services, and do they exist today?" -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Absolutely. And the question that I raized was rather different. The question is whether we should publish a version of the overview with references to policy taken out. I do not accept that we have to wait till completion of the policy specification to publish a version of overview. It is sufficient to have last call on the policy requirements. The overview document does not go into the details of how policy works, requirements are sufficient. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker > Sent: Wednesday, March 14, 2007 11:11 AM > To: Eliot Lear > Cc: Untitled; Powers, Jot > Subject: Re: [ietf-dkim] Re: I-D > ACTION:draft-ietf-dkim-overview-04.txt > > > > Eliot Lear wrote: > > Jot, > > > > The overview isn't keeping DKIM from the world. In fact > you guys can > > sign today, if you don't already (haven't checked). > > Eliot, you are, of course, correct. But that rather misses the point. > > The point is what will facilitate adoption. (Why is it that > the IETF works so hard to ignore adoption issues, as we think > merely publishing a document is the end of the task?) > > The Overview document, approximately in its current form > (IMO), can be extremely helpful for the rest of the > community, to understand DKIM and make deployment and use > decisions about it. > > > > The real question > > for me now is simply this: will those people who are writing the > > overview now commit to updating it after SSP is complete? > And I for > > one want to see SSP complete quickly. > > Whether the current document is "updated", or a new document > is written, or an overview section in the SSP specification > itself is added strikes me as a decision to make at the time > we need the additional writing. > > I'm certainly happy to commit to putting in the effort to > make sure there is text of an overview style for SSP. > > d/ > -- > >Dave Crocker >Brandenburg InternetWorking >bbiw.net > ___ > 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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Dave Crocker wrote: Eliot Lear wrote: Jot, The overview isn't keeping DKIM from the world. In fact you guys can sign today, if you don't already (haven't checked). Eliot, you are, of course, correct. But that rather misses the point. The point is what will facilitate adoption. (Why is it that the IETF works so hard to ignore adoption issues, as we think merely publishing a document is the end of the task?) The Overview document, approximately in its current form (IMO), can be extremely helpful for the rest of the community, to understand DKIM and make deployment and use decisions about it. Who, exactly, is this "rest of the community"? I'd say that there are at least two distinct communities: 1) software/hardware vendors as well as open source implementations writing DKIM 2) IT folks deploying (1) From what I can tell, (1) seems to be doing pretty OK with what we've given them. Google's recent introduction of dkim signing seems to have only required -base (actually -allman-01) to get them going. And google isn't the only one who's digested the spec and popped out an implementation. As for (2), I suspect they are going to be taking their cues from (1). Arvel's user base is a great testament of how (2) needs software that makes doing the right thing easy. I don't think they need any deep understanding of the motivations and mechanics -- and for Arvel's customers an awareness that the IETF even exists :) So I'm sort of dubious -- at this stage -- that either of these is the *necessary* audience. Or is there some other necessary audience? I can see this later as I've already written, but not now. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Powers, Jot wrote: On 3/14/07 8:01 AM, "Michael Thomas" <[EMAIL PROTECTED]> scribbled: Powers, Jot wrote: On 3/12/07 5:43 AM, "Tony Hansen" <[EMAIL PROTECTED]> scribbled: In other words, would folks prefer to: A. Expedite publishing the Overview documents, in order to facilitate development and deployment of the -base specification (with an update later on for SSP), or +1 B. Defer the Overview document until the SSP specification is complete. As the largest phishing target out there, we're interested in having DKIM be out there as soon as possible, without waiting for SSP, because even "fast" for the IETF process isn't particularly speedy, whereas spammers and phishers are. Not to pick on Jot, but this is very illustrative of why putting -overview in the path right now may be very counter-productive. -Base *is* done. Waiting for -overview is *not* required. The best possible wait time is the zero you can do by reading -base right now and deploying it. Don't worry, I can take it. :) I almost wrote: C: Wait for nothing. But I was trying to be a good little list member and only vote on the options provided. Just to be clear: We would DKIM sign now (and did a while ago) if our appliance vendor supported DKIM, which they plan on doing, once it is a "standard" for some value of "standard". (They have said summer '07) Our approach is that we don't care about chicken's or eggs, we just love a nice chicken omlete. :) I think this touches on the important question about all of this: what are we trying to accomplish right now? My feeling is that we want as quickly as possible to fertilize the fields with as many DKIM signers as possible. This is a very straightforward proposition and -base provides the necessary blueprint on how to do that. I really don't think we need anything more elaborate than that (from an IETF perspective, that is). How receivers use the verification results will hopefully become a lot more apparent once we have a critical mass of people signing, and this is a *good* thing -- we're creating a tool, not a solution. When that plays out, I think it would be very useful to document that, and any SSP related practices into a BCP. That's what I've envisioned -overview as being a start on: an eventual BCP. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On 3/14/07 8:00 AM, "Eliot Lear" <[EMAIL PROTECTED]> scribbled: > Jot, > > The overview isn't keeping DKIM from the world. In fact you guys can > sign today, if you don't already (haven't checked). The real question > for me now is simply this: will those people who are writing the > overview now commit to updating it after SSP is complete? And I for one > want to see SSP complete quickly. It has come to my attention that perhaps I confused the discussions with "fixing" -base due to the FWS stuff, and overview. I read the discussion as having Overview be one of the solutions to this, and thus holding up base, not SSP. If that is the case, I apologize for muddying the waters. Regardless, I would like to see RFCs move forward (be it base or SSP) without waiting for an overview document. -Jot -- Jot Powers <[EMAIL PROTECTED]> Phone: 480-862-7234Cell: 480-221-1157 Skype: jotebay ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On 3/14/07 8:01 AM, "Michael Thomas" <[EMAIL PROTECTED]> scribbled: > Powers, Jot wrote: >> On 3/12/07 5:43 AM, "Tony Hansen" <[EMAIL PROTECTED]> scribbled: >> >>> In other words, would folks prefer to: >>> >>> A. Expedite publishing the Overview documents, in order to facilitate >>> development and deployment of the -base specification (with an update >>> later on for SSP), or >> >> +1 >> >>> B. Defer the Overview document until the SSP specification is complete. >> >> As the largest phishing target out there, we're interested in having DKIM be >> out there as soon as possible, without waiting for SSP, because even "fast" >> for the IETF process isn't particularly speedy, whereas spammers and >> phishers are. > > Not to pick on Jot, but this is very illustrative of why putting > -overview in the path right now may be very counter-productive. > -Base *is* done. Waiting for -overview is *not* required. The > best possible wait time is the zero you can do by reading -base > right now and deploying it. Don't worry, I can take it. :) I almost wrote: C: Wait for nothing. But I was trying to be a good little list member and only vote on the options provided. Just to be clear: We would DKIM sign now (and did a while ago) if our appliance vendor supported DKIM, which they plan on doing, once it is a "standard" for some value of "standard". (They have said summer '07) Our approach is that we don't care about chicken's or eggs, we just love a nice chicken omlete. :) -Jot -- Jot Powers <[EMAIL PROTECTED]> Phone: 480-862-7234Cell: 480-221-1157 Skype: jotebay ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Jot, The overview isn't keeping DKIM from the world. In fact you guys can sign today, if you don't already (haven't checked). The real question for me now is simply this: will those people who are writing the overview now commit to updating it after SSP is complete? And I for one want to see SSP complete quickly. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Eliot Lear wrote: Jot, The overview isn't keeping DKIM from the world. In fact you guys can sign today, if you don't already (haven't checked). Eliot, you are, of course, correct. But that rather misses the point. The point is what will facilitate adoption. (Why is it that the IETF works so hard to ignore adoption issues, as we think merely publishing a document is the end of the task?) The Overview document, approximately in its current form (IMO), can be extremely helpful for the rest of the community, to understand DKIM and make deployment and use decisions about it. > The real question for me now is simply this: will those people who are writing the overview now commit to updating it after SSP is complete? And I for one want to see SSP complete quickly. Whether the current document is "updated", or a new document is written, or an overview section in the SSP specification itself is added strikes me as a decision to make at the time we need the additional writing. I'm certainly happy to commit to putting in the effort to make sure there is text of an overview style for SSP. 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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Powers, Jot wrote: On 3/12/07 5:43 AM, "Tony Hansen" <[EMAIL PROTECTED]> scribbled: In other words, would folks prefer to: A. Expedite publishing the Overview documents, in order to facilitate development and deployment of the -base specification (with an update later on for SSP), or +1 B. Defer the Overview document until the SSP specification is complete. As the largest phishing target out there, we're interested in having DKIM be out there as soon as possible, without waiting for SSP, because even "fast" for the IETF process isn't particularly speedy, whereas spammers and phishers are. Not to pick on Jot, but this is very illustrative of why putting -overview in the path right now may be very counter-productive. -Base *is* done. Waiting for -overview is *not* required. The best possible wait time is the zero you can do by reading -base right now and deploying it. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On 3/12/07 5:43 AM, "Tony Hansen" <[EMAIL PROTECTED]> scribbled: > In other words, would folks prefer to: > > A. Expedite publishing the Overview documents, in order to facilitate > development and deployment of the -base specification (with an update > later on for SSP), or +1 > B. Defer the Overview document until the SSP specification is complete. As the largest phishing target out there, we're interested in having DKIM be out there as soon as possible, without waiting for SSP, because even "fast" for the IETF process isn't particularly speedy, whereas spammers and phishers are. -Jot -- Jot Powers <[EMAIL PROTECTED]> Phone: 480-862-7234Cell: 480-221-1157 Skype: jotebay ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On Mon, 12 Mar 2007 12:43:58 -, Tony Hansen <[EMAIL PROTECTED]> wrote: In other words, would folks prefer to: B. Defer the Overview document until the SSP specification is complete. +1 -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email:[EMAIL PROTECTED]: 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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Dave Crocker wrote: The -base document does not provide a general systems-framework for understanding the role of -base, because that was not a goal for -base. -overview provides that framework. More generally, the deployment of security-related protocols has a long history of being problematic. Understanding why and how DKIM is a credible mechanism, in the face of that problematic history, also is not something -base was intended to provide, since it is a specification rather than a tutorial. On the other hand, -base does help with that understanding. Given the disagreements with how people view dkim as being used in reality, I'd suggest that a dose of reality may be required before the overview you seek has any chance at consensus. I've already seen -overview being misconstrued by the Mailman folks to strip signatures given some editorializing about that subject. And we know what happens when we talk about those disagreements. I've been a proponent for a DKIM BCP for a long time. I think that is where -overview fits in, and it will make a huge amount of sense when we actually have enough experience to make a BCP -- and that goes for SSP as well. As it currently stands, there is far too much room for speculation so I think it is pretty much a waste of time to be going over the same set of arguments that we didn't overcome the last time. As far as the hand-wringing about -base not being enough.. I just don't buy it. We have a lot of implementations and deployments (esp. counting DK) even with the paucity of overview material. So that's not the problem. Nor does not doing -overview now prevent writing DKIM evangelizing articles/papers/etc that fill that gap -- with as much speculation as the author feels like dreaming up. So that's not the problem either. So what is the problem that -overview is trying to solve that _requires_ official IETF status *right now*? Mike Mike And so on... Deployment is not a technical issue, so much as a management decision issue. -Base is not intended to help decision makers or designers of the framework into which DKIM will fit. The -Overview document is intended to help with this. For anyone who is serious about wanting to get DKIM used, I would think that they would want it used sooner, rather than later. Anything that will facilitate the 'sooner' ought to be a straightforward choice. In particular, I do not understand the idea of delaying something that can be of significant use for early-stage -base adoption, and waiting for some unknown moment in the problematic future, when SSP might eventually converge and get approved. d/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Jeff Macdonald wrote: On Tue, Mar 13, 2007 at 10:01:03AM -0700, J.D. Falk wrote: On 2007-03-12 16:51, Hector Santos wrote: I tend to side with the high probability that blindly signing MAIL in a DKIM-BASE only manner (with no helper support, and I presume you are just against SSP, not other kind of helpers, like DAC or some other yet to be established reputation helper) Hmm, not sure who you're arguing with here -- can't be me, I'm not against SSP. Never have been. I just don't think it's a good idea to continue telling the world that DKIM isn't ready. I don't think the 'world' understands that DKIM is just a building block. I don't think the "world" understands that a building block does not mean it is a public consumption technology without the helper blocks. In fact, putting out a "building block" before it the required parts are ready can do more harm than good. The easiest issue to envision is that this can build a new legacy market of "DKIM-BASE" systems that now the receiver has to deal with. Lets say you finally (by you, I am speaking in general), finally realize that DKIM-BASE by itself, although theoretically usable, it is not practical to be used on its own. You realize you need something else before you can turn it on. What then? What are the rules for the receiver? - Support DKIM-BASE only systems? - Don't Support DKIM-BASE only systems? This is exactly the same problem that the industry evolved to over the past two decades and what has brought us together here. The problem is dealing with the legacy market of old SMTP systems and how the bad guys use this to gain entry into systems. If that wasn't the problem then we would have FULL control of all anonymous transactions. So by drinking your wine before its time, we risk wasting the potential of a promising technology being forced into the market place before essential elements are at the very least, settled for final development. I'm not against DKIM-BASE. I'm against premature decisions that will ruin it. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
J.D. Falk wrote: On 2007-03-12 16:51, Hector Santos wrote: I tend to side with the high probability that blindly signing MAIL in a DKIM-BASE only manner (with no helper support, and I presume you are just against SSP, not other kind of helpers, like DAC or some other yet to be established reputation helper) Hmm, not sure who you're arguing with here -- can't be me, I'm not against SSP. Never have been. I just don't think it's a good idea to continue telling the world that DKIM isn't ready. We can probably drive a car with just the frame, engine, wheels, etc but no body yet and get good use of it. You will be exposed to the elements of the world during the process of using it, but its usable. Some people won't care and some people actually like the eating bugs. Some will be excited to have it now. However, I'm sure most people will prefer that there was "added security," "a helper,", "a wrapper," "a blanket," "a body" that helps protects you from the elements. So is the frame ready? Sure, 100%, it still has its kinks. But is it ready. I don't think anyone disputes that. But is it ready for public consumption? Has all the engineering been worked out so that its SAFE to be used in the public? Does it present any liability issues? Is an early release better with the risk of creation a wide tertiary market of "different helper" systems in the name of getting exposure and experience with this "frame-" work., or is better to have an augmenting IETF standard helper technology? -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Jeff Macdonald wrote: I don't think the 'world' understands that DKIM is just a building block. That is one of the reasons for wanting to get the Overview document out sooner, rather than 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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On Tue, Mar 13, 2007 at 10:01:03AM -0700, J.D. Falk wrote: > On 2007-03-12 16:51, Hector Santos wrote: > > >I tend to side with the high probability that blindly signing MAIL in a > >DKIM-BASE only manner (with no helper support, and I presume you are > >just against SSP, not other kind of helpers, like DAC or some other yet > >to be established reputation helper) > > Hmm, not sure who you're arguing with here -- can't be me, I'm not > against SSP. Never have been. I just don't think it's a good idea to > continue telling the world that DKIM isn't ready. I don't think the 'world' understands that DKIM is just a building block. -- :: Jeff Macdonald | Principal Engineer, Messaging Technologies :: e-Dialog | [EMAIL PROTECTED] :: 131 Hartwell Ave. | Lexington, MA 02421 :: v: 781-372-1922 | f: 781-863-8118 :: www.e-dialog.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On 2007-03-12 16:51, Hector Santos wrote: I tend to side with the high probability that blindly signing MAIL in a DKIM-BASE only manner (with no helper support, and I presume you are just against SSP, not other kind of helpers, like DAC or some other yet to be established reputation helper) Hmm, not sure who you're arguing with here -- can't be me, I'm not against SSP. Never have been. I just don't think it's a good idea to continue telling the world that DKIM isn't ready. -- J.D. Falk, Anti-Spam Product Manager Yahoo! Mail ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Jeff Macdonald wrote: On Mon, Mar 12, 2007 at 08:43:58AM -0400, Tony Hansen wrote: In other words, would folks prefer to: A. Expedite publishing the Overview documents, in order to facilitate development and deployment of the -base specification (with an update later on for SSP), or +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On Mon, Mar 12, 2007 at 08:43:58AM -0400, Tony Hansen wrote: > In other words, would folks prefer to: > > A. Expedite publishing the Overview documents, in order to facilitate > development and deployment of the -base specification (with an update > later on for SSP), or +1 -- :: Jeff Macdonald | Principal Engineer, Messaging Technologies :: e-Dialog | [EMAIL PROTECTED] :: 131 Hartwell Ave. | Lexington, MA 02421 :: v: 781-372-1922 | f: 781-863-8118 :: www.e-dialog.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Eric Allman wrote: --On March 12, 2007 8:43:58 AM -0400 Tony Hansen <[EMAIL PROTECTED]> wrote: In other words, would folks prefer to: A. Expedite publishing the Overview documents, in order to facilitate development and deployment of the -base specification (with an update later on for SSP), or B. Defer the Overview document until the SSP specification is complete. B. But I think I'm going against the flow. +1. I'd like to focus on SSP, but wouldn't rule out a draft (which wouldn't be published as an RFC) that contains deployment guidance in the interim. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
J.D. Falk wrote: On 2007-03-12 11:05, Steve Atkins wrote: On Mar 12, 2007, at 10:34 AM, Wietse Venema wrote: Tony Hansen: However, I'd like to hear some discussion on the issue: Should we put out a version now (without the SSP references), or hold off until SSP is totally finished? I would not wait with an Overview document until SSP is ready for prime time. I would encourage deployment of DKIM-base now so that we can gain useful experience. +1 +1 We're also more likely to get DKIM widely deployed before there's much real-world experience with SSP than after. SSP is pointless if it scares everyone away from deploying DKIM at all. It is totally ironic that there come could be two opposite viewpoints. Of course, one of us is going to be proven wrong. :-). I tend to side with the high probability that blindly signing MAIL in a DKIM-BASE only manner (with no helper support, and I presume you are just against SSP, not other kind of helpers, like DAC or some other yet to be established reputation helper), will not only open the door for DOMAIN reputation damage but make DKIM as useless as the NO POLICY DRIVE DOMAINKEYS currently is in the wide public open market place. If there is any proof that a DKIM-BASE only concept will be proven to be worthless (not widely adopted across the board), all anyone has to do is look are DOMAINKEYS. I take the position that if this issues are known as they are today and we fail to do something about it, then we acted irresponsibly. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
I would not wait with an Overview document until SSP is ready for prime time. I would encourage deployment of DKIM-base now so that we can gain useful experience. I sure hope that -overview is not looked upon as a necessary ingredient for developing/deploying -base. Because I don't think it is. In order to decide to deploy -base, one must understand not only its details, but the context in which it is supposed to operate. The -base document does not provide a general systems-framework for understanding the role of -base, because that was not a goal for -base. -overview provides that framework. More generally, the deployment of security-related protocols has a long history of being problematic. Understanding why and how DKIM is a credible mechanism, in the face of that problematic history, also is not something -base was intended to provide, since it is a specification rather than a tutorial. On the other hand, -base does help with that understanding. And so on... Deployment is not a technical issue, so much as a management decision issue. -Base is not intended to help decision makers or designers of the framework into which DKIM will fit. The -Overview document is intended to help with this. For anyone who is serious about wanting to get DKIM used, I would think that they would want it used sooner, rather than later. Anything that will facilitate the 'sooner' ought to be a straightforward choice. In particular, I do not understand the idea of delaying something that can be of significant use for early-stage -base adoption, and waiting for some unknown moment in the problematic future, when SSP might eventually converge and get approved. 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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On 2007-03-12 11:05, Steve Atkins wrote: On Mar 12, 2007, at 10:34 AM, Wietse Venema wrote: Tony Hansen: However, I'd like to hear some discussion on the issue: Should we put out a version now (without the SSP references), or hold off until SSP is totally finished? I would not wait with an Overview document until SSP is ready for prime time. I would encourage deployment of DKIM-base now so that we can gain useful experience. +1 +1 We're also more likely to get DKIM widely deployed before there's much real-world experience with SSP than after. SSP is pointless if it scares everyone away from deploying DKIM at all. -- J.D. Falk, Anti-Spam Product Manager Yahoo! Mail ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
--On March 12, 2007 8:43:58 AM -0400 Tony Hansen <[EMAIL PROTECTED]> wrote: In other words, would folks prefer to: A. Expedite publishing the Overview documents, in order to facilitate development and deployment of the -base specification (with an update later on for SSP), or B. Defer the Overview document until the SSP specification is complete. B. But I think I'm going against the flow. eric ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
At 1:34 PM -0400 3/12/07, Wietse Venema wrote: I would not wait with an Overview document until SSP is ready for prime time. I would encourage deployment of DKIM-base now so that we can gain useful experience. +1 --Paul Hoffman, Director --Domain Assurance Council ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Having spent a day reading through the draft from start to finish I think it is hard to see how to untangle the two. Policy is a major motivation behind a lot of what is in the overview. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Thomas > Sent: Monday, March 12, 2007 1:57 PM > To: Wietse Venema > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Re: I-D > ACTION:draft-ietf-dkim-overview-04.txt > > Wietse Venema wrote: > > Tony Hansen: > > > >> However, I'd like to hear some discussion on the issue: > Should we put > >> out a version now (without the SSP references), or hold > off until SSP > >> is totally finished? > >> > > > > I would not wait with an Overview document until SSP is ready for > > prime time. I would encourage deployment of DKIM-base now > so that we > > can gain useful experience. > > > I sure hope that -overview is not looked upon as a necessary > ingredient for developing/deploying -base. Because I don't > think it is. > > My preference is to wait and have one document that covers both. > >Mike > ___ > 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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
I don't think we need to agree on the policy implementation to get overview out. We do have to have agreement on the requirements. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Wietse Venema > Sent: Monday, March 12, 2007 1:34 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Re: I-D > ACTION:draft-ietf-dkim-overview-04.txt > > Tony Hansen: > > However, I'd like to hear some discussion on the issue: > Should we put > > out a version now (without the SSP references), or hold off > until SSP > > is totally finished? > > I would not wait with an Overview document until SSP is ready > for prime time. I would encourage deployment of DKIM-base now > so that we can gain useful experience. > > Wietse > ___ > 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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
On Mar 12, 2007, at 10:34 AM, Wietse Venema wrote: Tony Hansen: However, I'd like to hear some discussion on the issue: Should we put out a version now (without the SSP references), or hold off until SSP is totally finished? I would not wait with an Overview document until SSP is ready for prime time. I would encourage deployment of DKIM-base now so that we can gain useful experience. +1 We're also more likely to get DKIM widely deployed before there's much real-world experience with SSP than after. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Wietse Venema wrote: Tony Hansen: However, I'd like to hear some discussion on the issue: Should we put out a version now (without the SSP references), or hold off until SSP is totally finished? I would not wait with an Overview document until SSP is ready for prime time. I would encourage deployment of DKIM-base now so that we can gain useful experience. I sure hope that -overview is not looked upon as a necessary ingredient for developing/deploying -base. Because I don't think it is. My preference is to wait and have one document that covers both. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Tony Hansen: > However, I'd like to hear some discussion on the issue: Should we put > out a version now (without the SSP references), or hold off until SSP is > totally finished? I would not wait with an Overview document until SSP is ready for prime time. I would encourage deployment of DKIM-base now so that we can gain useful experience. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Hi Tony, My technical and "product attraction" opinion is: The original scope (SSP) was on track with addressing with what I believe were the most marketable features of the product: - High benefits for exclusive domain policies - High benefits in exposing the nature of domain usage As a product producer, this is how I am going to be able to "help" the "world of domains" outside my own control. It is what I see my customers will desire, and at the same time, as a USER of the product, I would like to also protect my own domains being exploited and used at other compatible DKIM/SSP systems out there. I would rather that they honor our DKIM/SSP own policies. We are simply not going to protect the entire spectrum of DKIM with no or flexible SSP policies. But we can MOST definitely address domains (HIGH VALUE or not, but HIGH VALUE will probably be most interested) with "tigher" policies who simply do not expect MIDDLE WARE and/or LIST SERVERS to be "touching" or passing thru such mediums. In effect, we want to provide "increased assurances" to the domains wanting to increase security value with direct communications with their end-users and target recipients. In short, speaking as one vendor, we will not expose our customers with a "out of the box" DKIM solution until we have a SSP or similar concept wrapper concept. I see absolutely no value in a DKIM-BASE only system and in fact, could hurt more than it helps and the longer DKIM-BASE is used and ignored, the more it becomes obsolete. So if all possible, I "vote" for concurrent (or near) release of both specs, whatever that means in terms of IETF. I think Jim Fenton's updated SSP-03 is good enough to start and it covers the "features" that I outlined in my own (now expired) draft DSAP which was strategically written to simply highlight the concerns. With that, I support SSP-03 rather than continue with DSAP. -- HLS Tony Hansen wrote: [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DomainKeys Identified Mail (DKIM) Message Signing Service Overview As you read through this, you will find that the stuff in it dealing with SSP is only part way there. This is hardly unsuprising since SSP itself is only part where there. An outstanding issue from the last IETF was (quoting the minutes): Tony Hansen reviewed the status of the DKIM Overview document, and we got another "hum" from the room about preference to put the document out soon, to aid implementations of the DKIM base, with a possible second version later, covering subsequent topics... or to publish the overview document only after the working group completes (or largely completes) the rest of its work. The consensus was again not overwhelming, and was marginally in favour of publishing a first version now. Given the lukewarm consensus before about publishing this document now versus later, we didn't push hard one way or the other for the latest update. However, I'd like to hear some discussion on the issue: Should we put out a version now (without the SSP references), or hold off until SSP is totally finished? Tony Hansen [EMAIL PROTECTED] ___ 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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Tony Hansen wrote: In other words, would folks prefer to: A. Expedite publishing the Overview documents, in order to facilitate development and deployment of the -base specification (with an update later on for SSP), or B. Defer the Overview document until the SSP specification is complete. B. I would rather see us put all of our efforts into concluding work on SSP. Any distraction from that adds no functionality and will simply require revision when SSP is eventually complete, thus making more work. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
In other words, would folks prefer to: A. Expedite publishing the Overview documents, in order to facilitate development and deployment of the -base specification (with an update later on for SSP), or B. Defer the Overview document until the SSP specification is complete. Tony Hansen [EMAIL PROTECTED] Tony Hansen wrote: > [EMAIL PROTECTED] wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : DomainKeys Identified Mail (DKIM) Message >>Signing Service Overview > > As you read through this, you will find that the stuff in it dealing > with SSP is only part way there. This is hardly unsuprising since SSP > itself is only part where there. > > An outstanding issue from the last IETF was (quoting the minutes): > > Tony Hansen reviewed the status of the DKIM Overview document, > and we got another "hum" from the room about preference to put > the document out soon, to aid implementations of the DKIM base, > with a possible second version later, covering subsequent > topics... or to publish the overview document only after the > working group completes (or largely completes) the rest of its > work. The consensus was again not overwhelming, and was > marginally in favour of publishing a first version now. > > Given the lukewarm consensus before about publishing this document now > versus later, we didn't push hard one way or the other for the latest > update. > > However, I'd like to hear some discussion on the issue: Should we put > out a version now (without the SSP references), or hold off until SSP is > totally finished? > > Tony Hansen > [EMAIL PROTECTED] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
