Subject: Re: [ietf-dkim] Issue 1550 - the name of the document (remains open *briefly*); there's still disagreement on "Author"

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Mar 2008 16:14:49 -0700 (PDT)

I'm coming down on the side that the strong language against changing 
drafts is unjustified.

Moreover, I prefer the name change because at the moment one could 
implement the -02 draft, looking for "_ssp" and applying that algorithm, 
*and* the -03 draft, looking for "_asp" and applying that algorithm, *and* 
the -04 draft, looking for "_adsp" (or whatever it will be) and applying 
that algorithm.  One could moreover put the selection in the hands of the 
user *or* implement all of them and return some sort of consolidated 
result.  Who knows?  We might even be able to collect statistics that 
reveal meaningful conclusions about one algorithm over the other.

Changing the draft (which is, after all, only a draft and thus 
experimental) shouldn't shatter any production implementations.  Ripping 
out -02 support and adding -03 didn't take me very long at all, maybe an 
afternoon, and it also wouldn't be a giant deal for me to exhume the -02 
code and run them in parallel.

I've left my _ssp records up in my test domains too, so interoperability 
at least with my installations shouldn't be broken even if they change the 
name another dozen times.

This answers JD's question:

> Are there any current implementations of asp in the wild?

Yes, mine is one.  There may be others, but I've not heard of any.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 13 Mar 2008 19:00:27 -0400

> Yes, mine is one.  There may be others, but I've not heard of any.

Disclaimer:  this is just my own approach on how I've handled this issue - your mileage may vary.

Back in early November 2007, MDaemon 9.63 was released which included a full implementation of the then current SSP draft (well, it was the one that changed to _ssp and dkim=unknown/strict/all etc).  We also updated our open source library for the same.  I simply documented in my release notes what to change in DNS to turn old records into new ones and instructed customers that they would have to do this themselves.  

In fact, that version of MDaemon dropped support entirely for the older SSP and included some commentary to the effect that I was hopeful we were close to a final SSP (turns out we weren't at that time but that's fine).  I further warned my customers in the same release notes that work on SSP continues (meaning more changes were likely).

I think this approach is good enough in my case because although I have been overly optimistic at times concerning our progress I have nevertheless been warning my customers that SSP is contentious (much MUCH more so than BASE) and thus likely to go through several revisions.  I've sort of smoothed this over by reminding customers that they were helping the process by using the various incarnations and reporting on any technical failings.  So far, I've not been flooded with complaints other than "you people hurry up and get this done already" which is to be expected.

I plan to take the same approach when moving from _ssp/dkim=unknown/strict/all to whatever the final draft requires.

Arvel

---

From: "J D Falk" <[email-masked]>
Date: Fri, 14 Mar 2008 13:14:42 -0400

Arvel explained:

> I think this approach is good enough in my case because although I
> have been overly optimistic at times concerning our progress I have
> nevertheless been warning my customers that SSP is contentious (much
> MUCH more so than BASE) and thus likely to go through several
> revisions.  I've sort of smoothed this over by reminding customers
> that they were helping the process by using the various incarnations
> and reporting on any technical failings.  So far, I've not been
> flooded with complaints other than "you people hurry up and get this
> done already" which is to be expected.

Do you think that the change to _asp or _adsp or _frodo and
all/discardable will cause unhappiness amongst your installed base, or
should we keep going with the near-consensus changes?

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 14 Mar 2008 12:24:40 -0500

> should we keep going with the near-consensus changes?

No, not unhappiness.  At most some will consider it a minor annoyance 
but they will recall that they were warned to expect this.  So, it's not 
a major issue to me.

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Mar 2008 14:33:02 -0400

Now I know you are fibbing.

You are saying that your customers actually remember being warned.

Have you been seeling to some off-world market niche?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 14 Mar 2008 13:59:49 -0500

> You are saying that your customers actually remember being warned.

It's true that many don't read the release notes or pay attention to 
official posts in MDaemon related discussion forums.  But, in my view, 
they were warned regardless.  One can choose not to listen but one can't 
say that nobody was talking.

-- 
Arvel

---

From: Douglas Otis <[email-masked]>
Date: Fri, 14 Mar 2008 12:03:46 -0700

On Mar 14, 2008, at 10:14 AM, J D Falk wrote:
>
> Do you think that the change to _asp or _adsp or _frodo and all/ 
> discardable will cause unhappiness amongst your installed base, or  

Concerns raised about the term "discardable" have to do with the  
related action thereby implied.  This action is likely inappropriate  
for those that once expected to be asserting they are the sole signers  
of their domain.  Those that give up delivery integrity for security  
deserve neither.  Rather than arguing against this suggested assertion  
and its related action, a different assertion is still needed to  
preserve delivery integrity.  A reporting mechanism does not offer a  
practical solution for the problem the "discardable" assertion might  
create, and invites possible exploits of its own.  Perhaps the term  
"strict", "sole", or "exclusive" must be added to prevent customer  
unhappiness.  I can imagine the conversation, "Why did you set a  
policy that requested discarding my domain's messages?"  When this is  
the desired result, then the assertion would be fine.  When this is  
not the desired result, a different assertion would be necessary.  The  
bottom line is that the "discardable" can not be used to solve the  
problem defined in RFC 5016.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Mar 2008 15:06:46 -0400

Arvel Hathcock wrote:
>   One can choose not to listen but one can't 

again, your experience with your customers differs so dramatically with the kind 
i used to have to support.  some were even in texas.

and you make a profit, too.

my stetson is off to you.

d/

-- 

   Dave Crocker