Subject: [ietf-dkim] 1359: ssp-requirements-01 // Outsource First Party Signing concerns extended

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Oct 2006 11:12:55 -0700

https://rt.psg.com/Ticket/Display.html?id=1359

There was some agreement on the list regarding considerations  
pertaining to who should receive the abuse feedback enabled by the  
DKIM signature.

When a designation scheme is considered, then this feedback  
consideration becomes far more significant.  Some assume the signing  
domain will accrue a reputation for unsolicited commercial email, but  
this overlooks limitations in the DKIM protocol making such  
accountability impossible.

While DKIM may provide a means for accruing a list of domains that  
either do or do not phish, it does not provide a means for accruing a  
lists of domains that do or do not send unsolicited commercial  
email.  As a result, accrual of reputation for general acceptance  
will continue to be done by the IP address of the SMTP client.  This  
consideration significantly alters assumptions regarding which domain  
should be signing the messages, and what role domain designation  
might play.

-Doug 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Oct 2006 15:08:22 +0100

Doug,

That was agreed to be closed on the jabber session.

No-one spoke against that, so please consider this closed/rejected.

(Eliot - you can close it now, thanks.)

Stephen.

Douglas Otis wrote:
> There was some agreement on the list regarding considerations pertaining 
> to who should receive the abuse feedback enabled by the DKIM signature.
> 
> lists of domains that do or do not send unsolicited commercial email.  
> As a result, accrual of reputation for general acceptance will continue 
> to be done by the IP address of the SMTP client.  This consideration 
> significantly alters assumptions regarding which domain should be 
> signing the messages, and what role domain designation might play.
> 
> -Doug_______________________________________________
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
>

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 11 Oct 2006 08:02:43 -0700 (PDT)

> No-one spoke against that, so please consider this closed/rejected.

You're quite wrong. Number of people spoke - just not on the jabber. 
You're abusing jabber as means of making decision for WG items -
jabber is just a discussion forum for some group of WG participants
but as per IETF rules all decisions are really done based on discussions 
on the list.

---
William Leibzon
Elan Networks
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Oct 2006 16:05:36 +0100

william(at)elan.net wrote:
> You're quite wrong. 

If so, apologies. Can you point me at the mail archive please? (I
mean since we discussed this in the jabber session and I posted
the summary.)

 > Number of people spoke - just not on the jabber.

Overstated.

> but as per IETF rules all decisions are really done based on discussions 

Of course,
Stephen.

---

From: Damon <[email-masked]>
Date: Wed, 11 Oct 2006 11:20:54 -0400

+1

 I can't attend due to firewall restrictions it seems. (*sigh*)
But I think there is plenty of positive concensus on this AND
https://rt.psg.com/Ticket/Display.html?id=1358 -DKIM Strict-

Regards,
Damon Sauer

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Oct 2006 08:49:41 -0700

> mean since we discussed this in the jabber session and I posted

It's probably worth mentioning that some people speaking in favor of
something does not rough consensus make. I put these provisional requirement
into the draft to try to distill out what was on the list to see if they 
would *then*
achieve rough consensus. If it did not achieve rough consensus, I'd then 
remove
it from the draft. From what I can tell -- and I'm not the chair here --
at least as many people are against this requirement as are for it, 
which is not
generally considered to be rough consensus in my understanding.

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Oct 2006 17:18:38 +0100

> I can't attend due to firewall restrictions it seems. (*sigh*)

That's a pity. But this was flagged as heading for closed on Sep 21,
on the list.

> But I think there is plenty of positive concensus on this 

Can you point to any messages sent to the list that support Doug's
position on 1359? I saw none at all (until today).

 > AND

Again - please point to such messages.

If no-one can show me where I've erred then I'm happy that I
haven't and these therefore remain closed issues.

Stephen.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Oct 2006 12:20:52 -0400

On Wednesday 11 October 2006 11:49, Michael Thomas wrote:

> something does not rough consensus make. I put these provisional
> requirement into the draft to try to distill out what was on the list to
> see if they would *then*

That's true, but that presumes there is a rough consensus for the base 
document that has never been established.  If opinion is split then there is 
neither consensus to add it nor consensus to take it out.  Since the point of 
departure has never been agreed, I don't think there is a basis for making a 
presumption that consensus is required to move in one direction more than the 
other.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Oct 2006 17:36:21 +0100

Scott Kitterman wrote:
> document that has never been established.  

Remember that the base document here is the ssp-reqs and not
draft-allman-ssp. I think we're much closer to a basic consensus
on the former, but not the latter.

So you're both correct in what you say above.

 > If opinion is split then there is

There are some close-calls, where in the end Barry and I may have to
make a decision. In cases where some feature could be added
later on, my bias would be to omit such features for now if opinion
seems split, but I'll take each as it comes.

Regards,
Stephen.