Subject: [ietf-dkim] Responsibility vs. Validity

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Nov 2007 10:17:01 -0800

Folks,

This note is about an old topic that seems to remain unresolved. I'm posting 
it to see where the working group is on the matter:

Mechanisms like OpenPGP and S/MIME essentially validate the authenticity of 
content.  DKIM does not.  For example, a DKIM signature does not contain the 
semantics that claim that the From field is correct, nevermind that it does 
not distinguish between "brands" such as are often implied by the display 
string in the From field, versus the email address in it.

Rather, DKIM's task is to allow an organization to say this it has some 
responsibility for the message; that is, come to them if there is a problem.

In looking at the range of features that have been added to SSP, I keep 
thinking that this distinction is not clear.  It seems to me that there is 
tendency to want to build "the content is valid" mechanisms into SSP.

Thoughts?

d/
-- 

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

---

From: Steve Atkins <[email-masked]>
Date: Tue, 27 Nov 2007 10:47:20 -0800

On Nov 27, 2007, at 10:17 AM, Dave Crocker wrote:

> Folks,
>
> This note is about an old topic that seems to remain unresolved.  
> I'm posting it to see where the working group is on the matter:
>
> Mechanisms like OpenPGP and S/MIME essentially validate the  
> authenticity of content.  DKIM does not.  For example, a DKIM  
> signature does not contain the semantics that claim that the From  
> field is correct, nevermind that it does not distinguish between  
> "brands" such as are often implied by the display string in the  
> From field, versus the email address in it.

DKIM is a mix of the two (as are pgp and s/mime).

It's setup to not only say "this message came from THIS recipient",  
but also "THIS message came from this recipient".

>
> Rather, DKIM's task is to allow an organization to say this it has  
> some responsibility for the message; that is, come to them if there  
> is a problem.

That, to me, is it's *intended* use, sure, but there's no denying  
that a validly signed DKIM message asserts that the content has not  
been tampered with since it was signed (within some fairly well- 
defined limitations).

PGP, S/MIME and DKIM all make the same basic statement: "*this*  
sender sent you *this* message and it's not been tampered with since  
they signed it". Intended usage may be different, but the basic  
function is the same.

>
> In looking at the range of features that have been added to SSP, I  
> keep thinking that this distinction is not clear.  It seems to me  
> that there is tendency to want to build "the content is valid"  
> mechanisms into SSP.
>

That's an entirely different question to the one you started with.  
PGP and S/MIME make no assertions about unsigned messages, and nor  
does DKIM.

SSP is primarily about making negative assertions about mail with a  
particular from address that is not dkim signed. Given it makes  
negative assertions I don't see how it can really be used as part of  
a "the content is valid" mechanism other than by discriminating  
between "I assert the content is invalid" and "I make no assertion  
about the content".

Cheers,
   teve

---

From: Steve Atkins <[email-masked]>
Date: Tue, 27 Nov 2007 10:56:33 -0800

> but also "THIS message came from this recipient".

Sender, of course.

"It's setup to not only say "this message came from THIS sender", but  
also "THIS message came from this sender""

Cheers,
   Steve

---

From: "J D Falk" <[email-masked]>
Date: Tue, 27 Nov 2007 14:00:04 -0500

>  That, to me, is it's *intended* use, sure, but there's no denying
that
> a validly signed DKIM message asserts that the content has not been
> tampered with since it was signed (within some fairly well- defined
> limitations).
> 
> PGP, S/MIME and DKIM all make the same basic statement: "*this* sender
> sent you *this* message and it's not been tampered with since they
> signed it". Intended usage may be different, but the basic function is
> the same.

To continue agreeing, I'd add that it says "this message has not been
modified since this sender took responsibility for it" -- which gets
back (as these conversations always do) to the question of whether or
not you trust the sender (for various definitions of "trust"), which
isn't a question DKIM can answer for you.

--
J.D. Falk
Receiver Products
Return Path

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Nov 2007 11:09:17 -0800

Steve Atkins wrote:
>> "brands" such as are often implied by the display string in the From 
>> field, versus the email address in it.
> 

I believe that a basic DKIM signature is not.  I believe the semantics of a 
signature are stated rather plainly in the -base specification.

Opening line of the -base Introduction:

   "DomainKeys Identified Mail (DKIM) defines a mechanism... permitting a 
signing domain to claim responsibility for the introduction of a message into 
the mail stream."

(One might quibble about the "introduction" reference, since signing can be 
done by any handler along the way, but that's a subtlety not at issue for this 
discussion.)

> It's setup to not only say "this message came from THIS recipient", but 
> also "THIS message came from this recipient".

Depends on what one means by "from" since a DKIM signature is not required to 
relate to the rfc2822.From string.

Also do not at all understand the second half of your sentence.  Came from 
this *recipient*???

>> some responsibility for the message; that is, come to them if there is 
>> a problem.
> 
> That, to me, is it's *intended* use, sure, but there's no denying that a 
> validly signed DKIM message asserts that the content has not been 
> tampered with since it was signed (within some fairly well-defined 
> limitations).

Yes, it carries semantics about in-transit modification.  But it says nothing 
about correctness prior to signing.

> signed it". Intended usage may be different, but the basic function is 

Mumble.  My impression is that the semantics of these other signatures is 
taken to be considerable stronger.

>> keep thinking that this distinction is not clear.  It seems to me that 
>> there is tendency to want to build "the content is valid" mechanisms 
>> into SSP.
> 
> 
> That's an entirely different question to the one you started with. PGP 
> and S/MIME make no assertions about unsigned messages, and nor does DKIM.
> 
> particular from address that is not dkim signed. 

That is only one of SSP's features.

 > Given it makes negative
> assertions I don't see how it can really be used as part of a "the 
> content is valid" mechanism other than by discriminating between "I 
> assert the content is invalid" and "I make no assertion about the content".

Discussions about SSP seem to conflate From field domain name correlations 
with "brand" representation authenticity in the message.  That type of issue 
is what prompted my sending my note.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Tue, 27 Nov 2007 14:24:56 -0500

Dave Crocker wrote:
> Folks,
> 
> This note is about an old topic that seems to remain unresolved. I'm 
> posting it to see where the working group is on the matter:
> 

I always had trouble with this "responsibility declaration."  Something 
was never right about it especially with the "ignore if failure" 
semantic, with no really strong agreement on Policy.  I can't see how 
one would want to take responsibility when there is hardly any 
protection for abuse.  I don't want people "coming to us" when they see 
abuse that had nothing to do with us.  In fact, I will go on the record 
to suggest this can open new legal issues, such as malpractice claims.
I need to be very careful about what I am going to tell people about 
what DKIM offers and the last thing I want to tell them is we are 
responsible for issues related to it, or that they will responsible for 
all mail signed with DKIM.

> thinking that this distinction is not clear.  It seems to me that there 
> is tendency to want to build "the content is valid" mechanisms into SSP.

Well, I think it is part of it, but not as important as policy or domain 
expectations for their DKIM usage.

I say that because the integrity part of the design will always be a 
risk in damage.  But with Policy, it is more about protecting the domain 
itself from unauthorize usage.

In any case, there is "No Tendency." it is the current SSP draft 
specification. If the integrity fails or signature fails, the design is 
such that it should then check SSP.  Against my technical 
recommendations, it is the only time SSP is checked.

SSP should be designed so it can be checked any time. Especially for a 
mailings list subscription service where the DKIM ready list server can 
validate a subscribing domain for usage on its list server as a 3rd 
party or middle ware or outsourcing distribution point.

-- 
Sincerely

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

---

From: [email-masked]
Date: Tue, 27 Nov 2007 11:17:35 -0800 (PST)

> Thoughts?

I haven't been tracking the list all that closely so I'm not entirely sure I
know what proposed features you're talking about. The current SSP draft doesn't
seem to have any features I would classify as having these sorts of semantics
(which I agree would be bad).

The one recent SSP extension proposal I've seen is the reporting address idea,
which seems largely orthogonal to this.

Unintentional implication that such a service is being offered is another
matter. This is an easy trap to fall into. Consider the use of the word
"signed", which is rampant in these specifications. Yes, we're using digital
signatures as part of this, so the verb is technically correct, but a lot of
people read "signed" as "validating the content".

So aside from stating repeatedly that this is not a content validation service
and signatures are merely a means to an end, I don't have anything useful to
suggest here.

				Ned

---

From: Steve Atkins <[email-masked]>
Date: Tue, 27 Nov 2007 11:38:15 -0800

On Nov 27, 2007, at 11:09 AM, Dave Crocker wrote:

> I believe that a basic DKIM signature is not.  I believe the  
> semantics of a signature are stated rather plainly in the -base  
> specification.
>
>   "DomainKeys Identified Mail (DKIM) defines a mechanism...  
> permitting a signing domain to claim responsibility for the  
> introduction of a message into the mail stream."

A message is identified and defined by it's content. You cannot claim  
responsibility for a message with also claiming responsibility for  
the content of the message. If the content were to change, it  
wouldn't be the same message.

>> It's setup to not only say "this message came from THIS  
>> recipient", but also "THIS message came from this recipient".
>
> Depends on what one means by "from" since a DKIM signature is not  
> required to relate to the rfc2822.From string.
>
> Also do not at all understand the second half of your sentence.   
> Came from this *recipient*???

Sender. Thinko.

"Signer" is better still, of course. It's no different to, say, PGP,  
where the signer need not be the same as the sender (but usually will  
be).

>>> Rather, DKIM's task is to allow an organization to say this it  
>>> has some responsibility for the message; that is, come to them if  
>>> there is a problem.
>> that a validly signed DKIM message asserts that the content has  
>> not been tampered with since it was signed (within some fairly  
>> well-defined limitations).
>
> Yes, it carries semantics about in-transit modification.  But it  
> says nothing about correctness prior to signing.

No more nor less than PGP or S/MIME. All three simply demonstrate  
that the content you see is the content that the sender signed.

         To: dcrocker
         From: [email-masked]

         All Cretans are liars.

If that is validly dkim signed by crete.gr, that doesn't make the  
content valid. Nor would it were it PGP signed by [email-masked].

(If it were dkim signed by blighty.com then crete.gr *could* assert,  
via SSP, that the From field is not correct, and perhaps that the  
entire message should be treated with some little-S suspicion.)

>> sender sent you *this* message and it's not been tampered with  
>> since they signed it". Intended usage may be different, but the  
>> basic function is the same.
>
> Mumble.  My impression is that the semantics of these other  
> signatures is taken to be considerable stronger.

Less fragile operationally, certainly, but no stronger, I don't think.

>>> SSP is primarily about making negative assertions about mail with  
>>> a particular from address that is not dkim signed.
>

OK, it also allows you to make negative assertions about validly dkim  
signed messages where the domain name of the From field and the  
signer differ. It's still only capable of making negative assertions  
about validity ("the content is not valid"), though.

>> content is valid" mechanism other than by discriminating between  
>> "I assert the content is invalid" and "I make no assertion about  
>> the content".
>
> Discussions about SSP seem to conflate From field domain name  
> correlations with "brand" representation authenticity in the  
> message.  That type of issue is what prompted my sending my note.

SSPs goal is the same as SPFs original goal - to protect the sanctity  
of the user-visible From address - but I've not really noticed that  
being conflated with "brand", "friendy from" or any of the other user  
visible parts of the message much. Do you have an example you're  
thinking of?

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Nov 2007 11:39:39 -0800

> that there is tendency to want to build "the content is valid"  

The DKIM base provides weakly defined i= semantics.  SSP could  
strengthen these assertions.

Nevertheless, efforts at assurances regarding even localpart@domain  
validation or authentication is dangerous.  Visible content and  
internationalized versions of an email-address should not be assumed  
properly recognized by recipients.

The TPA-SSP draft handles an identify validation assertion decision  
and allows it to be either dropped or strengthened.

The DKIM signature i= semantics can restrict use of the key.  Some  
will view this semantic as authenticating the associated localpart.   
Of course the key g= "user+*" or "*-offer" wildcarding makes it _very_  
difficult to then communicate which components of the localpart (if  
any) are assert as being authenticated.

There are many gray areas that could be strengthened by an SSP  
assertion.  The TPA draft attempts to illustrate how this might be  
done.  The "-i" suffix on a scope declaration was an attempt to  
replicate the i= DKIM base semantics for third-party domains.

The exchange of keys or the delegation of domains is either not safe  
or does not scale.

How would an organization authorize a mail-list?  Would the mail-list  
need to add a secondary signature for every From domain in order to be  
authorized?  The TPA-SSP draft allows the From domain to autonomously  
authorize a mailing-list signature as being valid.  This draft even  
allows this third-party signature to be asserted as having  
authenticated the localpart@domain.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Nov 2007 12:00:56 -0800

Steve Atkins wrote:
> responsibility for a message with also claiming responsibility for the 
> content of the message. If the content were to change, it wouldn't be 
> the same message.

The word "responsible" can be quite vague, and this was intentional.

When Yahoo or AOL or Google or... sign an outgoing message, they are clearly 
not saying that the content is truthful.  They are, perhaps, saying that the 
message came from a valid account on their service.  Or they might be saying 
something even weaker, such as "this did come through my MTA".

The danger is in thinking that a signature (or its absence) has more 
substantial meaning, absent extensive knowledge about the signer or whoever is 
vetting them.

> content valid. Nor would it were it PGP signed by [email-masked].

But I thought it was supposed to mean that it was authored by epimenides. 
That is, that the From address is really the author of this content.

DKIM doesn't make that strong a statement.

> (If it were dkim signed by blighty.com then crete.gr *could* assert, via 
> SSP, that the From field is not correct, and perhaps that the entire 
> message should be treated with some little-S suspicion.)

(SSP's use of the word 'suspicion' is a different line of problem to consider. 
It is SSP's way of trying to give direction about the behavior of receive-side 
filters.)

> signed messages where the domain name of the From field and the signer 
> differ. It's still only capable of making negative assertions about 
> validity ("the content is not valid"), though.

Which means that it is making statements about validity.

But a DKIM signature does not.

>> correlations with "brand" representation authenticity in the message.  
>> That type of issue is what prompted my sending my note.
> 
> SSPs goal is the same as SPFs original goal - to protect the sanctity of 
> the user-visible From address - but I've not really noticed that being 
> conflated with "brand", "friendy from" or any of the other user visible 
> parts of the message much. Do you have an example you're thinking of?

Hallway conversations about expectations for SSP.

In general, the model of a potential signer directing a potential receive how 
to handle a message with the potential signer's domain name in the From field 
is rather directly targeting brand protection.

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Tue, 27 Nov 2007 12:14:58 -0800

>some responsibility for the message; that is, come to them if there 

In the abstract of draft-ietf-dkim-overview-07

   "DomainKeys Identified Mail (DKIM) allows an organization to take
    responsibility for a message, in a way that can be validated by a
    recipient."

I suggest having:

   "DomainKeys Identified Mail (DKIM) allows an organization to take
    responsibility for transmitting a message, in a way that can be 
validated by a
    recipient."

as the organization, an ISP for example, is not responsible for the 
"content" of the message.  The signer is merely offering a means for 
the original or intermediate transmission to be validated.

The above comment applies to draft-ietf-dkim-deployment-00 as well.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Nov 2007 12:21:32 -0800

On Nov 27, 2007, at 12:00 PM, Dave Crocker wrote:

>> OK, it also allows you to make negative assertions about validly  
>> dkim signed messages where the domain name of the From field and  
>> the signer differ. It's still only capable of making negative  
>> assertions about validity ("the content is not valid"), though.
>

Not exactly.

-------
3.5 The DKIM-Signature Header Field
...
[Regarding i= tag]

INFORMATIVE NOTE: The local-part of the "i=" tag is optional because  
in some cases a signer may not be able to establish a verified  
individual identity. In such cases, the signer may wish to assert that  
although it is willing to go as far as signing for the domain, it is  
unable or unwilling to commit to an individual user name within their  
domain. It can do so by including the domain part but not the local- 
part of the identity.

INFORMATIVE DISCUSSION: This document does not require the value of  
the "i=" tag to match the identity in any message header fields. This  
is considered to be a verifier policy issue. Constraints between the  
value of the "i=" tag and other identities in other header fields seek  
to apply basic authentication into the semantics of trust associated  
with a role such as content author. Trust is a broad and complex topic  
and trust mechanisms are subject to highly creative attacks. The real- 
world efficacy of any but the most basic bindings between the "i="  
value and other identities is not well established, nor is its  
vulnerability to subversion by an attacker. Hence reliance on the use  
of these options should be strictly limited. In particular, it is not  
at all clear to what extent a typical end-user recipient can rely on  
any assurances that might be made by successful use of the "i=" options.
------

While definitely not normative, these issues will become defined by  
how these semantics are either used or more likely misused.

SSP could and should clarify what should be construed when a key is  
restricted to a specific localpart.  Perhaps the localpart is not  
authenticated, but is instead used by a class of users.  The TPA-SSP  
also allows assertions to be more stringent for third-party signatures  
than that found on first-party signatures.

By using the TPA-SSP extension, a sub-domain signature could be seen  
as valid for a the From domain AND be seen as having authenticated the  
use of the email address, whereas a signature at the domain might  
assert that no authentication is being made.  This mode of operation  
would permit different handling without involving any more overhead  
than that used for CNAMEs.

http://www.ietf.org/internet-drafts/draft-otis-dkim-tpa-ssp-02.txt

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Nov 2007 12:24:16 -0800

> The above comment applies to draft-ietf-dkim-deployment-00 as well.

The scope parameter found in TPA-SSP allows this assertion to be made  
while also allowing stronger assertion to be made by a sub-domain  
signature, for example.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 27 Nov 2007 14:26:02 -0600

> It is SSP's way of trying to give direction about the behavior
 > of receive-side filters.)

It is SSP's way of offering input for use with the receive-side's 
decision making tree.  Receivers can decide whether and how much import 
to place on such offered input (if any at all).  We must resist the 
tendency to think that doing so is unprecedented (it's not) or somehow 
out-of-bounds (it isn't).

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 27 Nov 2007 14:40:25 -0600

> We must resist the tendency to think that doing so is
 > unprecedented (it's not) or somehow out-of-bounds
 > (it isn't).

Sorry, I want to be clear.   By "doing so" I mean the act of offering 
SSP input for receivers to use (or not) as they see fit.  Such and act 
would be neither taboo nor unprecedented.

Arvel

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Nov 2007 13:03:30 -0800

On Nov 27, 2007, at 12:26 PM, Arvel Hathcock wrote:

> decision making tree.  Receivers can decide whether and how much  
> import to place on such offered input (if any at all).  We must  
> resist the tendency to think that doing so is unprecedented (it's  
> not) or somehow out-of-bounds (it isn't).

Agreed.

Message filtering is likely how DKIM will be initially used.  Abuse of  
DKIM may restrict validation of signatures to those domains considered  
trustworthy.  If so, any DKIM related annotations may convey more than  
it should to a recipient.  Allowing SSP to assert the scope of  
identity authentication might help mitigate mistakes made when the  
localpart of the email-address is otherwise annotated as  
"authenticated" simply because it was included within the i=  
parameter, although not actually authenticated at the author  
granularity, but rather at the group.

MUAs may seek to annotate those elements of a message asserted valid  
by a DKIM signature.  These MUAs will likely delve into what i=  
semantics convey with respect to the From header.  The From header is  
being protected by SSP assertions from being spoofed after all.

DKIM does not clarify who added the signature, the MUA or the MSA.   
Finding the localpart within the DKIM signature i= parameter means  
what?  When the recipient wants better clarification, should the DKIM  
WG say DKIM NEVER assures identify validation?  Have expectations  
changed and authentication of the From header is considered out-of- 
scope?  The base draft left this issue cloudy.  It seems SSP should  
shed light on this rather basic DKIM semantic.

Can the DKIM signature make a specific assurance that the related From  
email-address user has been authenticated?  If so, this necessitates  
some type of assertion within the key, or SSP record.  As illustrated  
by the TPA-SSP draft, SSP can be very flexible and much easier to  
manage.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 27 Nov 2007 13:04:16 -0800

> there is tendency to want to build "the content is valid" mechanisms

What is relevant to SSP is whether the signer is asserting that the
From: header field is authentic.  Or more specifically, whether the
signer is making that assertion in the specific case when the address in
the From: header field is the same as the signing address.  SSP has no
other dependency on whether the signer is asserting validity or is
"merely" taking responsibility.

Part of me wants to say this it's vaguely silly for a signer to take
responsibility for a message that purports to come from themselves, but
which they didn't send.  But I suppose RFC 4871 doesn't explicitly call
this out.

If there is consensus that this indeed isn't clear, we could easily add
verbiage to SSP stating that domains publishing SSP records other than
"unknown" MUST additionally ensure that they only sign messages
purporting to come from themselves when the address in the From: header
field is valid.  That way, we're putting the additional burden on those
who publish SSP records but are not trying to modify the meaning of RFC
4871 at all.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Nov 2007 15:06:42 -0800

On Nov 27, 2007, at 1:04 PM, Jim Fenton wrote:

> signer is making that assertion in the specific case when the  
> address in the From: header field is the same as the signing  
> address.  SSP has no other dependency on whether the signer is  
> asserting validity or is "merely" taking responsibility.

The question is who taking responsibility and for what?

Does the signing domain indicated From email-address use is  
restricted?  If so, this could then shift content responsibility onto  
the From email-address identity.  If not, the signing domain is only  
responsible for permitting some unknown users access.  Clearly,  
granting access says very little about content.  Just granting access  
without email-address restrictions requires reputations to be based  
upon a collective behaviour of users to which they grant access.

> responsibility for a message that purports to come from themselves,  
> but which they didn't send.  But I suppose RFC 4871 doesn't  
> explicitly call this out.

You are being rather vague by using the terms "who" and "send".  A  
signing domain does not author message content.  A signing domain  
might restrict From email-address use to just authenticated owners,  
but it may not.

> If there is consensus that this indeed isn't clear, we could easily  
> add verbiage to SSP stating that domains publishing SSP records  
> other than "unknown" MUST additionally ensure that they only sign  
> messages purporting to come from themselves when the address in the  
> From: header field is valid.

In other words, use of From email-addresses has been restricted to  
authenticated owners.  What happens when they wish to send a message  
where a user is not authenticated, but where use of some critical  
email-addresses are restricted.  There are currently no existing  
semantics to permit a mixed assertion, however actual use is likely to  
confront such a mixture.  And this must include assertions about third- 
party domains (which includes sub-domains).

This more complex situation can be handled using TPA-SSP.   Scope at  
the From domain can indicated whether email-address use is restricted  
or not.  Within a third-party domain, which could be just a sub- 
domain, an assertion for this domain's <tpa-label>._ssp record can  
assert scope=F-i,S-i where both the Sender header's and the From  
headers email-addresses are asserted as being restricted and that this  
specific third-party signature is valid.  The overhead is that of a  
CNAME. : )

The TPA-SSP extension can handle almost any desired breakdown of valid/ 
invalid third-party signatures and valid/invalid email-address  
assertions efficiently regardless of the signing domain.

Valid Third-Party Sig, Restricted Email-address
	Yes			Yes
	Yes			No
	No			Yes
	No			No
         Yes			Yes
	Yes			No
	No			Yes
	No			No

>  That way, we're putting the additional burden on those who publish  
> SSP records but are not trying to modify the meaning of RFC 4871 at  
> all.

Agreed.  TPA-SSP does not modify the base draft.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Nov 2007 01:46:03 -0500

SM wrote:
>    validated by a recipient."
> 
> "content" of the message.  The signer is merely offering a means for the 
> original or intermediate transmission to be validated.

+1.  Thank you SM.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Nov 2007 01:47:49 -0500

Douglas Otis wrote:
>> import to place on such offered input (if any at all).  We must resist 
>> the tendency to think that doing so is unprecedented (it's not) or 
>> somehow out-of-bounds (it isn't).
> 
> Agreed.
> 
> Message filtering is likely how DKIM will be initially used.  

It is what the layman is going to understand.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Nov 2007 01:57:49 -0500

> out-of-bounds (it isn't).

+1 Very True.

My only comment about this is that I was hoping there would be atleast a 
"sub-set" of a decision tree that is common to DKIM/SSP receivers as 
defined or implied by the DKIM/SSP specifications.   The goal is to help 
yield some form of enhanced assurance or purpose for all this. There has 
to be a firm answer for "Why" this is being offered to customers.  Why 
should they turn it on?

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 28 Nov 2007 13:22:01 +0100

>     validated by a recipient."
[...]
> The above comment applies to draft-ietf-dkim-deployment-00 as well.

+1  It can take years to get rid of unjustified expectations after 
    the fact, DKIM shouldn't (try to) repeat this ugly SPF mistake.

 Frank

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Nov 2007 04:33:49 -0800

> field, versus the email address in it.

    I don't know what "correct" means in this context.
> there is tendency to want to build "the content is valid" mechanisms 
I think you've got it essentially backward. SSP doesn't say anything about
signed content per se. It's completely focused on *unsigned* content. Also:
it's hard evaluate this "tendency" without some specific examples from the
draft.

       Mike

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 28 Nov 2007 13:36:32 +0100

Douglas Otis wrote:

> The scope parameter found in TPA-SSP allows this assertion
> to be made while also allowing stronger assertion to be
> made by a sub-domain signature, for example.

That's fine for your draft, but "overview" and friends are
about what Hector called the "batteries not included" DKIM,
pure DKIM without SSP.

Similar example:  Claiming that SPF allows to indicate that
a domain is never used as RHS in sender addresses would go
too far, "v=spf1 -all" is about HELO identities and the RHS
of envelope sender addresses, the domain could be still used
as RHS of a say "purported responsible address" (PRA) under
some conditions explained in 2821bis/2822upd/4406.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 28 Nov 2007 13:51:11 +0100

Jim Fenton wrote:

> we could easily add verbiage to SSP stating that domains publishing
> SSP records other than "unknown" MUST additionally ensure that they
> only sign messages purporting to come from themselves when the 
> address in the From: header field is valid.  That way, we're putting
> the additional burden on those who publish SSP records but are not
> trying to modify the meaning of RFC 4871 at all.

Good idea, a connection to 4409, 4954, and 5068.

 Frank

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Nov 2007 04:50:20 -0800

[email-masked] wrote:
>> posting
>> authenticity of

This begs the question of misconstrued by _whom_? Are we talking about
the average Joe, or spam filter writers, or what? I don't think that the 
average
Joe is especially relevant here, so it must be some other group. And if this
is indeed the case what bad things might this misunderstanding lead this
group of people to do? This is all way to vague, IMO.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Nov 2007 04:59:38 -0800

> Good idea, a connection to 4409, 4954, and 5068.
So the implication here is that that sort of domain could never run a 
mailing
list that resigns messages? That doesn't seem right to me.

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Nov 2007 13:03:27 +0000

Jim Fenton wrote:

> 4871

I'd wonder how "purporting" and "valid" above would be
strictly defined.

And for any such pair of definitions, I'd then wonder how
I'd check the "MUST" by looking at someone's code.

Do we really want to go there in SSP? (Maybe guidance in
the overview would be better if we want to say anything
about this.)

S.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 28 Nov 2007 08:17:19 -0500

> list that resigns messages? That doesn't seem right to me.
I don't think so as messages with a different From domain use a different SSP 
lookup.

Scott K

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 28 Nov 2007 13:35:06 -0000

On Tue, 27 Nov 2007 20:21:32 -0000, Douglas Otis <[email-masked]>  
wrote:

> INFORMATIVE NOTE: The local-part of the "i=" tag is optional because in  
> some cases a signer may not be able to establish a verified individual  
> identity. In such cases, the signer may wish to assert that although it  
> is willing to go as far as signing for the domain, it is unable or  
> unwilling to commit to an individual user name within their domain. It  
> can do so by including the domain part but not the local-part of the  
> identity.
>
> INFORMATIVE DISCUSSION: This document does not require the value of the  
> "i=" tag to match the identity in any message header fields. This is  
> considered to be a verifier policy issue. Constraints between the value  
> of the "i=" tag and other identities in other header fields seek to  
> apply basic authentication into the semantics of trust associated with a  
> role such as content author. Trust is a broad and complex topic and  
> trust mechanisms are subject to highly creative attacks. The real-world  
> efficacy of any but the most basic bindings between the "i=" value and  
> other identities is not well established, nor is its vulnerability to  
> subversion by an attacker. Hence reliance on the use of these options  
> should be strictly limited. In particular, it is not at all clear to  
> what extent a typical end-user recipient can rely on any assurances that  
> might be made by successful use of the "i=" options.

That almost, but not quite, says the right thing.

Essentially, the signature MUST include the From header (others are at the  
signer's discretion). So, at a minimum, the signer is asserting that this  
message came into bis possession via a route that indicacted that its  
origin was within the domain within the From (mailing list signatures  
excepted, of course). If the signer is not prepared to vouch for that,  
then he has no business signing it.

Likewise, if he goes to the trouble of including an "i=[email-masked]", then  
he is asserting that [email-masked] had played some part in introducing the  
message into his system. Otherwise, he should not have included that tag.

So if the present documents do not make these things clear, then we need a  
further (BCP?) document that sets out, in the form of a Code of Practice,  
just what obligations are entailed by creating such a signature.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Nov 2007 10:46:27 -0800

On Nov 28, 2007, at 5:35 AM, Charles Lindsey wrote:

> On Tue, 27 Nov 2007 20:21:32 -0000, Douglas Otis <dotis@mail- 
> abuse.org> wrote:
>
>> Not exactly.
>>
>> -------
>> INFORMATIVE NOTE: The local-part of the "i=" tag is optional  
>> because in some cases a signer may not be able to establish a  
>> verified individual identity. In such cases, the signer may wish to  
>> assert that although it is willing to go as far as signing for the  
>> domain, it is unable or unwilling to commit to an individual user  
>> name within their domain. It can do so by including the domain part  
>> but not the local-part of the identity.
>>
>> the "i=" tag to match the identity in any message header fields.  
>> This is considered to be a verifier policy issue. Constraints  
>> between the value of the "i=" tag and other identities in other  
>> header fields seek to apply basic authentication into the semantics  
>> of trust associated with a role such as content author. Trust is a  
>> broad and complex topic and trust mechanisms are subject to highly  
>> creative attacks. The real-world efficacy of any but the most basic  
>> bindings between the "i=" value and other identities is not well  
>> established, nor is its vulnerability to subversion by an attacker.  
>> Hence reliance on the use of these options should be strictly  
>> limited. In particular, it is not at all clear to what extent a  
>> typical end-user recipient can rely on any assurances that might be  
>> made by successful use of the "i=" options.
>
> Essentially, the signature MUST include the From header (others are  
> at the signer's discretion). So, at a minimum, the signer is  
> asserting that this message came into bis possession via a route  
> that indicacted that its origin was within the domain within the  
> From (mailing list signatures excepted, of course). If the signer is  
> not prepared to vouch for that, then he has no business signing it.

Many providers do a good job, and only ensure behaviour of those  
granted access.  These providers might not require From email-address  
vetting equivalent to that of S/MIME certificates before granting  
access.  Such a provider may wish to ensure recipients that their  
outbound SMTP clients sign _all_ outbound messages.  If this assurance  
were possible, it could avoid complaints related to any spoofing which  
does not include their signature.  This is different from saying that  
all email-addresses within the From header are assured to belong to  
the purported author, as some might wish to assume.  SSP does _not_  
allow this distinction.  SSP policy is From domain centric, rather  
than from the perspective of the SMTP client.

This is a important distinction.  The provider might only vouch for  
the behaviour of their users, and not the accuracy of the From  
header.  Spam is defined based upon behaviour and not content, after  
all.

This becomes problematic when large providers using DKIM end up  
signing a fair amount of spam.  The proper way to handle this spam  
will depend upon knowing whether there are restrictions placed upon  
the use of the From email-address.

Unfortunately, providers may assert an SSP "all" to mitigate spoofing  
related complaints for messages they did not originate from their SMTP  
clients.  Before making this assertion, the provider instructs their  
customers to submit using only their outbound servers without imposing  
other restrictions.  This provider might even assign keys with "g=* 
+<group-number>" (based upon RFC 3598 sub-address extension)  
restrictions for MUA signed by customers who complain they don't  
always have access to the outbound servers.  And yes, some firewalls  
block port 587 for strange reasons.

When there are no or only limited restrictions on the From email- 
address use, the email-address in conjunction with the signing-domain  
should not be used as a basis for filtering spam.  A method to handle  
a situation of non-restricted From email-addresses being exploited by  
bots would be to include an opaque identifier based upon the account  
granted access.  An opaque identifier could track bot compromised  
systems independently from that of the From address.  An Opaque  
Identifier might be something as simple as u=<account-number> added to  
the DKIM signature.

DKIM must ensure correct identities are used to block spam.  For large  
domains, blocking can not always be done at the signing domain due to  
high levels of collateral blocking.

> Likewise, if he goes to the trouble of including an "i=[email-masked]",  
> then he is asserting that [email-masked] had played some part in  
> introducing the message into his system. Otherwise, he should not  
> have included that tag.

The i= parameter include the localpart to enable a key assigned to a  
group of users using the g= wildcard feature.  The i= syntax has been  
made necessary for a type of key which does not assure a unique  
identity.  Requiring the g= mask to be copied within the i= parameter  
would be a change to the DKIM base specification.  Not having the g=  
parameter contained within the message makes spam related filtering  
based upon the i= problematic.

> So if the present documents do not make these things clear, then we  
> need a further (BCP?) document that sets out, in the form of a Code  
> of Practice, just what obligations are entailed by creating such a  
> signature.

There remains a problem related to a provider's desire to avoid costly  
unwarranted complaints.  SSP currently does not offer an SMTP client  
centric policy assertion.  This limitation will tend to distort how  
Form header policy will be defined.  This situation requires that  
email-address restrictions must be made extremely clear.  Expecting  
this clarity based upon i= semantics remains problematic.  The TPA-SSP  
draft adds a scope= parameter that can be added to the non-TPA SSP  
record to make this assertion explicit.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 28 Nov 2007 11:35:46 -0800

> list that resigns messages? That doesn't seem right to me.

That's precisely one of the motivations for the local-part of the i=
tag.  If a message from this list, for example, were signed with
i=[email-masked], the signing address would not match
[email-masked], so there's no confusion about whether it's an
originator signature or a mailing list signature.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Nov 2007 12:08:01 -0800

On Nov 28, 2007, at 11:35 AM, Jim Fenton wrote:

> Michael Thomas wrote:
>> Frank Ellermann wrote:
>>
>> So the implication here is that that sort of domain could never run  
>> a mailing list that resigns messages? That doesn't seem right to me.
>
> tag.  If a message from this list, for example, were signed with i=[email-masked] 
> , the signing address would not match [email-masked], so there's  
> no confusion about whether it's an originator signature or a mailing  
> list signature.

1) The i= parameter must include the localpart to help ensure on who's  
behalf the message was signed.

(This might be helpful when the the identity is found within a Sender  
header instead of the From header.)

2) The localpart must be included within the i= parameter to ensure on  
who's behalf the message was signed, but _only_ when the localpart has  
been authenticated.

3) The localpart must be included within the i= parameter whenever a  
restricted key is used, but where the localpart may not have been  
fully authenticated when wildcards are employed.

It is not clear whether the localpart included within the i= parameter  
actually implies authentication.  I'll even bet that it doesn't in  
many cases.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Nov 2007 12:13:59 -0800

> originator signature or a mailing list signature.
I'm completely lost, sorry. I guess I have no idea what you mean by "From:
header field is valid" or "coming from themselves".

       Mike

---

From: Jim Fenton <[email-masked]>
Date: Wed, 28 Nov 2007 13:58:56 -0800

> header field is valid" or "coming from themselves".

It seems that my language wasn't precise enough, so let me take another
shot at it.

It has been noted that when a signing domain "claims responsibility for
the introduction of a message into the mail stream" it is not actually
asserting the validity of any part of the message.  This is relevant to
SSP because it has a dependency on whether the Signing Address (i=
address or its default) matches the address in the From: header field.

I propose to solve that problem by adding language similar to the
following to the SSP draft:

> Domains publishing SSP records indicating practices other than
> "unknown" MUST ensure the validity [correctness] of the address in the
> From: header field for messages to which they apply an Originator
> Signature.

In other words, before applying an Originator Signature, make sure the
message isn't spoofed.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Nov 2007 14:23:58 -0800

> In other words, before applying an Originator Signature, make sure the

I'm having trouble reconciling this with section 5.1:

5.1.  Determine Whether the Email Should Be Signed and by Whom

   A signer can obviously only sign email for domains for which it has a
   private key and the necessary knowledge of the corresponding public
   key and selector information.  However, there are a number of other
   reasons beyond the lack of a private key why a signer could choose
   not to sign an email.

      INFORMATIVE NOTE: Signing modules may be incorporated into any
      portion of the mail system as deemed appropriate, including an
      MUA, a SUBMISSION server, or an MTA.  Wherever implemented,
      signers should beware of signing (and thereby asserting
      responsibility for) messages that may be problematic.  In
      particular, within a trusted enclave the signing address might be
      derived from the header according to local policy; SUBMISSION
      servers might only sign messages from users that are properly
      authenticated and authorized.

This is basically saying that you shouldn't sign for things you
don't want to take responsibility for, which I'd think is pretty
obvious that you wouldn't want to take responsibility for something
that could be a forgery. 

My question is whether we're trying to put too fine a point on 
this, and whether trying to clarify things makes it even more
murky. Also: I'm wondering whether the point Dave seems to be 
making is anything more than a theoretical problem. Who in their
right mind would assert responsibility for something that is a
possible forgery? And if they do, why should anybody care about
their promiscuity?

FWIW, the new proposed text didn't really help me. Maybe tightening up the
text in 5.1 to be a bit more explicit might be a better approach?

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Nov 2007 14:48:28 -0800

On Nov 28, 2007, at 1:58 PM, Jim Fenton wrote:

> It seems that my language wasn't precise enough, so let me take  
> another shot at it.
>
> It has been noted that when a signing domain "claims responsibility  
> for the introduction of a message into the mail stream" it is not  
> actually asserting the validity of any part of the message.  This is  
> relevant to SSP because it has a dependency on whether the Signing  
> Address (i= address or its default) matches the address in the From:  
> header field.
>
>> "unknown" MUST ensure the validity [correctness] of the address in  
>> the From: header field for messages to which they apply an  
>> Originator Signature.
>
>
> In other words, before applying an Originator Signature, make sure  
> the message isn't spoofed.

Mailing-lists should still be able to sign their outbound messages!

I think you mean "Do not include the localpart within the i= parameter  
when the email-address within the From header has not been  
authenticated."

What about Sender and Resent-* headers?

Why not say: "Do not include the localpart within the i= parameter  
when the email-address has not been authenticated."  It does not  
really matter which header is contains a matching domain for which the  
signature is being added.

This is not defined within the base draft where this added condition  
appears to be a significant change.

Are DKIM signing MTAs even able to make these authentication assurances?

Should the i= parameter be forced to exclude localparts when this  
email-address authentication assurance can not be made?

Secondly, how would you classify the possibility for spoofing when MUA  
keys employ partial g= restrictions?

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 28 Nov 2007 15:00:17 -0800

I'm lost, but I'll answer what I can...

Douglas Otis wrote:
>> signer is making that assertion in the specific case when the address
>> in the From: header field is the same as the signing address.  SSP
>> has no other dependency on whether the signer is asserting validity
>> or is "merely" taking responsibility.
>

SSP does, indeed, deal specifically with the From email address.  I have
no idea what this might have to do with responsibility for content.

> might restrict From email-address use to just authenticated owners,

Let me state it differently then:  If you're publishing an SSP record
other than "unknown", make sure you're not applying an Originator
Signature to spoofed mail.
>> add verbiage to SSP stating that domains publishing SSP records other
>> than "unknown" MUST additionally ensure that they only sign messages
>> purporting to come from themselves when the address in the From:
>> header field is valid.
>
> confront such a mixture.  And this must include assertions about
> third-party domains (which includes sub-domains).

I'm not sure what "restricted" means, but I suppose I'll find out when I
read your draft.

-Jim

---

From: Jon Callas <[email-masked]>
Date: Wed, 28 Nov 2007 15:09:52 -0800

I have to strongly disagree with many of the things said here. I am  
one of the original authors and designers, and while I don't speak  
for the other authors and designers, I believe that I can reasonably  
authoritatively say something about DKIM's original intent.

This working group can, of course, *change* DKIM's intent with  
nothing more than rough consensus. However, I have to object when I  
hear the intent misstated. Rather than write a huge note, I'm going  
to break my major objections up.

DKIM is subtly different from OpenPGP [1] and S/MIME. DKIM is  
analogous to a postmark, as opposed to the signature on a letter  
inside the envelope. To use another analogy, it is like the routing  
tag that an airline puts on baggage to make sure it wends its way  
through an airport. There's no corresponding equivalent to the  
OpenPGP-S/MIME signatures in this analogy, but DKIM is a statement  
about the container rather than the contents.

Because of the way that digital signatures work, the mechanics of the  
signature has to cover the body of the message. But the airport  
routing tag also by necessity covers the content of the bag because  
the laws of physics just work that way. That's not the intent.

Each of these metaphors will break down if I go further with them, so  
I won't. I'll move to a use case.

The buck for the "administrative domain" of callas.org lies  
ultimately with me. I run it. I have a number of users, who are all  
members of my family. The way that I run the system, it's possible  
for us to forge messages from each other. Now, the MTA will also put  
in a header line that says who the authenticated sender is, but  
that's in a "Received" line, and isn't going to be signed by DKIM.

My policy is that an authenticated user can "forge" senders. If that  
policy turns out to be unwise, it's my problem. It is the intent of  
DKIM that the administrative domain has the right to be stupid.  
Nonetheless, a DKIM signature means that I accept responsibility for  
a message I (meaning one of my authenticated users) put into the mail  
stream.

	Jon

[1] PGP is software, OpenPGP is an IETF standards-track protocol. The  
PGP software implements a number of standards including OpenPGP, S/ 
MIME. The name PGP is a trademark of PGP Corporation.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 28 Nov 2007 15:10:14 -0800

Michael Thomas wrote:
> My question is whether we're trying to put too fine a point on this,
> and whether trying to clarify things makes it even more
> murky. Also: I'm wondering whether the point Dave seems to be making
> is anything more than a theoretical problem. Who in their

That was what I meant when I said earlier, "it's vaguely silly for a
signer to take responsibility for a message that purports to come from
themselves, but which they didn't send."
> text in 5.1 to be a bit more explicit might be a better approach?

If you mean adding additional text in SSP to clarify (or expand on) 5.1
when SSP is being used, sure.  Otherwise, it's hard to tighten up 5.1
since it's already published.  Sorry the new text didn't help; I'll keep
trying.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 28 Nov 2007 15:25:27 -0800

> I'd wonder how "purporting" and "valid" above would be

Agree that my wording wasn't clear.  Let me try again:

If you're publishing SSP other than "unknown",
     and you're applying an Originator Signature (as defined in
-dkim-ssp section 2.8),
        then you MUST ensure that the message was sent by an entity
authorized to use the Originator Address (as defined in -dkim-ssp
section 2.3) [i.e., that the message wasn't spoofed]
> I'd check the "MUST" by looking at someone's code.

I see this as less of a coding (implementation) issue than one of
deployment.  There are mechanisms like SMTP AUTH that are available for
use to allow a given domain to meet this requirement, or the signer
might just accept mail from a trusted webmail server that authenticates
its users.
> the overview would be better if we want to say anything

I'll leave it up to the WG to decide whether we're splitting hairs
here.  I'm just suggesting that if we do decide we want to go there,
here's how we might address the issue.

-Jim

---

From: Jon Callas <[email-masked]>
Date: Wed, 28 Nov 2007 15:41:38 -0800

The thing I find most disturbing is that I perceive an effort to turn  
DKIM into a user-level signing system. This is not the intent of DKIM.

DKIM has never outright forbidden this -- heck, what consenting  
senders do in the privacy of their own domain is their business. But  
DKIM is carefully constructed so that the signature tracks back to  
the domain and only the domain for privacy reasons. We didn't want it  
to be a big brother identification and tracking system. Changing that  
is not only a change counter to the intent of DKIM, but it is wicked  
and evil. It contributes to the creeping surveillance we're all  
subject to.

(Side note: I am well aware that email as it exists bleeds lots of  
tracking information and that the number of times that unsigned  
content has ever been challenged can be counted on one hand, if not  
one finger. If you can't figure out what countries I've been in in  
the last couple of weeks, your header-reading-fu needs a serious  
remedial lesson. That's beside the point, however. We didn't want  
DKIM to make the situation worse.)

There are a number of places that this is happening. One of which is  
the continued suggestion that i= means something, or worse *must* (I  
don't know if the "musts" I have seen are MUSTs) track back to the  
user. Stop that, please.

The i= tag is a note from the signer to the signer. It can be  
anything the signer desires, and the verifier interprets it at his  
own peril. It is a Humpty-Dumpty thing, it means whatever the signer  
wants it to mean.

In general, signers *will* put something that is essentially tracking  
information in i=. I accept that. In general, if  
"i=[email-masked]" is in a DKIM signature, there are things a  
clever receiver can deduce from that. Fair enough.

Nonetheless, to step past that and assert that there must be user- 
level tracking in DKIM whatever the mechanism, or even that user- 
level tracking should be part of best practices is stepping too far.  
Spam fighting is not so important that we should erode privacy  
further than it is already eroded. It is not so important that we  
should infringe upon the sovereignty of a domain and impede its  
ability to protect its users.

	Jon

---

From: Jim Fenton <[email-masked]>
Date: Wed, 28 Nov 2007 16:16:47 -0800

> don't know if the "musts" I have seen are MUSTs) track back to the  

There is no requirement in DKIM, or SSP, that i= have a local-part,
unless a domain decides to delegate keys at the user level (with the g=
tag on the key).  I have been talking about user-level signing a lot in
this thread in an effort to be complete.

I see the need for the local-part in i= primarily to disambiguate a use
case that Mike Thomas mentioned earlier today.  If I send a message from
[email-masked] and it were to be signed by this mailing list, the
signing domain would be mipassoc.org.  It's obvious then that it's not
an Originator Signature.  But of my address were instead
[email-masked] and the list applied a signature with no local-part
in i=, one couldn't tell whether the signature represented the message
passing from me to the mailing list (an Originator Signature), or from
the mailing list to the users.  In that instance, the local-part on i=
tells what kind of signature this is, to provide equivalent
functionality when users and lists (or other re-signers) happen to be in
the same domain as when they don't.  I believe this is better than
requiring that re-signers and users be relegated to different domains.
> own peril. It is a Humpty-Dumpty thing, it means whatever the signer  

The SSP draft that's on the table matches the local-part of the From
address against the local-part of i= if it is provided, so it goes
against what you just said.  RFC 4871 also requires the local-part to
match the g= tag on the key if it is present.
> ability to protect its users.

I consider myself to be a privacy advocate too, but feel that we need to
balance user-level signing assertions against ambiguities that exist in
their absence.  I think DKIM and SSP strike a good balance.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 28 Nov 2007 16:32:31 -0800

> a message I (meaning one of my authenticated users) put into the mail  
I have avoided using the term "forge" because it is imprecise, and
here's an example of it.  I don't think that authenticated users of
callas.org can forge each other's email, because Jon has authorized his
family to use any address in the domain.  If it's authorized, it's not
forgery, is it?

Nevertheless, there will be lots of domains, particularly bigger ones,
that don't authorize anyone in the domain to use any address in the
domain.  Some of these will want to delegate keys to third parties, and
will need third parties with g= in their key records to use the
local-part on i=.  It's entirely up to local domain policy whether they
want to use this feature, however.

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 28 Nov 2007 19:41:08 -0500

> family to use any address in the domain.  If it's authorized, it's not

If the definition of authorized includes not implemented technical measures to 
prevent it, then sure.  I expect that even within such a family domain there 
is an expectation that this is not appropriate to do (that's certainly the 
case here).

> want to use this feature, however.

Personally, I think this is a much lower risk case than shared servers that 
serve multiple domains with disjoint user sets needing to worry about 
cross-domain 'forgery'.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Nov 2007 16:43:47 -0800

On Nov 28, 2007, at 3:00 PM, Jim Fenton wrote:

>> restricted?  If so, this could then shift content responsibility  
>> onto the From email-address identity.  If not, the signing domain  
>> is only responsible for permitting some unknown users access.   
>> Clearly, granting access says very little about content.  Just  
>> granting access without email-address restrictions requires  
>> reputations to be based upon a collective behaviour of users to  
>> which they grant access.
>
> SSP does, indeed, deal specifically with the From email address.  I  
> have no idea what this might have to do with responsibility for  
> content.

All headers are found in message content.  DKIM is unrelated to the  
envelope.

An identity associated with an email-address within message content  
should not be assumed authenticated when a signing domain matches an  
email-address domain found within the From, Sender, or Resent-*  
headers.  After all, asserting an SSP "ALL" might be to mitigate  
spoofing complaints caused by messages submitted from other domains.

Signatures may only assure recipients where the particular message had  
been submitted, but not whether the identity of the email-address  
matching the domain of the signature has been authenticated.  This is  
what was meant by not being responsible for content.

A DKIM signature may only attest to the domain's stewardship at  
excluding access to those who spam (spamming is a behaviour unrelated  
to content).  Excluding access does not require the authentication of  
email-address identities.  The account used for access and the email- 
addresses submitted are often independent items.  There are ways these  
two items can be joined, but normally they are not.  See Frank's note.

> Let me state it differently then:  If you're publishing an SSP  
> record other than "unknown", make sure you're not applying an  
> Originator Signature to spoofed mail.

Your use of "Originator Signature" seems to imply a signature that  
contains a matching i= parameter and a domain or parent domain d=  
parameter of the email-address found within the From header.

Per SSP draft:
,---
| The "Originator Address" is the email address in the From header
| field of a message [RFC2822], or if and only if the From header field
| contains multiple addresses, the first address in the From header
| field.
'---

A mailing-list can easily conform to an SSP "ALL" policy and yet sign  
messages containing From headers where the owners of email-addresses  
have not been authenticated.  Adding scope that specifically asserts  
authentication could be useful.  I assume you mean the i= parameter  
should not include the localpart.  There is a corner case for a  
semantic that asserts when i=localpart, this means the associated  
identity has been authenticated.  The problematic case would be with  
g= wildcard restricted keys.  For these keys, i= localpart inclusion  
becomes _necessary_, even when the identity associated with the  
localpart is not authenticated.

>> authenticated owners.  What happens when they wish to send a  
>> message where a user is not authenticated, but where use of some  
>> critical email-addresses are restricted.  There are currently no  
>> existing semantics to permit a mixed assertion, however actual use  
>> is likely to confront such a mixture.  And this must include  
>> assertions about third-party domains (which includes sub-domains).
>
> I'm not sure what "restricted" means, but I suppose I'll find out  
> when I read your draft.

You typically make an indirect assertion regarding whether an  
Originator Address is "valid".  I interpret this to be saying that the  
provider restricts signing email-addresses where the localpart is  
contained within the i= parameter to specific authenticated  
identities.  (Perhaps these identities would be defined as those who  
have exclusive access to a mailbox associated with the email- 
address.)  The TPA-SSP draft defines the "-i" suffix added to the  
"scope=" parameter to assert identities for the scoped headers are  
authenticated.  The TPA-SSP draft assumed rules regarding which header  
was signed will apply when the signing and email-address domains  
match.  There are two different scopes for message content, the  
(F)rom, and (O)ther being the Sender, or Resent-* headers.   Only when  
the From header is signed by a third-party domain would the TPA-SSP  
scope indicating authentication of identities become critical for  
domain parity.

-Doug

---

From: John Levine <[email-masked]>
Date: 29 Nov 2007 03:48:35 -0000

> But of my address were instead [email-masked] and the list
> applied a signature with no local-part in i=, one couldn't tell
> whether the signature represented the message passing from me to the
> mailing list (an Originator Signature), or from the mailing list to
> the users.

Right.  That's a feature, not a bug.  As Jon has eloquently reminded
us, the granularity of DKIM validation is domains, not mailboxes.  If
for some reason it is important to you to separate the reputation of
your list mail from your individual mail, sign the list mail with a
different signing domain.  You can also put the lists into a different
domain, but that's optional.

>match the g= tag on the key if it is present.

4871 says that the local part in g= matches the local part in i= but
that local part is still an opaque token, not a mailbox.

R's,
John

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 29 Nov 2007 11:26:20 -0000

> own peril. It is a Humpty-Dumpty thing, it means whatever the signer

If the i= tag does not "mean something", and the verifier cannot make use
of it for any purpose, then what on earth is the point of having it in the
standard in the first place?

AFAICS, it does not mean much, but at least is should mean that whatever
user of domain is present in that tag was known to have played some part
in bringing that message to the signer.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 29 Nov 2007 11:32:55 -0000

>> Essentially, the signature MUST include the From header (others are at  
>> the signer's discretion). So, at a minimum, the signer is asserting  
>> that this message came into bis possession via a route that indicacted  
>> that its origin was within the domain within the From (mailing list  
>> signatures excepted, of course). If the signer is not prepared to vouch  
>> for that, then he has no business signing it.
>
> Many providers do a good job, and only ensure behaviour of those granted  
> access.  These providers might not require From email-address vetting  
> equivalent to that of S/MIME certificates before granting access.  Such  
> a provider may wish to ensure recipients that their outbound SMTP  
> clients sign _all_ outbound messages.  If this assurance were possible,  
> it could avoid complaints related to any spoofing which does not include  
> their signature.  This is different from saying that all email-addresses  
> within the From header are assured to belong to the purported author, as  
> some might wish to assume.  SSP does _not_ allow this distinction.  SSP  
> policy is From domain centric, rather than from the perspective of the  
> SMTP client.

If there are multiple addresses in the From header, then there is supposed  
to be a Sender. In that case, the signer (who SHOULD then include the  
Sender in the signature) is asserting that the messages arrived into his  
possession from the Sender rather than from the From. But in the absence  
of a Sender header, then the signer is vouchong for the From. What steps  
the signer takes to satisfy himself that either the Sender or the From is  
one of its legitimate clients is another matter, but such steps must not  
be entirely absent.

Note that a mailng list expander is supposed to insert a Sender.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 29 Nov 2007 10:40:39 -0500

> Note that a mailng list expander is supposed to insert a Sender.

IIRC it's a SHOULD and not a MUST, so one really can't rely on it.

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Thu, 29 Nov 2007 10:09:18 -0800

> domain, but that's optional.

The issue here isn't reputation (although this may come up in that
context, too); the issue is whether a given signature is interpreted as
an Originator Signature or not by SSP.
> that local part is still an opaque token, not a mailbox.

That's a creative interpretation, but it isn't supported by 4871.  From
the tag definitions in section 3.5:

>    i=  Identity of the user or agent (e.g., a mailing list manager) on
>        behalf of which this message is signed (dkim-quoted-printable;
>        OPTIONAL, default is an empty Local-part followed by an "@"
>        followed by the domain from the "d=" tag).

Although 4871 doesn't specify any semantics associated with the
local-part of i=, if it had been intended to be an opaque token, it
would have been worded differently.  It's true that 4871 says that the
local-part doesn't have to match any particular header field, but says
in an informative discussion that this is a "verifier policy issue". 
This leaves the door open to matching the local-part to a header field
as has been proposed in the SSP draft.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Nov 2007 11:34:15 -0800

>> As Jon has eloquently reminded us, the granularity of DKIM  
>> validation is domains, not mailboxes.  If for some reason it is  
>> important to you to separate the reputation of your list mail from  
>> your individual mail, sign the list mail with a different signing  
>> domain.  You can also put the lists into a different domain, but  
>> that's optional.
>
> context, too); the issue is whether a given signature is interpreted  
> as an Originator Signature or not by SSP.

Per SSP:
,---
|2.8. Originator Signature
|
| An "Originator Signature" is any Valid Signature where the signing
| address (listed in the "i=" tag if present, otherwise its default
| value, consisting of the null address, representing an unknown user,
| followed by "@", followed by the value of the "d=" tag) matches the
| Originator Address.  If the signing address does not include a local-
| part, then only the domains must match; otherwise, the two addresses
| must be identical.
'---

The term Originator Signature will not clarify whether the identity  
within the email-address had been authenticated (per non-normative  
notes within the base specifications regarding inclusion of the  
localpart within the i= parameter).

When a large domain is signing with DKIM and is submitting a fair  
amount of spam, there will be a desire to make erroneous assumptions  
to block based upon email-addresses in conjunction with DKIM signing  
domain.  The term Originator Signature sheds no light on this matter  
whatsoever.  It would be very wrong to even think that it does.

The missing definition is:

: Authenticated Identity
:
: An "Authenticated Identity" is determined by a Valid Signature where
: the signing domain within the d= tag is the same or a parent domain
: of the email-address within the header, and where the localpart is
: also fully included within the "i=" tag.

>> 4871 says that the local part in g= matches the local part in i=  
>> but that local part is still an opaque token, not a mailbox.
>>
>
> That's a creative interpretation, but it isn't supported by 4871.   
> From the tag definitions in section 3.5:

No.  There are _no_ stipulations that the "on behalf of" email-address  
identity be elsewhere in the message.

> would have been worded differently.  It's true that 4871 says that  
> the local-part doesn't have to match any particular header field,  
> but says in an informative discussion that this is a "verifier  
> policy issue".  This leaves the door open to matching the local-part  
> to a header field as has been proposed in the SSP draft.

Sorry Jim, but as you can see from the quoted section, even the SSP  
draft fails to make the distinction of i= semantics.  See my suggested  
definition.

-Doug

---

From: John L <[email-masked]>
Date: Thu, 29 Nov 2007 14:41:17 -0500 (EST)

> an Originator Signature or not by SSP.

Seems to me that any algorithm more complex than comparing the From: 
domain to the signing domain will die in the Swamp of Unforseen and 
Unmanageable Complexity.  If you mean something different when you sign 
list mail than when you sign individual mail, use a different signing 
domain.  As Jon reminded us, the semantic granularity of DKIM is domains, 
not mailboxes.

>>    i=  Identity of the user or agent (e.g., a mailing list manager)

> would have been worded differently.

Now wait a minute.  I don't see the word "mailbox" or "address" there, I 
see the carefully neutral term "identity".  The following text says that 
it has the syntax of a mailbox, not the semantics of a mailbox.

It's a cookie, just like the cookie that the late lamented RFC 1413 IDENT 
returns.  In many cases those cookies may happen to match mailbox names, 
but in just as many cases they don't, and it's poor design to assume that 
they do.  See the informative discussion two paragraphs later.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J D Falk" <[email-masked]>
Date: Thu, 29 Nov 2007 15:00:06 -0500

> Nonetheless, to step past that and assert that there must be user-
level
> tracking in DKIM whatever the mechanism, or even that user- level
> tracking should be part of best practices is stepping too far. Spam
> fighting is not so important that we should erode privacy further than
> it is already eroded. It is not so important that we should infringe
> upon the sovereignty of a domain and impede its ability to protect its
> users.

It also strikes me as odd to assume that a receiver/verifier WANTS to
track individual users (or user-equivalent entities) within the
responsible domain.  That's a ton of extra work, for very little benefit
(from an anti-spam point of view.)

The attack here is obvious: spammers will simply use a new i= per
message, much as they rotate through every other possible identifier.
So, anyone hoping to use i= to identify spammers will be forced to move
back up to d=.

As we continue thinking about this stuff, it's important to remember
that methods for identifying "good" messages don't directly convert to
methods for identifying "bad" messages.

--
J.D. Falk
Receiver Products
Return Path

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Nov 2007 12:13:49 -0800

On Nov 29, 2007, at 12:00 PM, J D Falk wrote:

> It also strikes me as odd to assume that a receiver/verifier WANTS  
> to track individual users (or user-equivalent entities) within the  
> responsible domain.

Agreed.

>  That's a ton of extra work, for very little benefit (from an anti- 
> spam point of view.)

No. With there being so many bots, it is common to find a large domain  
sending a fairly high level of spam.  It would be helpful if there  
were a means to mitigate spam from such a domain without blocking the  
entire domain.  In addition, don't forget about the replay issue.

> message, much as they rotate through every other possible  
> identifier. So, anyone hoping to use i= to identify spammers will be  
> forced to move back up to d=.

This is not a problem.  The domain will not be of mixed content.

> that methods for identifying "good" messages don't directly convert  
> to methods for identifying "bad" messages.

The problem is being able to identify the responsible entity for  
having issued the spam.  DKIM clearly works at the domain.  It might  
be able to extend to the email-address when additional assurances have  
been made.  See scope=.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 29 Nov 2007 15:30:56 -0500

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

+1. I can't see that working well or even practical.

-- 
Sincerely

Hector Santos, CTO

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 29 Nov 2007 15:32:47 -0500

> entire domain.  In addition, don't forget about the replay issue.

Then find a solution other than DOMAIN Keys Identified Mail for that problem.  
A user level reputation system is going to be at least an order of magnitude 
harder than domain reputation and we really don't have the domain level 
problem figured out yet.

Scott K

---

From: "J D Falk" <[email-masked]>
Date: Thu, 29 Nov 2007 15:43:55 -0500

Doug Otis opined:

> entire domain.

I agree, that would be extremely helpful -- but DKIM's i= won't give it
to us.  (Unless you're assuming that these same botnet operators will
allow themselves to be corralled into a single identifer, which clearly
isn't the case.)

Scott Kitterman responded:

>  Then find a solution other than DOMAIN Keys Identified Mail for that
> problem. A user level reputation system is going to be at least an
order
> of magnitude harder than domain reputation and we really don't have
the
> domain level problem figured out yet.

+1

--
J.D. Falk
Receiver Products
Return Path

---

From: Hector Santos <[email-masked]>
Date: Thu, 29 Nov 2007 16:08:15 -0500

> a message I (meaning one of my authenticated users) put into the mail  

And let me say Jon, thanks for helping put it together.

My only issue is the term "responsibility."

In my opinion, you are are always inherently responsible for your system 
regardless of DKIM.

So are we now saying there is a even a greater "responsibility" once you 
sign with DKIM?

What about the domain with the optional signing policy (default)?  Are 
they responsible for the own domains they sign and not responsible for 
their own domains they don't sign?

To me, what we are really talking about is "authenticating ownership" 
not of the author's message content but of the transaction.

For example, a DOMAIN, example.com, has a "I sometime sign" SSP.

For some reason, his system signs some but not all, so a receiver can 
potentially get four types of messages purported from example.com:

   1S) signed by example.com (REALLY FROM EXAMPLE.COM)
   1U) unsigned by example.com (REALLY FROM EXAMPLE.COM)
   2S) signed by example.com (REALLY FROM BAD GUY)
   2U) unsigned by example.com (REALLY FROM BAD GUY)

SSP will not help much here, other than tell the receiver that some mail 
  can be signed.

In theory, the resultant classification (not related to whether a 
message is ultimately rejected or accepted) is:

   1S) VALID
   1U) INVALID DUE TO DKIM SPECIFICATION (NO SIGNATURE)
   2S) INVALID DUE TO DKIM SPECIFICATION (BAD HASH)
   2U) INVALID DUE TO DKIM SPECIFICATION (NO SIGNATURE)

Never mind the predicament this puts the receiver in, which messages are 
you responsible for?

According to DKIM,  you are responsible for 1S and 2S - the ones that 
were signed, including the forge or spoofed DKIM message.  Conversely, 
according to DKIM semantics, you are NOT responsible for 1U - the one 
really from you and 2U the one from the bad guy.

 From a receiver standpoint, it will know the difference between 1U and 
2U unsigned transactions.  It also tells me that you have a 75% chance 
of adding a negative classification weight for the default "I something 
sign" policies.

One reason I think the "Ignore if invalid signature" DKIM rule is a 
terrible idea is because its an untruthful state in an automated 
transaction world.

In 2S, there was an obvious intent to signing.  But it failed. So this 
SHOULD have a higher negative classification weight.

If one was to use a neuron network or Bayes like based decision tree, 
this is the type of information that is needed.  But if we follow the 
DKIM "IGNORE IF FAILURE" rule, one can say the classification would be:

   1S) +1
   1U) -.25 (following DKIM)
   2S) -.25 (following DKIM INVALID IS NO SIGNATURE)
   2U) -.25 (following DKIM)

See the problem?  1U, 2S and 2U can potentially have the same weight.

If we include the true failure fact of 2S, the weight might be:

   1S) +1
   1U) -.25 (following DKIM)
   2S) -.50 (following DKIM INVALID IS NO SIGNATURE)
   2U) -.25 (following DKIM)

So we really can't ignore the invalid signature attempts.

Ultimately, DKIM or no DKIM, you are responsible for all of this.

So to me, DKIM is about taken ownership with signed transactions, the 
added DKIM "tokens" provide new attributes that is typically missing in 
normal email.

-- 
Sincerely

Hector Santos, CTO

---

From: Jon Callas <[email-masked]>
Date: Thu, 29 Nov 2007 13:36:12 -0800

> standard in the first place?

It is there for the signer to relate the message back into their own  
framework. It is there so that *when* you get a complaint about a  
message, you have more to go on.

Let us suppose that the DKIM signer writes out log messages with a  
monotonically increasing numbers for each message it signs. That  
number is a perfectly fine thing to put in i= because it lets the  
signer know who did a bad thing. (Or whose message was used as a bad  
thing.)

> in bringing that message to the signer.

Who says there has to be a domain in the tag? In the example I gave,  
it can be a number.

While it is an identity, we are completely open as to what that  
identity has to be. It doesn't have to be an email address, or an  
account, or anything. 4871 says that <string>@<domain-from-d=> is the  
default, and it makes a certain sense to do that, it is not required.

There are very good reasons for making it opaque. It protects the end  
user from harassment, and makes sure that if the user is misbehaving,  
the place people complain is to the domain itself.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Nov 2007 14:20:04 -0800

On Nov 29, 2007, at 1:36 PM, Jon Callas wrote:

>> If the i= tag does not "mean something", and the verifier cannot  
>> make use of it for any purpose, then what on earth is the point of  
>> having it in the standard in the first place?
>

Agreed.

However, by including the scope= parameter, both you and Jim can be  
satisfied.  When Jim and Frank achieve identity authentication (where  
the i=<localpart> is asserted to be an indicator of authentication),  
this would ensure proper message filtering and annotation.  Knowing  
whether intra-domain spoofing is prevented does have value.  Of  
course, the DKIM group could insist this feature not be allowed, where  
identity authentication is limited to S/MIME and OpenPGP.  When added  
as an SSP scope= parameter, this assertion allows a few to indicate  
they are authenticating the identity associated with the email- 
address.  The scope= approach also makes it clear when _no_  
assumptions should made about authentication of the identity  
associated with the email-address.  Clarifying this issue via policy  
assertions would be safer approach.  Otherwise, people are likely to  
try anyway and make wrong assumptions.

>> AFAICS, it does not mean much, but at least is should mean that  
>> whatever user of domain is present in that tag was known to have  
>> played some part in bringing that message to the signer.
>

Agreed.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Nov 2007 15:38:14 -0800

On Nov 29, 2007, at 12:43 PM, J D Falk wrote:

>> No. With there being so many bots, it is common to find a large  
>> domain sending a fairly high level of spam.  It would be helpful if  
>> there were a means to mitigate spam from such a domain without  
>> blocking the entire domain.
>
> I agree, that would be extremely helpful -- but DKIM's i= won't give  
> it to us.  (Unless you're assuming that these same botnet operators  
> will allow themselves to be corralled into a single identifer, which  
> clearly isn't the case.)

The provider might limit i= annotation to those accounts specifically  
assigned the particular email-address.  This would not be easy,  
however RFC2554/4954 and RFC4409 provide a foundation for such a  
mechanism.  It might be easier to use opaque identifiers, where SSP  
policy indicates these identifiers relate to an account granted  
access.  This assertion could look something like scope=F-a.  Either  
scope=F-i or scope=F-a would be making an assertion about what is  
being authenticated.  Scope=F (the default) would indicate the DKIM  
signature is independent of access/email-address identity  
authentications.

>> Then find a solution other than DOMAIN Keys Identified Mail for  
>> that problem. A user level reputation system is going to be at  
>> least an order of magnitude harder than domain reputation and we  
>> really don't have the domain level problem figured out yet.
>
> +1

This information still allows valuable message annotations to better  
protect individuals from intra-domain spoofing.  Intra-domain spoofing  
would be a greater problem for large domains.  Such authentication  
assertion could indicate whether the recipient should even attempt to  
validate the signature when faced with too many abusive replays.

When a signing domain fails to offer some intra-domain identifier,  
bots and replay abuse may make validating DKIM signatures unable to  
justify the resources required.  Some intra-domain identifier, opaque  
or otherwise, could provide a practical means to deal with an abuse  
problem.  The alternative is the reputation of SMTP client IP  
address.  While larger domains represent less that 15% percent of the  
all email-sources, these large domains also represent more than 90% of  
the total message volume.  Bots are leveraging this situation in a  
major way.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 30 Nov 2007 11:38:37 -0000

On Thu, 29 Nov 2007 21:36:12 -0000, Jon Callas <[email-masked]> wrote:

>> make use

> default, and it makes a certain sense to do that, it is not required.

It has to be of the syntactic form of an <addr>. The usual implication of  
such syntax appearing in a standard is that a thing that looks like an  
<addr> is expected to be an <addr>. If there is any other intent (e.g. it  
was a Message-ID), then one would expect the standard to say so. The  
wording in 4871 strongly suggests, by implication, that the domain at  
least is supposed to be a domain.

If a signer wishes to include private information in his signature to  
assist with his own internal processes, such as dealing with complaints,  
then the correct procedure is to invent his own tag for the purpose, e.g.

..............priv=1234567890...........

Thas is syntactically allowed (3.2). Granted it says "Unrecognized tags  
MUST be ignored", but I would regard that as applying to verifiers who  
have not the slightest idea what they mean. I don't think it precludes the  
signer from using it.

---

From: John Levine <[email-masked]>
Date: 30 Nov 2007 16:18:07 -0000

>was a Message-ID), then one would expect the standard to say so.

The local part is not a mailbox, and it's not a Message-ID.  If it
were a mailbox, it would say it was a mailbox, or if it were a
Message-ID, it would say it's a Message-ID.  We're not deconstructing
the Talmud here, the words mean what they say.

> The wording in 4871 strongly suggests, by implication, that the
> domain at least is supposed to be a domain.

Um, it's not an implication, its a MUST:

  The domain part of the address MUST be the same as or a subdomain of
  the value of the "d=" tag.

R's,
John