Subject: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.

From: Hector Santos <[email-masked]>
Date: Wed, 15 Sep 2010 06:22:39 -0400

Based on existing open source DKIM API code from a large MTA, they 
must of come across signatures that did not include the 5322.From 
signature binding requirement of RFC 4871 because it contains an 
option to not enforce 5322.From hash binding in the DKIM.H header.

In other words, if the DKIM-Signature h= header does not have the 
"from" value, then this code has an option to ignore this RFC 4871 
requirement and allow this type of DKIM-Signature.

Although the API is technically violating RFC 4871, they must of did 
this for a reason but I am not totally clear what all scenarios this 
will cover with Author Domains who sign without the 5322.From bind.

The main point is they found an implementation reason to add an 
verification option to relax the RFC 4871 MUST hash 5322.From requirement.

My Technical recommendation.

1) For 4871bis, we should consider relaxing the 5322.From
    binding requirement from a MUST to a SHOULD.  This will help
    justify its new words of "separating the signer domain from
    the author domain."  There is no separation until the 5322.From
    binding requirement is relaxed.

2) We should consider a 5617bis (ADSPbis) to codify its semantics
    regarding Author Domain only signature policies to include a:

    Always sign by *anyone* Policy.

    Currently 5617 (ADSP) defines the two policies:

     all           All mail from the domain is signed with an Author
                   Domain Signature.

     discardable   All mail from the domain is signed with an Author
                   Domain Signature........

Many people felt we were missing the "Signed by Anyone" concept which 
did not help "authorized" 3rd party signers or the list servers who 
are going to be resigning.  To compensate, many viewed ADSP=ALL to 
mean it allowed any signer, not just the Author Domain as defined by 
the spec.

In fact, this same DKIM API includes ADSP support and it also 
interprets ADSP=ALL as an anyone can sign concept as long as there is 
a valid signature. There is no option in the software to follow 
ADSP=ALL exactly how it it defined in 5871.

Since this is an API from a large MTA vendor, I would not ignore this 
implementation "data point." If the suggestion is made the software is 
"buggy" then we are back to a status quo of non-resolution of 
conflicting issues regarding the author domain, 3rd party signers 
and/or list servers.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

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

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 15 Sep 2010 17:18:36 +0100

> mean it allowed any signer, not just the Author Domain as defined by

So, that would mean that anyone is allowed to spoof my 5322.From address, 
provided that they sign the message, would it? I'm not sure I could think 
of a useful application for that feature.

Perhaps "ADSP=anyof:example.com, example.org..." would make the system more 
useful. Heck, one might even say "anyof:*", if one really wanted.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Sep 2010 13:01:27 -0400

Ian Eiloart wrote:
> So, that would mean that anyone is allowed to spoof my 5322.From 
> address, provided that they sign the message, would it? I'm not sure I 
> could think of a useful application for that feature.
> 
> Perhaps "ADSP=anyof:example.com, example.org..." would make the system 
> more useful. Heck, one might even say "anyof:*", if one really wanted.

Perhaps and this has been proposed in the 2006 DSAP I-D, Doug's has 
similar TPA (Third Party Authorization) and I recently tried to rewake 
the DSAP idea for ADSP as an extension called ASL (Allowable Signer List).

ADSP allows extension, so a DNS record like

    DKIM=all;  x-asl=mipassoc.org, gmail.com

would say, that I sign all my mail, and allow those other domains to 
also sign.

However, this can be potentially be a high overhead/management for 
large companies with many employees using different list servers.  I 
think it fits the millions more market place of small to mid size 
domains or private domains that may outsource a one or more third 
party signers or use a few professional or trade support list forums.

If you think this is something to pursue, +1 it because I am trying to 
see if its worth the effort to reintroduce it.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 15 Sep 2010 18:28:23 +0100

> large companies with many employees using different list servers.

Too true, and I don't think that this kind of delegation would be any kind 
of a solution for the ADSP=discardable/MLM problem. It might be used as a 
work around for small vanity domains, but wouldn't scale. Plus, I'm not 
sure that it would be a great workaround, as it kind of says "if you want 
to spoof my email address, here's a list of MLM servers that might accept 
my email and apply a convincing signature for you!"

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Sep 2010 13:39:20 -0400

Ian Eiloart wrote:

> Too true, and I don't think that this kind of delegation would be any 
> kind of a solution for the ADSP=discardable/MLM problem. It might be 
> used as a work around for small vanity domains, but wouldn't scale. 
> Plus, I'm not sure that it would be a great workaround, as it kind of 
> says "if you want to spoof my email address, here's a list of MLM 
> servers that might accept my email and apply a convincing signature for 
> you!"

Agree, it does expose your "friends," but wouldn't you be first party 
protected on the submission (assuming the MLM is ADSP compliant and 
why one would put it in their ASL)?

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Sep 2010 00:56:39 -0400

>option to not enforce 5322.From hash binding in the DKIM.H header.

I don't think that's a reasonable conclusion do draw from this data point. 

>will cover with Author Domains who sign without the 5322.From bind.

Protecting messages from in transit modification was one of the DKIM design goals. Excluding this user visible header from such protections is not a good idea. This is an even worse idea than "l=".

>verification option to relax the RFC 4871 MUST hash 5322.From requirement.

People implement all kinds of thing for all kinds of reasons. Don't depend very much on the mere fact of an implementation tidbit.

>    binding requirement is relaxed.

As discussed during the original DKIM development effort, this is about protecting content from modification. The base DKIM spec already doesn't treat 5322.from specially, so such a change in not needed to meet your specified goal.

>ADSP=ALL exactly how it it defined in 5871.

It sounds to me like a bug.

>conflicting issues regarding the author domain, 3rd party signers 
Since anyone can generate a DKIM signature with a signing domain they control, an unconstrained 3rd party signing policy means precisely nothing. Without some kind of constraint (1st party only or a defined set of third party signers) arbitrary senders could meet the policy requirements.

- 1.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 15 Sep 2010 23:28:57 -0700

Concur, for all your reasons.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Scott Kitterman [[email-masked]]
Sent: Wednesday, September 15, 2010 9:56 PM
To: [email-masked]
Subject: Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.

[...]

- 1.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Sep 2010 03:23:15 -0400

> As discussed during the original DKIM development effort, this 
> is about protecting content from modification. The base DKIM spec 
> already doesn't treat 5322.from specially, so such a change in not 
> needed to meet your specified goal.

Excuse me if I don't understand your reading.  5322.From is the only
header that is required hashing. Is that not a special consideration?

I think it will serve the community interest to find out why this
large MTA vendor revised there open source software three years later
presumably after extensive field operations to include a new option to
relaxed the 5322.From binding.

Thanks for your input.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 16 Sep 2010 05:19:41 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, September 16, 2010 12:57 AM
> Since anyone can generate a DKIM signature with a signing domain they
> control, an unconstrained 3rd party signing policy means precisely
> nothing. Without some kind of constraint (1st party only or a defined
set
> of third party signers) arbitrary senders could meet the policy
> requirements.
> 
> - 1.
> 
> Scott K

Make that a -2 for all the reasons Scott indicated. 

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 16 Sep 2010 08:50:50 -0400

Since there's no such thing as a "3rd party signing policy" in DKIM or 
ADSP, I don't understand why we're even discussing this.

R's,
John

> Make that a -2 for all the reasons Scott indicated.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
Please consider the environment before sending e-mail.

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Sep 2010 09:17:46 -0400

> ADSP, I don't understand why we're even discussing this.

John,

Because the lack of one has created other conflicts and 
mis-interpretations.

Cited another way:

1) dkim=all

    is being read as a 3rd party signing allowance when as you say,
    offers no 3rd party signing policy.

2) It has created design pressure to create I-D proposals
    to hack the 5322.From or add new Headers to circumvent #1

3) As you often state, in the spirit of what counts most in the
    IETF, "Running Code" and open source DKIM API (which mean
    other MTA must be using it) naturally follows #1

4) Resigners (New and Legacy) are not listening to ADSP,
    so #1 doesn't apply, thus forcing #2 and #3.

Just providing input to help codify the engineering.

Thanks

---

From: "John R. Levine" <[email-masked]>
Date: 16 Sep 2010 10:20:00 -0400

> we can discuss it for the very reason you pointed out, people want to 
> use/sell 3rd party signing, so lets discuss a policy and write it up.

But this is DKIM.  If you want to sign something, sign it.  You don't need 
anyone's permission.  If you want to generally endorse a list of signers, 
we have VBR for that.

If anyone thinks there is value in A publishing a statement that they like 
it when B signs mail which has A on the From: line, write up an I-D. 
Personally, I don't see any value, since I'll develop my opinion about B's 
signatures regardless of what A says about them, but I suppose I might be 
missing something.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 16 Sep 2010 10:31:34 -0400

> [email-masked]] On Behalf Of John R. Levine
> Sent: Thursday, September 16, 2010 10:20 AM
> To: [email-masked]
> Cc: DKIM List
> Subject: Re: [ietf-dkim] Who signs what
> 

People should be free to use/sell 3rd party signing but that is outside
the scope of DKIM/ADSP by intent. I would urge people to go back and
read the archives. There was a (hard won) consensus that a signature by
the owner/admin of a domain carries more weight than the signature of a
3rd party because the owner/admin of the domain controls the domain and
the 3rd party doesn't. (DOH!) We also discussed the practicality of
making assertions authorizing 3rd party signing and decided to kick the
can down the road until there was more practical experience with DKIM
usage generally and 3rd party signing specifically. I'm not going to go
through the archives to find the specific threads but they are there.

> anyone's permission.  If you want to generally endorse a list of
signers,

+1

> signatures regardless of what A says about them, but I suppose I might
be

Sounds like more of a marketing issue than a technical issue to me.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 16 Sep 2010 10:34:44 -0400

> here was a (hard won) consensus that a signature by the owner/admin of a 
> domain carries more weight than the signature of a 3rd party because the 
> owner/admin of the domain controls the domain and the 3rd party doesn't.

That's not my recollection, but whatever.

> Sounds like more of a marketing issue than a technical issue to me.

Indeed.  If the owner is myobscurelittledomain.com and the signature is 
from yahoo.com, I know which one I'm likely to pay more attention to.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Sep 2010 10:43:03 -0400

> signatures regardless of what A says about them, but I suppose I might be 

John, you are the good guy. The concern is the bad guy's opinion to do 
the same thing you wish to do freely.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 16 Sep 2010 10:46:49 -0400

> From: John R. Levine [mailto:[email-masked]]
> Sent: Thursday, September 16, 2010 10:35 AM
> To: MH Michael Hammer (5304)
> Cc: [email-masked]; DKIM List
> Subject: RE: [ietf-dkim] Who signs what
> 

That was the thread that resulted in us changing the name from SSP to
ADSP (I was the one who suggested ADSP). Because we tied it firmly to
the RFC5321 From field we ended up with Author Domain Signing Policy
rather than Sender Signing Policy. In between we had suggestions such as
Author Signing Policy (among others).

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Sep 2010 10:48:14 -0400

> from yahoo.com, I know which one I'm likely to pay more attention to.

Which one? and why?  I see spam, scams and phishes from both and 
mixed, from little guy signed by yahoo.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Sep 2010 08:00:28 -0700

> from yahoo.com, I know which one I'm likely to pay more attention to.

myobscurelittledomain.com, right? As Miles said in the past, Yahoo would
always have sort of middling reputation.

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Sep 2010 11:08:01 -0400

> relaxed the 5322.From binding.

Finding out why sounds reasonable.  What you propose isn't finding out why, but 
assuming it's valuable without bothering to find out.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 16 Sep 2010 08:25:54 -0700

On 9/16/2010 7:31 AM, MH Michael Hammer (5304) wrote:
> the scope of DKIM/ADSP by intent.

This is a technical group, writing technical specifications.  So we need to be 
extremely careful in being accurate in how we describe things.

By its definition, ADSP targets the author's domain (in the From: field.)  This 
means that ADSP cannot be used for other domains.

However DKIM says nothing about any other field, author or otherwise.  It is 
equally happy with 1st-, 2nd-, 3rd-, and nth- party signatures.  And /that/ 
really is by intent.  (It always was the major enhancement of DKIM over Domainkeys.)

ADSP is not DKIM. It relies on it, but it goes far beyond it.

DKIM does not require or expect ADSP.

You said DKIM/ADSP. The implication is that the constraint you cited is relevant 
to DKIM.  But it isn't.  It's relevant (and in fact essential) only to ADSP.

d/
-- 

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 16 Sep 2010 11:31:18 -0400

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Thursday, September 16, 2010 11:26 AM
> Cc: Bill Oxley; DKIM List
> This is a technical group, writing technical specifications.  So we
need
> to be
> By its definition, ADSP targets the author's domain (in the From:
field.)
> This
> However DKIM says nothing about any other field, author or otherwise.
It
> is
> really is by intent.  (It always was the major enhancement of DKIM
over
> Domainkeys.)
> You said DKIM/ADSP. The implication is that the constraint you cited
is
> relevant

You are absolutely correct Dave. My intent was to communicate the
combination of DKIM and ADSP (or ADSP layered on top of DKIM if you
will).

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 16 Sep 2010 11:31:38 -0400

> always have sort of middling reputation.

If I've heard of myobscurelittledomain.com, sure.  But in the more likely 
case that I haven't, Yahoo's middling reputation will have to do.

R's,
John

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 16 Sep 2010 11:32:01 -0400

On Thu, Sep 16, 2010 at 10:31 AM, MH Michael Hammer (5304) <[email-masked]>

>There was a (hard won) consensus that a signature by
> the 3rd party doesn't.

I don't think there is a consensus on what a 3rd party signature is.

-- 
Jeff Macdonald
Ayer, MA

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 16 Sep 2010 08:46:19 -0700

> combination of DKIM and ADSP (or ADSP layered on top of DKIM if you

Right.  And I was pretty sure that was your intent.  (In fact I singled our your 
note because I was confident that it would be possible to keep the focus on the 
terminology usage and not worry about mixing it with a misunderstanding of the 
distinction between DKIM and ADSP...)

The problem is that there is a general perception that DKIM cares about the 
"type" of the signature.  Linking DKIM directly to a discussion about the 
'party' of the signature reinforces that misunderstanding.

As many of you know, I've recently added a little audience-participation test to 
my presentations about DKIM. Almost everyone who answers the question "What does 
DKIM do" says that it is about verifying the author or the sender.  Formally, it 
does neither.

I strongly suggest that when someone is talking about ADSP, they need to say ADSP.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 16 Sep 2010 08:48:03 -0700

On 9/16/2010 8:32 AM, Jeff Macdonald wrote:
> On Thu, Sep 16, 2010 at 10:31 AM, MH Michael Hammer (5304)<[email-masked]>
>

ADSP has a definition that is, I think, pretty clear.

The problem is that that definition does not synchronize with many people's 
expectations of the term, and especially its usage in other circumstances.

We could, I suppose, write an ADSP erratum that redefines its usage. I've no 
idea whether that would be worth the effort.

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Thu, 16 Sep 2010 09:35:18 -0700

> I don't think there is a consensus on what a 3rd party signature is.

I hear it used in ADSP context to mean any signature that is valid
but which is not an author domain signature.

That contradicts the usual meaning of "3rd party", so maybe it's not
the best term, but usage is fairly consistent, which is close to
being consensus.

Michael's usage of it above doesn't match with that (as 
valid, non author domain signatures are commonly
signatures by the owner/admin of the domain).

Cheers,
  Steve

---

From: <[email-masked]>
Date: Thu, 16 Sep 2010 08:58:25 -0400

John,
we can discuss it for the very reason you pointed out, people want to use/sell 3rd party signing, so lets discuss a policy and write it up. I know my company wants one and I suspect a few others might as well.  I know that some folks fought very hard to keep it out originally but as I pointed out then, its time will come
On Sep 16, 2010, at 8:50 AM, John R. Levine wrote:

> Please consider the environment before sending e-mail.<smime.p7s><ATT00001..txt>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Sep 2010 10:17:54 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, September 16, 2010 8:08 AM

We have extensions that go beyond DKIM and ADSP in OpenDKIM.  Lots of 'em.  They generally fall into two categories (and some fall into both):

One category is local policy stuff.  These are decisions made about message handling after the DKIM evaluation is complete.  They are well outside the scope of DKIM and ADSP, but they are generally useful to administrators.  They aren't there to make any indication that a part of the protocol was broken, because in fact they have little if anything to do with the protocol.

The other is experimental code.  These are things that we thought might be useful, some of which do adjust the actual DKIM processing beyond what the RFC says, and are presented with a "We think you might want/need/like this.  Try it out if you want, and let us know if you like it."  Such feedback, when we get it, is returned to the working group as input to the process.

Neither class of extension is a statement by us that extensive field operations has yielded this as a flaw in the protocol or a required extension.  Absent a statement by this other open source project to that effect, I would just assume it's another knob people can try.

Since I'm pretty sure we're talking about Alt-N here, I'll ask them.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Sep 2010 10:24:36 -0700

> [email-masked]] On Behalf Of Jeff Macdonald
> Sent: Thursday, September 16, 2010 8:32 AM
> To: DKIM List

Oh, I disagree.  As someone (Ian?) pointed out, there's some long-established common use about what the term "third-party" means, and I don't think we need to establish rough consensus on something like that.

For a message (not even specifically email) from A to B via C, A is the first party, B is the second party, C is the third party.

The first several definitions I found via a simple Google search concurred.

Let's not waste time on this.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Sep 2010 10:31:08 -0700

> Sent: Thursday, September 16, 2010 7:20 AM
> To: Bill Oxley @ Cox
> Cc: DKIM List

I'm at the point where I'm willing to create this capability in OpenDKIM as an optional feature for people to try just because so many people think this is important.  We can run the experiment for a while and report back, though getting enough results to be meaningful may take months.  Then we'll know if there's value to the effort, or whether it yields nothing, or even if nobody really uses it once it's out there.  One way or another, we can put the debate to rest.

I'm not going to let this derail efforts toward finding some DKIM-based name evaluation (reputation), however, just so you all know where the priority is.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 16 Sep 2010 13:32:11 -0400

> [email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Thursday, September 16, 2010 1:25 PM
> To: DKIM List
> Oh, I disagree.  As someone (Ian?) pointed out, there's some long-
> established common use about what the term "third-party" means, and I
> don't think we need to establish rough consensus on something like
that.
> 
> For a message (not even specifically email) from A to B via C, A is
the
> first party, B is the second party, C is the third party.
> 

I think the only difference is the one that Steve pointed out and I know
but didn't state accurately due to lack of sleep (2 hours last night). 

Domain owners may choose to sign with a signature with a d= different
than the domain in the rfc5321 From. That would make the domain owner
signature a 3rd party signature for that particular ADSP case rather
than a 1st party signature.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Thu, 16 Sep 2010 10:38:46 -0700

> Let's not waste time on this.

If that's the case, then we need to stop using the term "third-party signatures" when discussing ADSP, as ADSP does not make any distinction that maps on to the general used meaning of "third-party".

Perhaps we should use the terms "822from domain signature" and "non-822from domain signature" to differentiate between the only two cases of valid signatures that ADSP is concerned with.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Sep 2010 10:52:02 -0700

> [email-masked]] On Behalf Of Steve Atkins
> Sent: Thursday, September 16, 2010 10:39 AM
> To: DKIM List
> If that's the case, then we need to stop using the term "third-party
> signatures" when discussing ADSP, as ADSP does not make any distinction
> that maps on to the general used meaning of "third-party".

A recipient doesn't sign incoming mail (it could but we don't really care about that case), and we're not talking about author signatures (and I think we agree on what those are).  What's left?

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Sep 2010 11:03:14 -0700

On 9/16/10 10:24 AM, Murray S. Kucherawy wrote:
> > On Thursday, September 16, 2010 8:32 AM, Jeff Macdonald wrote: I
> > don't think there is a consensus on what a 3rd party signature is.
>
>  Oh, I disagree. As someone (Ian?) pointed out, there's some
>  long-established common use about what the term "third-party" means,
>  and I don't think we need to establish rough consensus on something
>  like that.
>
>  the first party, B is the second party, C is the third party.
>

This seems to be the correct answer, but there are a few issues that 
will cause some difficulties using this simplified terminology when 
describing parties and their related reputations/accountability/authority.

With ADSP, any signing domain that is NOT exactly the same as the 
email-address domain would be a third-party from the perspective of 
ADSP.  It could be both domains a.tld and a.a.tld are administered under 
the same authority.  So when a.tld sends a message signed by a.a.tld to 
b.a.tld, then-

a.tld     -> author-domain
a.a.tld  -> signing-domain (first party but not a valid Author Domain 
Signature)
b.a.tld  -> second party recipient

Hector had a good idea that could expand ADSP compliance when using 
different signing domains to identify different mail streams.

His asl tag could be used to enable the treatment of subdomain 
signatures as being equal to that of an author domain, but as a 
different mail stream.

It seems most would have difficulty understanding that a.a.tld will not 
provide a valid Author Domain signature able to satisfy ADSP compliance 
for a.tld.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Thu, 16 Sep 2010 11:08:16 -0700

> A recipient doesn't sign incoming mail (it could but we don't really care about that case), and we're not talking about author signatures (and I think we agree on what those are).  What's left?

If I were to sign this email with d=pedantic.wordtothewise.com would that be a third-party signature or a first party signature?

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Sep 2010 11:12:07 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Thursday, September 16, 2010 11:03 AM

I don't think any personal or business relative of mine should automatically be considered equivalent or even similar to me in terms of evaluation of the quality or value of their messaging output.  I don't see why domain names should be any different.

If I want them to share my reputation, I'll sign their mail.

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Sep 2010 14:11:57 -0400

Murray S. Kucherawy wrote:

> Neither class of extension is a statement by us that extensive 
> field operations has yielded this as a flaw in the protocol or 
> a required extension.  Absent a statement by this other open 
> source project to that effect, I would just assume it's another 
> knob people can try.

True, but...

A MUST does not mean optional.  Most good implementators will always 
begin by following the MUST specs to the letter and most will never 
implement a MUST as a SHOULD or MAY (thus make it a local policy 
option) unless absolutely necessary, and if its necessary to explore 
it is done in a low key manner.

Since we all agree the 5322.FROM is extremely important and MUST be 
bound to the signature, any reason to make this an option after 3-4 
years of implementation is a very significant DKIM Project Research 
data point especially when done by a large commercial MTA.

PS: The request has already been made to get the specifics on the 
implementation change.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Sep 2010 11:18:05 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Thursday, September 16, 2010 11:08 AM
> To: DKIM List
> If I were to sign this email with d=pedantic.wordtothewise.com would
> that be a third-party signature or a first party signature?

It's from you (A) to me (B) signed by your subdomain (C).

---

From: Steve Atkins <[email-masked]>
Date: Thu, 16 Sep 2010 11:34:58 -0700

>> The first several definitions I found via a simple Google search concurred.

I think you're saying that when I register a domain[1] and use
that domain in both the From: address and the DKIM signature
then that's a third-party signature if I use a subdomain in the
DKIM signature.

In the ADSP world the difference between "non-author-domain"
 vs "author-domain" is an important distinction, but you're
using "third-party" vs "first-party" to refer to that.

That's contrary to normal use of the term third-party, as there
is no third party involved in this example - there's me and my
domain, and there's the recipient.

And this isn't a theoretical case. Signing with a subdomain of
the domain in the From address is DKIM best practice in a
large fraction of cases. 

If we describe that as a third-party signature we risk confusing
it with the case of a true third-party signature from a certification
authority or some such. "Third-party that's the author"
vs "Third-party that's not the author".

>> Let's not waste time on this.

The way to avoid wasting time is to use the terminology
that's in the drafts we already have in place, rather than
making up new terminology that's misleading.

Cheers,
  Steve

[1] using the commonly used definition of domain as "the
thing I spend $20 a year to use that's a word with '.com'
or similar on the end".
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Sep 2010 14:36:37 -0400

> I don't think there is a consensus on what a 3rd party signature is.

What's wrong with Michael Thomas work, RFC 5016 where it specifically 
spells out the "Definitions and Requirements Language" for 1st and 3rd 
party as it is to be defined and used for DKIM and POLICY?

IMV, I believe we need to separate the ideas of outsourcing, clearing 
houses, service bureaus, etc, as they can be 3rd party, but also 
passive meaning the message is visible as a 1st party, even though 
they might been signed by someone else.  This would be more of 
business model function than a technical protocol function.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Sep 2010 11:52:39 -0700

> Sent: Thursday, September 16, 2010 11:35 AM
> To: DKIM List

Yes.

> using "third-party" vs "first-party" to refer to that.

I don't think there's a difference.  I think having two terms to describe the same thing in different ways only serves to confuse the issue.

> domain, and there's the recipient.

How is a piece of software supposed to detect and apply that?  As soon as you make that allowance, then one could argue we should also have a heuristic to say "yahoo.co.uk" and "yahoo.com" are related and should share a reputation.

I really don't think we want to go down this path.

> the domain in the From address is DKIM best practice in a

It's still a third-party signature, with its own reputation.  That is, as I understand it, the whole point of signing with a subdomain.

> vs "Third-party that's not the author".

There's only confusion when we pile adjectives onto the end.  It's third-party, or it's not.  Or since some people like ADSP's terms:  It's an author signature, or it's not.

Put another way: If we can't converge on terminology in this area to describe all the variations, maybe there's a reason for that.

> making up new terminology that's misleading.

Actually I think the time is wasted in trying to identify every possible variant of a very simple term that already has a well-defined history, and document them all and treat them all differently.

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 16 Sep 2010 16:25:53 -0400

On Thu, Sep 16, 2010 at 2:52 PM, Murray S. Kucherawy <[email-masked]> wrote:
> How is a piece of software supposed to detect and apply that?  As soon as you make that > allowance, then one could argue we should also have a heuristic to say "yahoo.co.uk" and > "yahoo.com" are related and should share a reputation.

I don't think Steve is saying that you do. I believe the point is that
people equate foo.com and a.foo.com as the same party. In many cases
this will be true. Before I posted my message, I had someone say how
did a.foo.com suddenly become 3rd party of foo.com? That wasn't that
person's understanding of it nor of other folks.

> There's only confusion when we pile adjectives onto the end.  It's third-party, or it's not.  Or > since some people like ADSP's terms:  It's an author signature, or it's not.

I am much happier with ADSP's terms. I'm still fairly certain folks
come to different conclusions regarding the term 3rd party.

-- 
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Sep 2010 14:24:38 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff Macdonald
> Sent: Thursday, September 16, 2010 1:26 PM
> To: DKIM List
> > How is a piece of software supposed to detect and apply that?  As
> soon as you make that > allowance, then one could argue we should also
> have a heuristic to say "yahoo.co.uk" and > "yahoo.com" are related and
> should share a reputation.
> 

We need to avoid conflating what people do when they see two strings and what computers can/will do when presented with the same data.

We can't code intuition.  Thinking that we can needlessly complicates our work.

If we want to use new definitions that include specific heuristics about comparing domains and subdomains, then let's do that.

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 16 Sep 2010 22:22:08 -0400

> If we want to use new definitions that include specific heuristics about comparing domains and subdomains, then let's do that.

No, that would be a mistake. Let's just not use the word "third-party".

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 17 Sep 2010 13:37:48 -0700

> we can discuss it for the very reason you pointed out, people want to use/sell 3rd party signing, so lets discuss a policy and write it up. I know my company wants one and I suspect a few others mi…

One of the original intentions behind publishing ADSP with only author domains was that we'd try that for a while, and then hopefully understand the ramifications well enough to devise a protocol that can handle non-author (non-From:) domains.

Since that hasn't happened yet, is there another approach we could try for gaining this understanding?

---

From: Hector Santos <[email-masked]>
Date: Fri, 17 Sep 2010 16:48:01 -0400

Jeff Macdonald wrote:
>> If we want to use new definitions that include specific heuristics 
>> about comparing domains and subdomains, then let's do that.

> No, that would be a mistake. Let's just not use the word "third-party".

In hindsight, we should have simply:

       "Signer Policies|Practices"

which would be a base/raw framework for a single DNS lookup allowing 
extensions to to be written for it. Piggy packing off the same DNS 
lookup,  we won't multiple DNS lookups for new POLICY ideas.

In an away that is what happening to ADSP.  AFAIK, there are two 
extensions I-D written already for ADSP for it and a third one coming. 
  Two of them will be related to third party authorized signature 
practices.

I guess the term ADSP is fine as long it allows for Author Domains to 
describe a signing practice that is not exclusive (1st party only).