Subject: [ietf-dkim] Seriously.

From: "J D Falk" <[email-masked]>
Date: Fri, 18 Jan 2008 21:28:55 -0500

How many people here have EVER seen a real message (not just a test to
see if it'd work) with multiple addresses in the From: header?

I know I'm still a newbie around here -- I've only been working on mail
systems since 1994 -- but I've never seen it.

Seems to me that this is one of the furthest-out edge cases yet.

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

---

From: Steve Atkins <[email-masked]>
Date: Fri, 18 Jan 2008 19:02:08 -0800

> Seems to me that this is one of the furthest-out edge cases yet.

Never seen it. No trace of it in any mailboxes here.

"What if spammers did it in order to compromise SSP?" is a
perfectly reasonable question.

"Multiple From: fields implies SSP fail" is a perfectly reasonable
answer.

Cheers,
   Steve

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 19 Jan 2008 08:25:22 +0100

J D Falk wrote:

> How many people here have EVER seen a real message (not just
> a test to see if it'd work) with multiple addresses in the
> From: header?

I have seen it in (de) Usenet FAQ messages with more than one
author.  IIRC I've never seen a multi-From or Resent-* in any
mail inbox, of course I could have missed it.
 
> Seems to me that this is one of the furthest-out edge cases

Please - I'd support to deprecate Resent-* since MARID, and 
while at it multi-From can also go.  But the place to do it
wasn't MARID or now DKIM, it would be 2822upd and after that
mail-arch.  But these proposals were REJECTED, and nobody
here (with two exceptions) bothered to at least try it.

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Sat, 19 Jan 2008 13:08:38 +0100

J.D. & Steve,

Thanks for affirming my own thoughts - we have a corner case and we just 
need to handle it safely.  We can't leave a gaping hole through which 
all spammers can walk.  I believe John L's and Arvel's proposal is 
perfectly fine for this corner case, along with what Mike Thomas and I 
suggested (a sentence or two in the security considerations about DNS 
queries).

I've been doing this stuff not quite as long as Dave or Eric, but still 
a long time, and I have *ONCE* seen a multiple From: line (I recall it 
because it was recent, and it broke something!).

Eliot

---

From: Matthew Joseff <[email-masked]>, [email-masked], [email-masked]
Date: Sat, 19 Jan 2008 13:54:03 +0000 (UTC)

On Fri, 18 Jan 2008, Steve Atkins wrote:
}"What if spammers did it in order to compromise SSP?" is a
}perfectly reasonable question.

We agree that this alone is good enough reason.

---
Ron Paul for President.  http://www.ronpaul2008.com/
Legitimate use of violence can only be that which is required in self-defense.

---

From: Tony Finch <[email-masked]>
Date: Mon, 21 Jan 2008 18:59:42 +0000

> see if it'd work) with multiple addresses in the From: header?

I have sent messages From: multiple authors, e.g. a party invitation from
me and my wife. It was not an interop success :-) Recipients' clients
would typically ignore one of the addresses or get slightly confused, both
when displaying the message and when replying to it.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: NORTHERLY 4 VEERING SOUTHERLY 7 OR GALE 8,
OCCASIONALLY SEVERE GALE 9 IN SOUTHEAST ICELAND, PERHAPS STORM 10 LATER. ROUGH
BECOMING VERY ROUGH OR HIGH. WINTRY SHOWERS. MODERATE OR GOOD BECOMING POOR.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Jan 2008 11:25:55 -0800

> when displaying the message and when replying to it.

There are two different issues in this thread that I think ought to dominate:

1. Multiple From addresses are in the RFC2822 standard, folks. The capability 
was defined in RFC 733 (1977) and has been retained in every iteration up to 
the current RFC2822 revision work.   That means that it has gone through 
repeated review by the email standards community. Why in the world would it be 
appropriate for the DKIM working group to debate its legitimacy?

2. While it is certainly useful to prune obsolete constructs, it is dangerous 
to assume that what a particular segment of the community is familiar with is 
all that ought to be allowed.  Email is a very general-purpose tool for human 
communications.  Human communications is a very, very rich space.  Just 
because on or another person -- or lots of them -- do not use a feature does 
not mean its use can be ignored or denied.

When one standard is built on another, the new one acts to its own peril when 
it seeks to impose restrictions on the use of the base specification, 
especially when the restrictions are arbitrary.

d/
-- 

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

---

From: [email-masked]
Date: Mon, 21 Jan 2008 12:00:25 -0800 (PST)

> especially when the restrictions are arbitrary.

Emphatic +1 on all points.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Mon, 21 Jan 2008 15:52:46 -0500

Dave says...
> 1. Multiple From addresses are in the RFC2822 standard, folks. The 
> capability was defined in RFC 733 (1977) and has been retained in every 
> iteration up to the current RFC2822 revision work.   That means that it 
> has gone through repeated review by the email standards community. Why 
> in the world would it be appropriate for the DKIM working group to 
> debate its legitimacy?
> 
> 2. While it is certainly useful to prune obsolete constructs, it is 
> dangerous to assume that what a particular segment of the community is 
> familiar with is all that ought to be allowed.  Email is a very 
> general-purpose tool for human communications.  Human communications is 
> a very, very rich space.  Just because on or another person -- or lots 
> of them -- do not use a feature does not mean its use can be ignored or 
> denied.

Yeah.  I'm speaking here not as DKIM working group chair, nor as DKIM 
working group participant, but as a member of the IAB: in that capacity, 
I would look VERY skeptically at any attempt to say that DKIM doesn't 
have to support something that's in the RFC2822 standard, on the basis 
that either (1) "no one uses it" or (2) "it doesn't interoperate well in 
the first place".

I'm sympathetic to the idea that we'd like not to spend a lot of time on 
an aspect that's pretty much never going to show up... on a "corner 
case".  But saying that we can ignore that aspect is just not on.  I 
would hope that Lisa or Chris, or both, would send up a DISCUSS if that 
happened.

Barry

---

From: SM <[email-masked]>
Date: Mon, 21 Jan 2008 13:41:38 -0800

At 11:25 21-01-2008, Dave Crocker wrote:
>dangerous to assume that what a particular segment of the community 
>is familiar with is all that ought to be allowed.  Email is a very 
>general-purpose tool for human communications.  Human communications 
>is a very, very rich space.  Just because on or another person -- or 
>lots of them -- do not use a feature does not mean its use can be 
>ignored or denied.

Most people do not use the feature because either they don't know 
about it or because their MUA does not offer such features.  That's 
not a reason to question its legitimacy.  We might as well move RFC 
2369 to obsolete status because most people don't know about it.

Regards,
-sm

---

From: "J D Falk" <[email-masked]>
Date: Mon, 21 Jan 2008 18:09:25 -0500

Barry wrote (though not speaking as chair):

> I'm sympathetic to the idea that we'd like not to spend a lot of time
> on an aspect that's pretty much never going to show up... on a "corner
> case".

That's the main idea I was trying to convey, but it appears I utterly
failed.  Oh well.

Some day maybe I'll learn that geeks will always prefer to beat edge
cases into the ground, even when there are more important issues to deal
with.

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 22 Jan 2008 15:44:27 +0100

> Barry wrote (though not speaking as chair):

[...]
 
> Some day maybe I'll learn that geeks will always prefer
> to beat edge cases into the ground, even when there are
> more important issues to deal with.

When he wrote...

| I'm speaking here not as DKIM working group chair, nor as
| DKIM working group participant, but as a member of the IAB

...mentioning DISCUSS it was IMO no "geek-code" for "veto".

 Frank

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 22 Jan 2008 08:26:05 -0800

I think this whole discussion (and most on the list) come from a failure to consider DKIM in the context of a system.
 
There are two questions that you can answer with a DKIM like specification:
 
1) Is there an authentic claim of responsibility from a trustworthy party?
2) Is there an authentic claim of origin from an identified party?
 
A claim of responsibility is not the same as a claim of origin. If all you want to do is to whitelist email for spam control purposes you simply do not care if the signer of the email is the originating party in any sense (author, employer, etc.). The multiple from issues is irrelevant.
 
If you do care about authenticated origin the RFC 822 headers are frankly irrelevant. The only claim(s) of origin you care about are those that are authenticated. If you have multiple From and only one is authenticated then you are only going to tread that one as authenticated for purposes where you require authentication. If all the From addresses are authenticated then you are fine.

________________________________

From: [email-masked] on behalf of Barry Leiba
Sent: Mon 21/01/2008 3:52 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Seriously.

Dave says...

Barry

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 22 Jan 2008 12:21:09 -0500

>From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hallam-Baker,
Phillip
>Sent: Tuesday, January 22, 2008 11:26 AM
>To: Barry Leiba; [email-masked]
>Subject: RE: [ietf-dkim] Seriously.
>

>I think this whole discussion (and most on the list) come from a
failure to consider DKIM in the context of a system.
 
Agreed
 
>There are two questions that you can answer with a DKIM like
specification:
 
I would phrase the questions slightly differently
 
>1) Is there an authentic claim of responsibility from a trustworthy
party?
 
Can I authenticate a claim of responsibility from a party (that party
may or may not be trustworthy but I can authenticate they are making the
claim)?
 
>2) Is there an authentic claim of origin from an identified party?
 
Is the identified party the originator of the message and can I
authenticate them as such?
 
>A claim of responsibility is not the same as a claim of origin. If all
you want to do is to whitelist email for spam control 
>purposes you simply do not care if the signer of the email is the
originating party in any sense (author, employer, etc.). The multiple
from issues is irrelevant.
 
Agreed
 
>If you do care about authenticated origin the RFC 822 headers are
frankly irrelevant. The only claim(s) of origin you care
> about are those that are authenticated. If you have multiple From and
only one is 
>authenticated then you are only going
>to tread that one as authenticated for purposes where you require
authentication. If all the From addresses are 
>authenticated then you are fine.
 
Agreed except that the Sender field should not be used unless it is in
the same domain as (authenticated) From. 
 
Mike

	Dave says...
	> of them -- do not use a feature does not mean its use can be
ignored or
	
	Yeah.  I'm speaking here not as DKIM working group chair, nor as
DKIM
	working group participant, but as a member of the IAB: in that
capacity,
	I would look VERY skeptically at any attempt to say that DKIM
doesn't
	have to support something that's in the RFC2822 standard, on the
basis
	that either (1) "no one uses it" or (2) "it doesn't interoperate
well in
	the first place".
	
	I'm sympathetic to the idea that we'd like not to spend a lot of
time on
	an aspect that's pretty much never going to show up... on a
"corner
	case".  But saying that we can ignore that aspect is just not
on.  I
	would hope that Lisa or Chris, or both, would send up a DISCUSS
if that
	happened.
	
	Barry

---

From: "Siegel, Ellen" <[email-masked]>
Date: Tue, 22 Jan 2008 13:40:42 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of MH Michael Hammer (5304)
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
> Can I authenticate a claim of responsibility from a party (that party may 
> or may not be trustworthy but I can authenticate they are making the
> claim)?
 
> authenticate them as such?
 >> A claim of responsibility is not the same as a claim of origin. If all
 
>> authenticated then you are only going to tread that one as authenticated
>> for purposes where you require authentication. If all the From addresses
>> are authenticated then you are fine. 
> Agreed except that the Sender field should not be used unless it is in the
> same domain as (authenticated) From. 

If you have an authentic claim of responsibility from a trustworthy party (as per #1), why should it matter whether that party is represented by the From: header or the Sender: header? And why, if the authenticated party in the Sender: field is trustworthy, should it be required that the From: domain is authenticated directly?

This all seems counter to the idea that reputation is the real differentiator. You seem to be saying that a trustworthy, authenticated signature related to the Sender field is worthless, but any authenticated signature related to the From: field is goodness. Taking that to its logical conclusion, spam signed with a signature based on the bogus From: domain will be rated better than valid mail signed with a well-know, trusted 3rd party signature based on the Sender field.

Using SSP as a backup if your first-level reputation check yields uncertain results is one thing, but claiming that receivers should automatically be invoking it any time that a signature fails to match the originator domain (independently of the trust status of the existing signature) seems like it's potentially creating more problems than it's solving. 

Ellen

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Jan 2008 11:11:14 -0800

> would hope that Lisa or Chris, or both, would send up a DISCUSS if that 

This debate has all of the qualities of an academic debate: why is it
so vicious? because the stakes are so low. Seriously.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Jan 2008 11:22:06 -0800

> so vicious? because the stakes are so low. Seriously.

How was that posting helpful, Mike?

It's not as if you haven't already posted your feelings about the issue.  So 
what is the incremental contribution to the working group process in having 
such a message posted?

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Jan 2008 11:28:27 -0800

Dave Crocker wrote:
> It's not as if you haven't already posted your feelings about the 
> issue.  So what is the incremental contribution to the working group 
> process in having such a message posted?

Because perspective still seems to be on holiday.

Now justify your post's helpfulness.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Jan 2008 11:41:15 -0800

> Because perspective still seems to be on holiday.

Hmm, let's see.  Postings in this thread by quite a few different folk; more 
diverse than usual, I believe  That suggests that their/our perspective is 
that it is significant.

List of posters includes Leiba, me, Hammer, Hallam-Baker, Siegel, Finch.

So we all lack perspective and it's helpful to have you point that out?

d/

ps. as for why I am pursuing it, it is in the hope that a degree of 
professional civility might eventually be imposed on the list and that 
postings which tend to undermine that civility might occur with more restraint 
than has so far been the pattern.

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Jan 2008 12:24:13 -0800

Dave Crocker wrote:
> postings which tend to undermine that civility might occur with more 
> restraint than has so far been the pattern.

Who elected you the civility adjudicator? Last I heard that was the
chairs job. I'm really not interested in this meta argument.

Seriously.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Jan 2008 12:24:11 -0800

On Jan 22, 2008, at 10:40 AM, Siegel, Ellen wrote:

> ...
>>> The only claim(s) of origin you care about are those that are  
>>> authenticated. If you have multiple From and only one is  
>>> authenticated then you are only going to [treat] that one as  
>>> authenticated for purposes where you require authentication. If  
>>> all the From addresses are authenticated then you are fine.
>>
>> Agreed except that the Sender field should not be used unless it is  
>> in the same domain as (authenticated) From.
>
> If you have an authentic claim of responsibility from a trustworthy  
> party (as per #1), why should it matter whether that party is  
> represented by the From: header or the Sender: header? And why, if  
> the authenticated party in the Sender: field is trustworthy, should  
> it be required that the From: domain is authenticated directly?

The SSP requirements are for From headers since only From headers are  
assured to be included within the signature's hash.  When a valid  
unrestricted signature is by a domain above or at the From domain,  
this signature should meet "all" or "strict" compliance based upon  
 From headers.  The signature itself might be on-behalf-of the email- 
address within the Sender header.  IMHO, DKIM must not attempt to  
impose explicit authentication requirements of identities within a  
domain.

> This all seems counter to the idea that reputation is the real  
> differentiator. You seem to be saying that a trustworthy,  
> authenticated signature related to the Sender field is worthless,  
> but any authenticated signature related to the From: field is  
> goodness. Taking that to its logical conclusion, spam signed with a  
> signature based on the bogus From: domain will be rated better than  
> valid mail signed with a well-know, trusted 3rd party signature  
> based on the Sender field.

A trusted 3rd party signature can be handled in any manner a verifier  
deems appropriate, despite definitions for "strict".  However, SSP  
compliance should not impose requirements on the on-behalf-of feature  
of a DKIM signature.

> Using SSP as a backup if your first-level reputation check yields  
> uncertain results is one thing, but claiming that receivers should  
> automatically be invoking it any time that a signature fails to  
> match the originator domain (independently of the trust status of  
> the existing signature) seems like it's potentially creating more  
> problems than it's solving.

Agreed, but more than just asserting "all" email is signed is being  
attempted by SSP at this time.  Imposing requirements on a signature's  
on-behalf-of feature creates more problems that it solves.  A signing  
domain should be able to decide whether they wish to "authenticate"  
the identities of individuals.  The only exception might be for g=  
restricted keys, where the restricted signature's compliance should be  
limited to the From domain.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Jan 2008 12:35:58 -0800

> chairs job. I'm really not interested in this meta argument.

The idea that only a designated person may ask after the utility of your 
making a summary dismissal of an active thread with diverse (and serious) 
postings is somewhat interesting, but really only as a distraction.

In a group focused on accountability, it does seem ironic that you won't take 
seriously a query about your own.

d/

-- 

   Dave Crocker

---

From: [email-masked]
Date: Mon, 21 Jan 2008 17:30:49 -0800 (PST)

> cases into the ground, even when there are more important issues to deal

Then you've completely missed the point of several people's comments, my own
included. The problem in general is that one person's unimportant edge case may
well be an essential feature for some large group we are unaware exists. Or it
may not. There's just no way to know, and unless someone here has access to an
oracular fountain of some sort, no way to find out.

In the specific case of multivalued From: fields, we're not talking about an
obscure syntactic fillip like, say, the ability to stuff comments in random
places throughout a structured field. Such capbilities provide no consistently
meaningful additional semantics and are therefore not something it makes sense
to spend a lot of effort to support. But this is different: We're talking about
the mechanism the protocol provides to associate multiple authors with a
message. Given that messages can be and sometime are written by more than one
person the potential utility of this semantic is quite clear.

				Ned

---

From: SM <[email-masked]>
Date: Tue, 22 Jan 2008 15:00:42 -0800

>it be required that the From: domain is authenticated directly?

It doesn't matter if we trust that party but see example below.

If example.com is a bank and example.net is an ISP who is a 
trustworthy party, would you trust an email for which example.net 
claims responsibility if the From: shows an example.com author?

See RFC 5016, Section 3.2 (Problem Scenario 2: Illegitimate Domain Name Use).

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 23 Jan 2008 05:09:03 -0000

>claims responsibility if the From: shows an example.com author?

Of course.

> See RFC 5016, Section 3.2 (Problem Scenario 2: Illegitimate Domain

If your point is that RFC 5016 is a very flawed base on which to build
a useful protocol, I entirely agree.  I suspect that I'm not the only
person who now regrets ignoring it last summer.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Tue, 22 Jan 2008 23:06:01 -0800

> person the potential utility of this semantic is quite clear.

I would really love it if we could get past the meta-discussion of "is 
the multiple From: case important?" to the proposals that have been made 
to address the issue.  These include:

1. Perform SSP checks on the domains of all From addresses in the 
message, with the exception of addresses having valid Author 
Signatures.  If any of the checks result in a Non-Compliant (formerly 
Suspicious) result, then the message is considered Non-Compliant.

or

2. In the case of multiple From: addresses in the message, and the 
domain part of one of the addresses matches the domain part of the 
Sender address, then perform an SSP check on that address unless it has 
a valid Author Signature.  If the Sender header field does not match the 
domain of one of the from address or is missing [violating 2822], revert 
to alternative #1.

There are some other variations, but I think these are the two main 
proposals.

-Jim

---

From: Jon Callas <[email-masked]>
Date: Wed, 23 Jan 2008 02:22:50 -0800

> Signatures.  If any of the checks result in a Non-Compliant  
> (formerly Suspicious) result, then the message is considered Non- 
> Compliant.
>
> or
>
> Sender address, then perform an SSP check on that address unless it  
> has a valid Author Signature.  If the Sender header field does not  
> match the domain of one of the from address or is missing [violating  
> 2822], revert to alternative #1.
>

But there's also

3. Throw your hands up in the air and let non-DKIM software squint at  
the message.

	Jon

---

From: Jim Fenton <[email-masked]>
Date: Wed, 23 Jan 2008 06:56:19 -0800

> 3. Throw your hands up in the air and let non-DKIM software squint at 

I'm expecting that non-DKIM software will "squint at the message" 
anyway.  SSP is an input to that process.  By "Throw your hands up in 
the air," I gather you mean, "the result of the SSP check is 
indeterminate," and yes, that is an option too.  I don't think that's a 
very good option, because it means that an attacker can defeat SSP 
simply by adding an additional From address to a message.

-Jim

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 23 Jan 2008 06:55:11 -0800

What I am saying in case 1 is that all that matters is that you have an authenticated claim of responsibility from a party you consider to be trustworthy.
 
Whether that corresponds to the sender, from or any other header is irrelevant for the purposes of edeciding which mail gets passthrough and which gets sent to the filters. For example, say Google decides to sign all outbound mail sent through Postini. Google is not the sender, from or has anything else to do with the message other than they are saying that it complies with their rate limiting anti-spam control.

The from, sender etc do matter when the indicated party has a mail sending policy. In that case there is an affirmative statement out there 'reject all mail that purports to come from me that is not authenticated as comming from me'. Without a policy the from addresses are irrelevant in my view.

From: [email-masked] on behalf of Siegel, Ellen
Sent: Tue 22/01/2008 1:40 PM
To: MH Michael Hammer (5304); [email-masked]
Subject: RE: [ietf-dkim] Seriously.

 

Ellen

---

From: Jim Fenton <[email-masked]>
Date: Wed, 23 Jan 2008 07:12:00 -0800

> This all seems counter to the idea that reputation is the real differentiator. You seem to be saying that a trustworthy, authenticated signature related to the Sender field is worthless, but any au…

The SSP result is by no means the final judgment on a message; 
regardless of the SSP result, a recipient is free to ignore that and 
accept the message anyway.  But when you say things like "well-known" 
and "trusted" you're implying some sort of accreditation or reputation, 
even if that reputation is locally held (i.e., a white list).

SSP is about providing advice in the absence of sufficient trust to just 
accept/deliver the message.  How much is "sufficient" is up to the 
receiver, and may depend on the claimed author.

> Using SSP as a backup if your first-level reputation check yields uncertain results is one thing, but claiming that receivers should automatically be invoking it any time that a signature fails to…

This is a fair point.  We need some words that don't create a normative 
dependency on reputation and accreditation systems that are out of 
scope.  Suggestions welcomed.

-Jim

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 23 Jan 2008 10:45:23 -0500

I'mnot sure I'm comfortable with your explanation of case 1. You may or
may not consider the party you are authenticating as being trustworthy.
You may not even have enough information to make that decision. The
generic description of this case is that you have a claim of
responsibility from a party and you are authenticating (through the DKIM
query to DNS) that their signature does indeed match (or does not). 
 
If the signature matches then the trustworthiness of the party can be
considered.
 
With regard to the indicated party having a mail sending policy, I still
maintain that if the sender domain is not the same as the from domain
there is a significant issue and subsequent risk. Because there does not
have to be any trust relationship or authorization indicated by the From
address for the sender adddress, this leads to the potential for cross
domain attacks that would potentially degrade the effectiveness of DKIM
checking by receivers. This is very similar to an issue (one that I have
not seen commonly discussed) that exists for PRA (with regard to sender)
in SIDF. 
 
If there were a way for domain owners to indicate authorized 3rd party
signers (whether sender field or simply 3rd parties) through SSP, this
might be useful. That is, I sign my mail but if you receive mail signed
by (for example) smallbusiness._domainkey.constantcontact.com. IN TXT
and they sign it then that is ok too. 
 
Now we have a clear link between the from field domain authorizing mail
sent by sender field domain which is signed by sender field domain. Does
this address all sender cases? Absolutely not. Does it address some
potentially useful and significant ones.... possibly. Consider a
business which wishes to allow it's law firm to send and sign mail on
it's behalf. This is just a quick example but I thinkit illustrates the
point. We now have a confidence level that sender really is sending on
behalf of from.
 
Mike 

	From: Hallam-Baker, Phillip [mailto:[email-masked]] 
	Sent: Wednesday, January 23, 2008 9:55 AM
	To: Siegel, Ellen; MH Michael Hammer (5304);
[email-masked]
	Subject: RE: [ietf-dkim] Seriously.

	What I am saying in case 1 is that all that matters is that you
have an authenticated claim of responsibility from a party you consider
to be trustworthy.
	 
	Whether that corresponds to the sender, from or any other header
is irrelevant for the purposes of edeciding which mail gets passthrough
and which gets sent to the filters. For example, say Google decides to
sign all outbound mail sent through Postini. Google is not the sender,
from or has anything else to do with the message other than they are
saying that it complies with their rate limiting anti-spam control.

	The from, sender etc do matter when the indicated party has a
mail sending policy. In that case there is an affirmative statement out
there 'reject all mail that purports to come from me that is not
authenticated as comming from me'. Without a policy the from addresses
are irrelevant in my view.

	> From: [email-masked]
[mailto:[email-masked]] On Behalf Of MH Michael Hammer
(5304)

	> same domain as (authenticated) From.
	
	If you have an authentic claim of responsibility from a
trustworthy party (as per #1), why should it matter whether that party
is represented by the From: header or the Sender: header? And why, if
the authenticated party in the Sender: field is trustworthy, should it
be required that the From: domain is authenticated directly?
	
	This all seems counter to the idea that reputation is the real
differentiator. You seem to be saying that a trustworthy, authenticated
signature related to the Sender field is worthless, but any
authenticated signature related to the From: field is goodness. Taking
that to its logical conclusion, spam signed with a signature based on
the bogus From: domain will be rated better than valid mail signed with
a well-know, trusted 3rd party signature based on the Sender field.
	
	Using SSP as a backup if your first-level reputation check
yields uncertain results is one thing, but claiming that receivers
should automatically be invoking it any time that a signature fails to
match the originator domain (independently of the trust status of the
existing signature) seems like it's potentially creating more problems
than it's solving.
	
	Ellen

---

From: [email-masked]
Date: Wed, 23 Jan 2008 07:41:53 -0800 (PST)

> domain of one of the from address or is missing [violating 2822], revert

This is an interesting, even novel approach. I'm still trying to
evaluate it. One question I have is how it would interact with what
headers are covered by the author signature. In particular, does the
Sender: field in this case have to be covered by the signature?

> There are some other variations, but I think these are the two main

Agreed.

				Ned

---

From: Michael Thomas <[email-masked]>
Date: Wed, 23 Jan 2008 08:06:54 -0800

> Sender: field in this case have to be covered by the signature?

I would think it would, but I'm a little suspicious that this couldn't
be gamed:

original:

From: [email-masked]
Subject: Aunt Matilda's Recipes

spoof:

From: [email-masked],[email-masked]
Sender: fooledyou.com
Dkim-signature: d=fooledyou.com
Subject: New Larger Manpex!

The virtue of checking them all is that you wouldn't fall into this
cleverness, as well getting to ignore the issue that most people
writing software have no clue that there's any supposed connection
between From and Sender.

		Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Jan 2008 16:16:03 +0000

> Sender: field in this case have to be covered by the signature?

Good point. I'd like if we could keep that as a tracked issue, just
so's we remember to think about it.

S.

---

From: <[email-masked]>
Date: Wed, 23 Jan 2008 16:32:29 +0000

> From: [email-masked]

I think my answer would be that for this purpose the scope of trust we're discussing is VERY narrow. It is "Do I trust this party to sign mail on behalf of other domains?" , not  "Do I generally consider this domain trustworthy?". For the first question it is really unlikely that any ISP would meet that requirement for me given the fact that it would imply a level of control over their end users that would be very hard to meet. Even the best ISPs have to deal with people creating bogus accounts with stolen credit cards and customers whose accounts get compromised, and I am not aware of anyone who has come up with a completely effective way to proactively stop traffic from those accounts.

If ISPs were widely considered trusted third parties for purposes of signing mail I think it would pushd the need for more domains to express "strict" policies.

> See RFC 5016, Section 3.2 (Problem Scenario 2: Illegitimate Domain Name Use).

_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join

---

From: Jon Callas <[email-masked]>
Date: Wed, 23 Jan 2008 10:36:27 -0800

> anyway.  SSP is an input to that process.  By "Throw your hands up  
> in the air," I gather you mean, "the result of the SSP check is  
> indeterminate," and yes, that is an option too.  I don't think  
> that's a very good option, because it means that an attacker can  
> defeat SSP simply by adding an additional From address to a message.

That is indeed what I mean, and I agree that it is suboptimal.

However, if an attacker "defeats" SSP this way, but SpamAssassin adds  
three asterisks to the message because statistically, only an attacker  
would put two "From"s in a message, then all is good.

You're absolutely right, but if I as a sender know that multiple  
"From"s will gank SSP, then I won't do it on my important mailings.  
The very presence of multiple "From"s is an indication that this is a  
hacked message. No crypto, no DNS  is needed at all.

Yes, I know that multiple "From"s is a charming, somewhat useful  
feature that's a legal part of the email infrastructure. It would be  
sad for it to whither away. But as we have already seen, its  
reliability is dodgy (the test got to me just fine, using Mail.app).  
There are other legal parts of the email infrastructure that have  
withered away as well. (E.g. the syntax <user>@<tld> is legal. I  
happen to have an @AI forwarder that matches my old account on MIT-AI  
from the late '70s; most software incorrectly thinks that example@ai  
is not a legal email address.) There are parts that have withered away  
that in my opinion shouldn't have. (E.g. I still think that collapsing  
" at " into "@" was a mistake, but I'm like that.) Tough. Times  
change. Entropy happens. Embrace the suckiness.

SSP is an important, valuable, *optional* part of the email  
infrastructure. If SSP and multiple "From"s interact badly in ways we  
can't fix easily, then just put in a note that says so. Or put in a  
note that says that an evaluator MAY consider mulitple "From"s as a  
hack on SSP. State it in draftese.

	Jon

---

From: Michael Thomas <[email-masked]>
Date: Wed, 23 Jan 2008 10:38:30 -0800

> so's we remember to think about it.

FWIW, this is sort of the point of rfc5016, 5.3.2, though Ned has
definitely uncovered another aspect of it.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Jan 2008 10:42:33 -0800

Jim Fenton wrote:
> accept/deliver the message. 

Jim, that statement seems very much at odds with the current text and with the 
pattern of comments about it from supporters of the current text.

The current text makes no explicit statements about 'trust' and no statements 
about relative application of SSP.

The closest it comes is the implicit statement that if the From: domain does 
not equal the DKIM domain (i=, I guess) then you should be 'suspicious', which 
translates into 'have little trust'.

In other words, the model of the current specification is really to say that a 
receiver should mistrust a message that isn't signed by its author.

Everything in the language and direction of the0 current specification derives 
from this perspective.

> scope.  Suggestions welcomed.

If the specification is restricted to statements of the type "here is what I, 
an author domain, do, in case you a receiver find it useful to know" then 
these issues become greatly simplified.

d/
-- 

   Dave Crocker

---

From: Damon <[email-masked]>
Date: Wed, 23 Jan 2008 14:13:00 -0500

> these issues become greatly simplified.

Are you are saying- If the Sender domain does not appear in the Author
domain's SSP mark as suspicious?

Regards,
Damon

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 23 Jan 2008 20:27:24 +0100

Jon Callas wrote:

> E.g. the syntax <user>@<tld> is legal.

Not under RFC 2821 rules intentionally demanding 
"at least one dot" - to get rid of <user>@<host>
constructs, where <host> is no FQDN.

It will be however legal under 2821bis rules, if
the IESG can resist all temptations to overrule
John's decision.  Of course what's legal or not
isn't necessarily related to what happens if you
try to use a TLD as host in SMTP or NNTP. 

> most software incorrectly thinks that example@ai  
> is not a legal email address.

Maybe submit this observation to Dave's collection
of 2821 interoperabilty reports, folks on the SMTP
list had serious difficulties to figure out what's
best.  "Don't talk about it" was no option.

> I still think that collapsing " at " into "@" was
> a mistake, but I'm like that.

That gives you odd places where LWSP has to work,
it would immediately kill RFC 2822 and dozens of
RFCs built on the new 2822-concepts (excl. "obs").

That I consider deprecating reverse paths while
keeping 1123 5.3.6(a) as a serious mistake (and as
reason of the spam problem, not less) is also odd,
but I consider SPF as "good enough" to fix it. :-)

 Frank

---

From: "Siegel, Ellen" <[email-masked]>
Date: Wed, 23 Jan 2008 14:36:56 -0500

> -----Original Message-----
> From: Jim Fenton [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2008 10:12 AM
> To: Siegel, Ellen
> Cc: [email-masked]
represented
> by the From: header or the Sender: header? And why, if the
authenticated
> party in the Sender: field is trustworthy, should it be required that
the
> From: domain is authenticated directly?
> >
authenticated
> signature related to the Sender field is worthless, but any
authenticated
> signature related to the From: field is goodness. Taking that to its
> logical conclusion, spam signed with a signature based on the bogus
From:
> domain will be rated better than valid mail signed with a well-know,
> trusted 3rd party signature based on the Sender field.
> >
> 

I'm glad to hear you say this. I think you may be assuming that this is
self-evident to people reading and/or implementing the spec, but I'd
suggest that it's much less self-evident than you may believe. At a
minimum, I think that this intent should be made much more clear within
the spec itself. 

In fact, the following excerpt from the SSP spec seems to contradict
your statement above:

   In the absence of a valid DKIM signature on behalf of the "From"
   address [RFC2822], the verifier of a message MUST determine whether
   messages from that sender are expected to be signed, and what
   signatures are acceptable.

There's nothing here about "in the absence of sufficient trust to just
accept/deliver the message"... it's pretty clear that the check MUST be
made if there is no valid signature on behalf of the FROM address.

In addition, the following strongly implies that any signature from a
domain other than the Originator/From domain is inherently invalid:

   In contrast, this
   specification focuses on information which is relevant in the absence
   of a valid signature. 

I think it's important to make a clear distinction between a blanket
statement about validity of the signature, and a statement about whether
or not that signature conveys information about the policies of the
Originator domain. 

[Note too that legitimate services that send emails with From: domains
outside their control are generally very careful to establish through a
confirmation step that such addresses are under the control of the email
author, so there's also a distinction between the policies of the domain
owner and the policies of individual users within that domain.]

I'd also note that the text in Section 2.8 under Suspicious implies
again that signatures other than Valid Originator Signatures are invalid
under SSP. I realize that the clause is an e.g. and not an i.e., but it
would take a pretty careful reader to catch that distinction:

   Messages that do not contain a valid Originator Signature and which
   are inconsistent with a Sender Signing Practices check (e.g., are
   received without a Valid Signature and the sender's signing practices
   indicate all messages from the entity are signed) are referred to as
   "Suspicious".

And again, in Section 3:

   Verifiers checking messages that do not have at least one valid
   Originator Signature MUST perform a Sender Signing Practices check on
   the domain specified by the Originator Address as described in
   Section 4.4.

Seems to me that if you believe that reputation is primary and SSP is an
option available to verifiers who want to dig deeper, then many of these
MUSTs should become MAYs. The protocol should define how someone who
wants to perform the check can access and interpret the record, but it
should not be defining when they should make the check or what they
should be doing with the information they get back: those should both be
at the discretion of the receiver/verifier.

> automatically be invoking it any time that a signature fails to match
the
> originator domain (independently of the trust status of the existing
> signature) seems like it's potentially creating more problems than
it's
> solving.

Well, as above, I'd start by taking out directives as to when a verifier
MUST query the SSP record, and as to what it MUST do with the results.
It seems to me that that decision is wholly at the discretion of the
receiver/verifier, and should be keyed at least in part off of the
reputation that receiver assigns to any valid signatures that do exist.
I also don't think it's important to describe the source of that
reputation (i.e., it shouldn't be necessary to create a dependency on
any particular reputation/accreditation engine in order to make the
point).

Ellen

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 23 Jan 2008 15:10:53 -0500

Sorry for all the quoting but if I start snipping context and sense will
be lost. 

>[mailto:[email-masked]] On Behalf Of Siegel, Ellen
>Sent: Wednesday, January 23, 2008 2:37 PM
>To: Jim Fenton
>I'm glad to hear you say this. I think you may be assuming 
>that this is self-evident to people reading and/or 
>implementing the spec, but I'd suggest that it's much less 
>self-evident than you may believe. At a minimum, I think that 
>this intent should be made much more clear within the spec itself. 
>
>In fact, the following excerpt from the SSP spec seems to 
>contradict your statement above:
>
>There's nothing here about "in the absence of sufficient trust 
>to just accept/deliver the message"... it's pretty clear that 
>the check MUST be made if there is no valid signature on 
>behalf of the FROM address.
>

>From my reading, I would assert that it is logical that the check MUST
be made if there is no valid signature on behalf of the from address. To
do otherwise invites abuse. You may not abuse it in your case but others
certainly will in other cases.

>In addition, the following strongly implies that any signature 
>from a domain other than the Originator/From domain is 
>inherently invalid:
>
>   In contrast, this
>I think it's important to make a clear distinction between a 
>blanket statement about validity of the signature, and a 
>statement about whether or not that signature conveys 
>information about the policies of the Originator domain. 
>
>[Note too that legitimate services that send emails with From: 
>domains outside their control are generally very careful to 
>establish through a confirmation step that such addresses are 
>under the control of the email author, so there's also a 
>distinction between the policies of the domain owner and the 
>policies of individual users within that domain.]
>

With regard to your bracketed comment, if the issue were only legitimate
services then there wouldn't be a need for DKIM at all. Further, there
can be no distinction - as you assert - between the policies of the
domain owner and the policies of the individual account users within
that domain. In order for the concept of domain ownership and
administration to make sense, the use of the account by the account user
at any given domain has to be considered governed by the policies
(whether publicly asserted or not)of the domain owner. If the domain
owner asserts a policy, whether through DKIM, SPF or anything else, it
has to be presumed that any use outside that assertion is not done so
with the approval of the domain owner. A receiver may choose to ignore
the domain owners assertion but then again, a receiver may choose to do
wahtever they want regardless.

>
>I'd also note that the text in Section 2.8 under Suspicious 
>implies again that signatures other than Valid Originator 
>Signatures are invalid under SSP. I realize that the clause is 
>an e.g. and not an i.e., but it would take a pretty careful 
>reader to catch that distinction:
>
>Seems to me that if you believe that reputation is primary and 
>SSP is an option available to verifiers who want to dig 
>deeper, then many of these MUSTs should become MAYs. The 
>protocol should define how someone who wants to perform the 
>check can access and interpret the record, but it should not 
>be defining when they should make the check or what they 
>should be doing with the information they get back: those 
>should both be at the discretion of the receiver/verifier.
>
>

To say that receivers purporting to use DKIM don't have to perform a
check for SSP if there is not a valid originator signature guts the
whole notion of SSP. Why even have SSP if the expectation is that
receivers aren't going to check the purported originator if there is no
originator signature.

>Well, as above, I'd start by taking out directives as to when 
>a verifier MUST query the SSP record, and as to what it MUST 
>do with the results.
>It seems to me that that decision is wholly at the discretion 
>of the receiver/verifier, and should be keyed at least in part 
>off of the reputation that receiver assigns to any valid 
>signatures that do exist.
>I also don't think it's important to describe the source of 
>that reputation (i.e., it shouldn't be necessary to create a 
>dependency on any particular reputation/accreditation engine 
>in order to make the point).
>

So question for you Ellen - or anyone else (and not meant to be
snarky)..... If my company/organization chooses to assert that ALL email
sent from ag.com will be signed using DKIM and we use a strong assertion
for SPF (or anything else), are you really willing to argue that your
company should have the right to send mail purporting to be from ag.com
(in the From field) because an individual approached you to mail for
them? What if my company does it for their well known brands (which we
are working on now)? I would think that you would want to check the
policy assertions of the domain in question before you even attempt to
send on behalf of that address.

In the absence of an assertion (through whatever means, including SSP)
by a domain owner then I see no conflict with a 3rd party
sending/signing for an individual account user. In the event of a domain
making a strong assertion per the standard it would be foolish of the
standard not to require receivers to make such a check. To do otherwise
defeats the notion of a strong/strict assertion.

Mike

---

From: John Levine <[email-masked]>
Date: 23 Jan 2008 21:06:17 -0000

>From my reading, I would assert that it is logical that the check
>MUST be made if there is no valid signature on behalf of the from
>address. To do otherwise invites abuse.

Why?  Nobody I know is saying that any signature gives a message a
free pass, but if it's signed by someone you have reason to trust,
why aren't you done?  Could you give us a step-by-step example of
the abuse you're anticipating?

Assume that the signature is from someone you've known and trusted for
20 years, and you've never heard of the From: domain before.

R's,
John

---

From: Jon Callas <[email-masked]>
Date: Wed, 23 Jan 2008 13:06:54 -0800

> but I consider SPF as "good enough" to fix it. :-)

This sounds like a digression, but I don't think it is.

Email is a delightfully baroque thing, and some things fade into and  
out of common use. An address of example@tld was legal, isn't, and  
will be. But if Outlook 2^n-1 doesn't support it, it almost doesn't  
matter if it's legal.

My love of " at " is purely aesthetic, and a horse that's been dead  
for a quarter-century, no matter how much I miss it and would cheer  
its resurrection.

Multiple-from is another feature that's known to be dodgy. I have no  
emotional attachment to it, but I empathize with those that do. It  
would be nice to make it and SSP play well together.

Let me wave a magic wand and create an okay-but-not-great solution. I  
would *still* recommend to all high-risk-phish targets that they  
*never* use multiple-from. I would recommend to a filtering agent to  
look askance at it. I believe that an real-world Bayesean filter would  
correlate multiple-from with misuse for the simple reason that there  
are so few legitimate users.

So here's my magic wand: make an SSP option that says, signall 
+multiplefrom. In other words, it says that I sign all, and it's okay  
to have a multiple-from. Without that modifer, there will be no  
multiple-froms.

If you don't like this, tweak the multiplefrom modifier to singlefrom,  
change defaults or anything else.

	Jon

---

From: Hector Santos <[email-masked]>
Date: Wed, 23 Jan 2008 16:07:27 -0500

> send on behalf of that address.

I've been making this point.  If you are going to be sending mail on 
behalf of others, you better make sure the domain in question is 
prepared to allowed 3rd party signatures.

> defeats the notion of a strong/strict assertion.

Thank you.

There were various proposals which allowed a receiver to lookup the SSP 
and determine which 3rd party domains where allowed to sign on its behalf.

However, I believe, the concern was that it did not scale well, i.e., 
how large can be 3PS list be in the SSP record?

I always felt this is going to be required.

-- 
Sincerely

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jan 2008 14:32:35 -0800

On Jan 23, 2008, at 1:06 PM, Jon Callas wrote:

> +multiplefrom. In other words, it says that I sign all, and it's  
> okay to have a multiple-from. Without that modifer, there will be no  
> multiple-froms.
>
> If you don't like this, tweak the multiplefrom modifier to  
> singlefrom, change defaults or anything else.

Jon,

The multiple From email-address issue can not be resolved using an SSP  
assertion.  When N number of email-address domains are considered by a  
verifier to be too many for the SSP discovery process, the SSP process  
must conclude with the message then failing SSP compliance.  A  
reasonable minimum for the maximum number of domains that should  
receive SSP discovery must be established by the SSP specification.   
Would anyone have problems with a setting where the minimum maximum is  
4?   Although a simple problem to solve, this would establish a limit  
for all other types of email.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jan 2008 14:48:18 -0800

On Jan 23, 2008, at 1:07 PM, Hector Santos wrote:

> There were various proposals which allowed a receiver to lookup the  
> SSP and determine which 3rd party domains where allowed to sign on  
> its behalf.
>
> However, I believe, the concern was that it did not scale well,  
> i.e., how large can be 3PS list be in the SSP record?

Hector,

Please review the SSP extension for third-party authorization:

http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-02.txt

The TPA-SSP technique easily scales and can include _every_ major  
legitimate MTA known to exist within the entire world!  Confirmation  
of authorization requires a single small DNS transaction.  This  
technique can resolve DSN issues for third-party domains as well.

TPA-SSP offers a significant security improvement over other  
delegation techniques.  Provider MTAs would not need to warehouse  
their customer's private keys, accept the delegation of their  
customer's domain, or maintain CNAME relationships with published keys  
in conjunction with the use of different selectors.  Management of TPA- 
SSP authorizations can be handled autonomously as well without  
impacting the normal operation of the MTA.

-Doug

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 23 Jan 2008 17:53:10 -0500

>From: John Levine [mailto:[email-masked]] 
>Sent: Wednesday, January 23, 2008 4:06 PM
>Cc: MH Michael Hammer (5304)
>Subject: Re: [ietf-dkim] the more reliable signature fallacy
>
>>be made if there is no valid signature on behalf of the from address. 
>>To do otherwise invites abuse.
>
>Why?  Nobody I know is saying that any signature gives a 
>message a free pass, but if it's signed by someone you have 
>reason to trust, why aren't you done?  Could you give us a 
>step-by-step example of the abuse you're anticipating?
>
>Assume that the signature is from someone you've known and 
>trusted for 20 years, and you've never heard of the From: 
>domain before.
>

Your last point is an artificial construct. Remember, the discussion is
about Sender signing vs From Signing. Is your trusted friend signing as
sender or simply appending their signature? Is this a general case? Is
it even a likely case? In what case would your friend be signing as
sender if the From domain owner has not signed and their SSP says that
they always sign their email?

Moving on to my example, the first step is for us to create a matrix of
use cases along the lines of:

>From  |Sender|  Trusted    Neutral Untrusted   No SSP
-----

Trusted

Neutral

Untrusted

No SSP

We can add whatever additional variations we choose but for discussion
purposes a 4x4 matrix is sufficient. In reality it's more complex
because we have to account for whether or not there is a signature at
all for particular cases. I'm only going to discuss two cases...The one
you set up and the one I will set up. I'm going to assert that the one I
set up is more likely to be faced by receivers if "Must check" is
dropped.

The example you set up is an easy but unlikely one as far as I can see.
Your answer would be "Who's your friend?" You would likely accept it
because your friend signed it. My answer would be "Friends don't sign in
weird circumstances if they are truly friends." They might forward the
email. They might sign if there is no SSP for the From domain. I find it
an odd case that someone would be signing as sender if the origin domain
did not and it's SSP says everything is signed. I'll grant you that
there might be some confusion and poor implementation leading to your
example as SSP and DKIM are deployed.

As I pointed out above, I view your example as highly unlikely.

What about the case where SSP for From says everything is signed? If
>From isn't signed and Sender is signed, then unless you require an SSP
Check for From you can only rely on Sender. I'm going to guess that you
would respond that Sender would acquire a poor reputation if they signed
for spammy malicious email. Now what if (those evil ne'er-do-wells
really can get creative) the bad guy simply uses a new sender domain for
each email sent (or each 5 or 10, whatever works for them). This
effectively allows abuse of the From domain unless there is a mandatory
check of the From domain. You might respond that the IP address of the
sending machine would acquire a poor reputation...but that isn't DKIM
and is beyond the scope of the discussion (as a solution).

This is the exact problem for PRA in the SIDF implementation. Because
the specification mandates the use of Sender as PRA if Sender is present
and excludes checking From, it invites abuse cases that are perfectly
allowable within the terms of the specification. I'm not looking to bash
the folks that came up with the PRA algorithm. There's been plenty of
nit-picking and arguing over other issues but I haven't seen any
detailed published analysis of this particular issue. I've gone through
and sent all sorts of test emails to various receivers that implement
SIDF. It is a problem in the RFC and not an implementation issue.

There is a real quick simple way to test what I am saying. Construct an
email purporting to be from thatsgross.com (that is, the From field is
[email-masked]). Send it from a machine (using the sender
field) that uses some other domain and publishes a SPF2.0/PRA record for
that domain that authorizes that host to send. The email should (and
will) pass an implementation of SIDF that conforms to the
(experimental)standard. 

The domain thatsgross.com simply has a -all record for both spf1 and
spf2.0. 

The actual records returned are:

thatsgross.com  text = "v=spf2.0/pra -all"
thatsgross.com  text = "v=spf1 -all"

Any mail purporting to be from that domain SHOULD FAIL a check. But SIDF
specifically says that if Sender is present then that is PRA and you
don't check anything else. 

If the decision is that people don't have to check SSP (drop MUST and
insert MAY) for from domain then it is setting up the same sort of
situation that currently exists for PRA. If we want to protect domains
(and the account users that must adhere to the policies of the domains
that provide them accounts) it is imperative to require a check for the
originating domain. 

If all of the From addresses are within a domain then there shouldn't be
a problem. If the From addresses are from multiple domains then my
inclination is to say that all From domain policies (SSP) need to be
considered for making a determination. In reality I'm sure - as others
have pointed out - that there is a practical limit to how many will be
checked. I've dealt with millions of emails and don't see many that have
multiple Froms. I don't remember (off the top of my head) seeing any
with lots of froms. It may be allowed but it doesn't really happen in
practice.

Mike

---

From: "J D Falk" <[email-masked]>
Date: Wed, 23 Jan 2008 18:28:25 -0500

Jon Callas wrote:

> infrastructure.

This is a very important point.  When the draft says "MUST," an
experienced i-d reader will know that it actually means "x must do y in
order to comply with this specification."  That's not so obvious for
other humans, especially when pretty much all of the conversation on
this list also has the inherent assumption that SSP will be everywhere
for everybody.

There will be entirely valid use cases for which SSP will not be useful,
and may even be damaging.  Ellen's is one of these: she's probably going
to have to change her entire business model as SSP adoption grows.  In
our discussions -- especially with people who aren't fluent in the
ancient & dusty IETF vernacular -- we MUST remember that SSP will never
and can never be any stronger than a SHOULD.

--
J.D. Falk
Receiver Products
Return Path

---

From: Michael Thomas <[email-masked]>
Date: Wed, 23 Jan 2008 15:47:04 -0800

> and can never be any stronger than a SHOULD.

Actually, I don't think that Ellen's business model needs to change
all that much: she needs to have her customers delegate her a selector
so that she can sign on their behalf. Or not, as SSP's applicability is
relatively narrow, so it's not going to be any time soon that most
people get to all and/or strict which in the mean time dkim signatures
linked with reputation ought to take on its own life.

		Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 23 Jan 2008 19:24:20 -0500

> and can never be any stronger than a SHOULD.

-1 for all the same reasons discussed over the last 2+ years.

Ellen is no special case than any other 3rd party system we
have debated over and over and over again for the past 2.5 + years.

If Ellen or similar business wants to get into the DKIM signing 
business, then when her service verifies the new user's domain, it needs 
to include SSP checking for restrictive policies during the signup 
process.  Otherwise, she is abusing the Domain's protection.  Thats part 
of the issue today - forging.

Same is going to have to be true for public Mailing List Services or any 
other ESP who offers free or fee-based email support and wants to get 
into the signing business.

And that includes high-commodity domains like banks sending signed mail 
to their users.  If they do this blindly, they are not helping 
themselves nor the user.

I don't see any of this as negatives and its actually a rather simple 
concept.  The question is whether it is feasible to do so and how it can 
optimized.

It has been my opinion, DKIM/SSP real benefits are with restrictive 
polices. The loose ones will continue to exhibit themselves 
problematically just like it does today with relaxed policies in SMTP 
and sure, there are ones who probably are not capable of using it.

But I don't think Ellen's business is one of those.

During the Ellen's user signup process:

   - If user's DOMAIN has no SSP,

        - Ellen can sign as a 3rd party, or
        - Choose not to sign

   - If user's DOMAIN has a SSP

      DKIM=UNKNOWN

        - Ellen can sign as a 3rd party, or
        - Choose not to sign

      DKIM=ALL

        - Ellen MUST sign as a 3rd party.

      DKIM=STRICT

        - Ellen MUST NOT allow this user to use her services.

Very consistent logic. Very simple.  The worst case, she will filtering 
out restrictive policies.  Her business can only with with non the 
non-restrictive.

Thats good in my opinion.  I would go on to suggest, the majority of the 
world wants the level of security.

Again, the question is one of feasibility.  I don't see a problem with this.

-- 
Sincerely

Hector Santos, CTO

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 23 Jan 2008 18:33:46 -0600

> There's nothing here about "in the absence of sufficient 
> trust to just accept/deliver the message"... it's pretty 
> clear that the check MUST be made if there is no valid 
> signature on behalf of the FROM address.

IMO, the SSP spec appropriately speaks to what must be done when SSP is used.  In cases where you decide not to use SSP you are naturally not bound by any of it's requirements.  It would seem odd to me if we added text along the lines of "If you're not planning to employ this spec then you can ignore what it says" as I believe that is a given and I've not seen it in other specs but I could be wrong.

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Jan 2008 16:36:54 -0800

Michael Thomas wrote:
> so that she can sign on their behalf. 

There's quite a bit of history in pursuing that alternative.  It's viable in 
some cases and infeasible in others.

While it makes sense to have the delegation, if the agent is intended to get 
the mail delivered based on the reputation of the author, it does not make 
sense if the reputation of the agent is relevant.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Jan 2008 16:39:01 -0800

JD,

1. Yes, folks often forget that the premise to a standard is "IF you embrace 
this standard, THEN various normative assertions apply.  IF you do not, then 
they do not."  So all the musting and shoulding are strictly in the context of 
those who have chosen to adopt the specification.

2. Your second point says that there should be an 'applicability statement' 
for SSP, to clarify the scenarios in which it makes sense to use and the ones 
it does not.

d/

-- 

   Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 23 Jan 2008 18:44:24 -0600

> so's we remember to think about it.

One question I have is this:  do we need the added algorithmic 
complexity of this Sender: match check?   If it can't solve all cases in 
which multiple addresses in From: exist then maybe it's not worth the 
extra effort to spec out and code for?  In other words, since 
implementations can't get away from a "check all From domains" 
sub-routine anyway then adding extra code for a Sender: match along with 
a check to make sure Sender was covered by the signature just seems like 
extra work for the implementor?

Something to think about anyway.

Arvel

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 24 Jan 2008 01:50:22 +0100

Arvel Hathcock wrote:
 
> IMO, the SSP spec appropriately speaks to what must be done when SSP is
> used.  In cases where you decide not to use SSP you are naturally not
> bound by any of it's requirements.  It would seem odd to me if we added
> text along the lines of "If you're not planning to employ this spec then
> you can ignore what it says" as I believe that is a given and I've not
> seen it in other specs but I could be wrong.

+1  

But no problem to mention it in the spec. if it helps to close an issue.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 23 Jan 2008 17:00:47 -0800

> Something to think about anyway.

Yeah, that's what I'm worried about too. Especially in light of
implementations that don't obey this From: Sender: correlation
which may well be a common misimplementation.

		Mike

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 24 Jan 2008 02:03:43 +0100

Arvel Hathcock wrote:

> complexity of this Sender: match check?

It was supposed to be better than "first author", and IMO it is.

If we now go for "all authors" (up to a limit) it doesn't help
to pick a "better than the first" author.  We could add Sender
to the list of "author domains" for cases where the Sender is
not one of the authors, just because it's SSP and no "ASP" (?)

 Frank

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 23 Jan 2008 20:11:36 -0500

On Wednesday 23 January 2008 19:39, Dave Crocker wrote:

> 1. Yes, folks often forget that the premise to a standard is "IF you
> embrace this standard, THEN various normative assertions apply.  IF you do
> not, then they do not."  So all the musting and shoulding are strictly in
> the context of those who have chosen to adopt the specification.
>
> for SSP, to clarify the scenarios in which it makes sense to use and the
> ones it does not.
>

I think he said there will be cases where it's not useful.  I don't seen 
anything in that statement where he says we should engineer out exactly what 
those cases are.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 23 Jan 2008 20:28:14 -0500

Dave Crocker wrote:
> JD,
> 
> 2. Your second point says that there should be an 'applicability 
> statement' for SSP, to clarify the scenarios in which it makes sense to 
> use and the ones it does not.

I'm sorry, but this is getting ridiculous.  Can we stop this madness 
already!?  Its like you don't listen to anyone or ignore everything that 
is been stated and written in 5016 and you keep on trying to find some 
reason, or keep trying to make it a controversy, to convince everyone 
that SSP is "BAD" and they should use REPUTATION services instead.

We already been through this and there are clear stated REAL WORLD 
scenarios where PEOPLE want certain (restrictive) policies over others.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jan 2008 17:34:09 -0800

On Jan 23, 2008, at 4:36 PM, Dave Crocker wrote:
>> all that much: she needs to have her customers delegate her a  
>> selector so that she can sign on their behalf.
>
> There's quite a bit of history in pursuing that alternative.  It's  
> viable in some cases and infeasible in others.
>
> While it makes sense to have the delegation, if the agent is  
> intended to get the mail delivered based on the reputation of the  
> author, it does not make sense if the reputation of the agent is  
> relevant.

Agreed.  Efforts establishing a domain delegation or maintaining  
customers' keys and selectors may greatly impede acceptance from a  
business perspective.  Security breaches of providers holding many  
customer keys may further impede DKIM acceptance when wrong domains  
are accused of signing abusive messages.  TPA-SSP offers a solution  
that benefits delivery with the reputation of either party, ensures  
forensics will locate the culpable or compromised domain, without  
altering normal DKIM signing operations.

-Doug

---

From: "John L" <[email-masked]>
Date: 23 Jan 2008 20:48:36 -0500

> they always sign their email?

Well, after a few seconds of contemplation, the obvious examples are 
mailing lists like this one and courtesy forwards that replace the Sender: 
or reformat the message a little, but if I thought more, I'm sure I could 
come up with dozens of others.

> As I pointed out above, I view your example as highly unlikely.

Yes, you made that clear.  I suppose your analysis would be useful in a 
world without mailing lists or forwarders, but I don't see much relevance 
to this one.

R's,
John

PS:

> This is the exact problem for PRA in the SIDF implementation.

Quite right.  What would be the point in inventing yet another 
authentication scheme that fails in all the same places that SIDF and SPF 
do?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jan 2008 18:03:21 -0800

On Jan 23, 2008, at 5:03 PM, Frank Ellermann wrote:

> If we now go for "all authors" (up to a limit) it doesn't help to  
> pick a "better than the first" author.  We could add Sender to the  
> list of "author domains" for cases where the Sender is not one of  
> the authors, just because it's SSP and no "ASP" (?)

Agreed; a From email-address minimum maximum must be defined.   
However, policy discovery for the Sender header is not needed.

With the exception of those signed using g= restricted keys, when the  
d= domain of the signature on-behalf-of the Sender's or any other  
header's email-address is at or above the domain the of From email- 
address, the message is "strict" and "all" complaint.  By limiting  
compliance to a comparison of email-address and signatures domains  
(the d= domain parameter), it does not matter which header a signature  
is on-behalf-of.  This mode of comparison establishes compliance  
without needing to discover SSP.  Any From email-address will be  
contained within the signature's hash, as should the header being  
signed on-behalf-of.  A signature by an unrestricted key SHALL  
indicate the message is complaint with the policy established by the  
signing domain.  Verifiers should not be expected to second guess  
whether such messages are complaint regardless of _any_ SSP assertions.

In the case of the g= restricted keys, unless signed on-behalf-of the  
 From email-address, SSP must be checked when a From domain signature  
is otherwise lacking.  When an assertion of "all" or "strict" has been  
found, these messages should be considered to have failed SSP  
compliance.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Jan 2008 18:17:29 -0800

John L wrote:
> authentication scheme that fails in all the same places that SIDF and 
> SPF do?

+1

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Wed, 23 Jan 2008 22:11:15 -0800

> Sender: field in this case have to be covered by the signature?

It might need to be, but I have a bigger concern about alternative 2.  
The Sender address and From address(es) have different meanings.  Just 
because a particular author happens to be the sender of the message, 
should that affect which domains' signing policies apply?  I can't see 
why it should, which is why I favor alternative 1 given that we're not 
going to do something arbitrary in the multiple-From case.

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 24 Jan 2008 13:23:09 +0100

> authentication scheme that fails in all the same places that
> SIDF and SPF do?

SPF has no problem with non-standard mailing list behaviour, it
doesn't look at (2)822 header fields From / Sender / Resent-*.

SSP looks at the header, unsurprisingly running into known PRA-
difficulties.  A public statement (SSP) about how From-addresses
are used *must* be cumbersome for legit e-mail uses not under
the control of the publisher (mailing lists, secy-at-shost, 
resend, multi-author above a limit decreed here, likely more).  

Not the same set of issues as for SPF, SPF "only" outlaws 1123
5.3.6(a) forwarding.  SSP might end up with outlawing more mail
features, and SSP can't claim that they were "always wrong".

 Frank

---

From: [email-masked] (Wietse Venema)
Date: Thu, 24 Jan 2008 09:18:23 -0500 (EST)

> doesn't look at (2)822 header fields From / Sender / Resent-*.

If you replace (Client IP Address) by (Valid DKIM Signature) then
the similarity between SPF and SSP can be quite striking.

Extreme application of SPF results in the rejection of mail that
does not come from the "right" Client IP Address.

Extreme application of SSP results in the rejection of mail that
does not come with the "right" Valid DKIM Signature.

It's really the same thing, at different layer in the OSI stack.

Or is it?

If all SSP were doing was to re-invent SPF at a different OSI
layer, then no progress would be made; we would only squander the
opportunity for better accountability that DKIM makes possible.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jan 2008 06:46:38 -0800

> opportunity for better accountability that DKIM makes possible.

Maybe. But maybe not. With SPF you had the lure of doing all of your
work at the 2821 layer. That is, reject things before you've read the
message. With SSP you have to read the message so you might as well
run SSP and the rest of your filtering and just incorporate SSP as
*one* datapoint of potentially many to determine the delivery
disposition. This seems a lot more sensible and prudent to me as
you're not elevating SSP to Silver Bullet status which is always
suspect.

		Mike

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 24 Jan 2008 16:39:14 +0100

Michael Thomas wrote:
 
> With SPF you had the lure of doing all of your work at the 2821
> layer. That is, reject things before you've read the message.

Receivers can read the DATA and still reject a "FAIL", for SSP,
SPF, and PRA.  Better than the lure to accept mails on probation,
a receiver deciding that it's "likely" spam post-SMTP is trapped:

Bouncing is bad, but dropping is also bad (for false positives).
Bouncing is okay for an SPF PASS, re-enforcing the way how SMTP
was designed in RFC 821.  On the other hand SSP is a new concept:

Many users won't like it if they can't use "their" From-address
in places where it used to be okay before SSP restricted it, and
other users might be also surprised if "resend" requires to keep
the DKIM-signature valid for an SSP-protected From-address.  

I'd consider a MUA as broken if it breaks an existing signature
for resent mail, but I can't judge how realistic my expectation
is - for starters I never used a MUA supporting to resend mails.

> This seems a lot more sensible and prudent to me as you're not
> elevating SSP to Silver Bullet status which is always suspect.

When receivers drop false positives they might find themselves
looking for a "prudent and sensible" court of justice.  No SSP
problem, rejecting "suspicious" (non-compliant) mails is okay.

 Frank

---

From: "Siegel, Ellen" <[email-masked]>
Date: Thu, 24 Jan 2008 10:38:16 -0500

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Dave Crocker
> Sent: Wednesday, January 23, 2008 7:39 PM
> To: J D Falk
> Subject: Re: [ietf-dkim] Srsly.
> 
> JD,
> 
> embrace
> this standard, THEN various normative assertions apply.  IF you do
not,
> then

I still think there's a strong likelihood that receivers will choose to
use SSP selectively, i.e. to apply it only if their first level
reputation check on an existing signature does not meet their threshold.
In this case, the MUST is still ambiguous... they may have embraced the
standard for certain cases but not for others. The spec seems to imply,
by using MUST in certain cases, that it is an all or nothing
proposition.

> statement'
> ones

This would be a very useful addition. 

Ellen

---

From: "J D Falk" <[email-masked]>
Date: Thu, 24 Jan 2008 13:09:46 -0500

> reputation check on an existing signature does not meet their
threshold.

Why would anyone choose to accept and process a message when, as far as
anyone can tell, the owner of the domain wants it to be rejected?

ISPs aren't going to reclassify a message from "should be rejected" to
"deliver to inbox" on a whim.

--
J.D. Falk
Receiver Products
Return Path

---

From: Steve Atkins <[email-masked]>
Date: Thu, 24 Jan 2008 10:15:09 -0800

> "deliver to inbox" on a whim.

Sure they are.

ISPs are responsible to their customers, not the senders. They should,
and usually will, do what will make their customers happy.

As a concrete example, if the mail is coming from a known forwarder
(eg acm.org) or mailing list provider. Somewhere that is known to the
recipient ISP to not be a source of unwanted mail, and which may break
DKIM signatures. Most SSP fails in those cases will lead to rejection
of mail that is wanted by the recipient. Any responsible ISP will not
want to reject mail that is wanted by the recipient.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Jan 2008 10:48:12 -0800

On Jan 23, 2008, at 10:11 PM, Jim Fenton wrote:

> Ned Freed wrote:
>>> I would really love it if we could get past the meta-discussion of  
>>> "is the multiple From: case important?" to the proposals that have  
>>> been made to address the issue.  These include:
>>>
>>> Sender address, then perform an SSP check on that address unless  
>>> it has a valid Author Signature.  If the Sender header field does  
>>> not match the domain of one of the from address or is missing  
>>> [violating 2822], revert to alternative #1.
>>
>> headers are covered by the author signature. In particular, does  
>> the Sender: field in this case have to be covered by the signature?
>
> It might need to be, but I have a bigger concern about alternative  
> 2.  The Sender address and From address(es) have different  
> meanings.  Just because a particular author happens to be the sender  
> of the message, should that affect which domains' signing policies  
> apply?  I can't see why it should, which is why I favor alternative  
> 1 given that we're not going to do something arbitrary in the  
> multiple-From case.

Jim,

The Author's email-address is not contained within the Sender header.   
When a message is not complaint with policy, the signing domain MUST  
NOT apply their signature.  SSP confirms the policy of the signing  
domain when policy is not already apparent via their signature.  SSP  
is not about the policy or identity of the author as you seem to  
suggest.

Ned accurately said when a signing domain is also authoritative for  
 From address domain in question, then this email-address can be  
considered signed as well.  The signature's hash for some identity  
within the signature's domain MUST include all From email-addresses.   
When the signature's domain is authoritative for the From's email- 
address's domain, (unless by a g= restricted key) the message MUST BE  
assumed to meet the signing domain's policies.

There are some concerns this conclusion creates:

1) Is the header containing the matching identity included within the  
signature's hash?

2) When a header contains a matching identity not contained within the  
signature's hash:

a) this message should be considered SSP non-compliant (rejected)

b) require caution when displaying information not included within the  
signature's hash

c) both a and b

3) Must a signature's matching identity be found within either a From  
or Sender header?

DKIM is not about identifying the identity of the Author or that of  
the entity introducing the message as denoted by From, Sender, or  
Resent-* headers.  The identity included within a signature is not  
relevant with respect to signing policy.  Any display of signed  
identities must ensure any additional information based upon the  
identity parameter (i=) must also be included within the signature's  
hash.

RFC 4871 has some dangerous gaps within the specification.  A g=  
restricted key can be used to sign on-behalf-of any header.  The  
identity contained within the signature might match that of some  
header, however this header is not required to have been included  
within the signature's hash.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 24 Jan 2008 11:54:00 -0800

Douglas Otis wrote:
>>>> (formerly Suspicious) result, then the message is considered 
>>>> Non-Compliant.
>>>>
>>>> or
>>>>
>>>> match the domain of one of the from address or is missing 
>> 2.  The Sender address and From address(es) have different meanings.  
>> Just because a particular author happens to be the sender of the 
>> message, should that affect which domains' signing policies apply?  I 
>> can't see why it should, which is why I favor alternative 1 given 
>> that we're not going to do something arbitrary in the multiple-From 
>> case.
>
> Jim,
>
> is not about the policy or identity of the author as you seem to suggest.
First two sentences:  Agree
Second two sentences:  Disagree strongly.  Policy associated with a 
valid signature more properly belongs in the key-record (selector) 
referenced in the signature (example:  acceptable hash algorithms).  SSP 
has to do with messages lacking, potentially, any valid signature at 
all, and the author domain(s) is/are used as the key to retrieve SSP 
from it/them.
> When the signature's domain is authoritative for the From's 
> email-address's domain, (unless by a g= restricted key) the message 
> MUST BE assumed to meet the signing domain's policies.

My concern has to do with whether the SSP of the other From (author) 
domains has to be considered as well.  Just as the point has been made 
that it's not proper to handle this case by arbitrarily picking the 
first From domain, I believe that it's also not proper to use Sender for 
this purpose.  Given that belief, the question of whether Sender is 
signed or not is moot.

> within the signature's hash.

There was language in earlier versions of the dkim-base draft, "any 
header field that describes the role of the signer...MUST also be 
included" but that text was removed by WG consensus.  I don't consider 
this to be a dangerous gap, however.  RFC 4871 describes the process for 
constructing and verifying DKIM signatures; the context for what valid 
signatures are useful for what purposes lies outside that scope.

-Jim

---

From: Damon <[email-masked]>
Date: Thu, 24 Jan 2008 15:13:44 -0500

> this purpose.  Given that belief, the question of whether Sender is

In the case of multiple from: addresses, wouldn't promoting (maybe
this is the wrong word) the from address(es) of the signing domain to
author resolve this?

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Jan 2008 14:39:11 -0800

On Jan 24, 2008, at 11:54 AM, Jim Fenton wrote:

> Douglas Otis wrote:
>>
>> The Author's email-address is not contained within the Sender  
>> header.  When a message is not complaint with policy, the signing  
>> domain MUST NOT apply their signature.
>> SSP confirms the policy of the signing domain when policy is not  
>> already apparent via their signature.  SSP is not about the policy  
>> or identity of the author as you seem to suggest.
>
> Second two sentences:  Disagree strongly.
> Policy associated with a valid signature more properly belongs in  
> the key-record (selector) referenced in the signature (example:   
> acceptable hash algorithms).

Strongly disagree.  By applying the concept that a signing domain MUST  
confirm policy compliance prior signing, a signature on-behalf-of an  
identity within their domain permits an assumption of policy  
compliance for all other identities also encompassed by the signing  
key's g= and t= parameters.

> SSP has to do with messages lacking, potentially, any valid  
> signature at all, and the author domain(s) is/are used as the key to  
> retrieve SSP from it/them.

Agreed. But this overlooks Ned's consideration for a signature on- 
behalf-of the Sender where the signing domain encompasses the From  
domain, (and where the identity is not excluded by the signature's key  
g= and t= parameters).

>> within the signature's domain MUST include all From email- 
>> addresses.  When the signature's domain is authoritative for the  
>> From's email-address's domain, (unless by a g= restricted key) the  
>> message MUST BE assumed to meet the signing domain's policies.
>
> domains has to be considered as well.  Just as the point has been  
> made that it's not proper to handle this case by arbitrarily picking  
> the first From domain, I believe that it's also not proper to use  
> Sender for this purpose.  Given that belief, the question of whether  
> Sender is signed or not is moot.

Disagree.  When the From email-address is encompassed by the Sender's  
signing domain and is not excluded by the signature's key g= and t=  
parameters, there is no reason to assume the message does not comply  
with the signing domain's policies.  This concept covers all From  
email-addresses.  Policy referenced by the Sender's email-address  
domain matters little, and that is not what is being suggested.

> included" but that text was removed by WG consensus.  I don't  
> consider this to be a dangerous gap, however.  RFC 4871 describes  
> the process for constructing and verifying DKIM signatures; the  
> context for what valid signatures are useful for what purposes lies  
> outside that scope.

When deciding compliance, these security gaps MUST be considered.   
When a message is signed on-behalf-of (i=) some other identity within  
the signing domain, and this identity does not appear within the From  
header, the key's g= and t= parameter matter.  In addition, when  
attempting to highlight which identities are signed, information not  
included within the signature's hash MUST BE excluded.  These  
represent significant security concerns.

In addition, a domain should be able to say they sign "all" and apply  
RFC 4871 as currently defined.  Presently, SSP requires significant  
changes to how RFC 4871 is applied.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 25 Jan 2008 15:37:36 -0000

> this purpose.  Given that belief, the question of whether Sender is  

The Sender header is an assertion "This is where this message _really_  
came from". If Ebay does not want people to be able to say "this message  
came from Ebay (even if Ebay appears nowhere in the Froms), then it ought  
to be possible for Ebay to state that policy in its SSP; whether such a  
policy is implied by 'strict', or by some other yet-to-be-invented tag, is  
just a minor technical detail to be decided. Likewise for the Resent-*  
headers.

Note that I am assuming such signatures would encompass the Sender header  
(which is a SHOULD in 4871).

-- 
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: Eliot Lear <[email-masked]>
Date: Fri, 25 Jan 2008 16:46:11 +0100

> and usually will, do what will make their customers happy.

You replied out of context.  In fact, Steve, I would argue that you 
ignored the original text.  ISPs cannot afford to make changes on a 
whim, and many ISPs can't afford to make changes at all.  We have an 
extraordinary debate going on on this mailing list.  We have gotten away 
from the practical deployment of SSP.  If we accept issue 1521 we 
mandate reputation services in order to deploy SSP.  That seems to me a 
mistake and a large one at that, when considering the general case.
> DKIM signatures.
The ISP has not made a change on a whim but based on the reputation of 
acm.org, which unverified could be the next spam vector, just like any 
other known forwarder whose signature breaks.

> Most SSP fails in those cases will lead to rejection

And again, that's not done on a whim.  Moreover, someone who puts out 
strict or similar conditions in an SSP record is going to get what they 
deserve.  Why would they do this?  They have customers too, right?

Eliot