Subject: [ietf-dkim] NEW ISSUE: Limit the application of SSP to unsigned messages

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 09:04:20 -0800

> 2. Unsigned vs. Mismatched Signature
> 
> The original SSP specification applied only to unsigned messages. The current
> version includes mail that is signed but has different domains between the
> DKIM i= attribute and the rfc2822.From field. Presumably, this new capability
> overrides whatever reputation is associated with the message signer.
> 
> If a signer has a good reputation, then why is that not sufficient for
> enabling delivery?  In other words, with a signature of a domain with a good
> reputation, what threats is SSP trying to protect against?

To the extent that the above is not sufficiently clear:

      All text that causes SSP to be applied to an already-signed message 
needs to be removed.

A DKIM signature is a statement of responsibility.  When a signature is 
present, an organization has taken responsibility for the message.

Reconciling an existing signature against another identity field, such as 
rfc2822.From moves the use of DKIM from statements about simple transit 
responsibility into assertions of content legitimacy and/or accuracy. This is 
out of scope for DKIM.

d/
-- 

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

---

From: Arvel Hathcock <[email-masked]>
Date: Sun, 09 Dec 2007 14:33:13 -0600

>      All text that causes SSP to be applied to an already-signed message 

-1.  That simply has to be utterly rejected.

> present, an organization has taken responsibility for the message.

That's fine for DKIM-Base.  We're discussing SSP though.

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 14:44:03 -0800

Arvel,

It would help to have some engineering rationale and market demand commentary 
to flesh our a call for "utter" rejection.

d/

Arvel Hathcock wrote:
>>      All text that causes SSP to be applied to an already-signed 
>> message needs to be removed.
> 
>> A DKIM signature is a statement of responsibility.  When a signature 
>> is present, an organization has taken responsibility for the message.
> 

-- 

   Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Sun, 09 Dec 2007 19:03:03 -0600

Sure thing!

The purpose of SSP is to detect unauthorized domain use.  This can not 
be achieved if the spec assumes that a signature from just anybody 
what-so-ever is OK.  So, the engineering rationale for rejecting your 
idea is that accepting it would mean a complete defeat of the purpose.

Arvel

Dave Crocker wrote:
> Arvel,
> 
> It would help to have some engineering rationale and market demand 
> commentary to flesh our a call for "utter" rejection.
> 
> d/
> 
> Arvel Hathcock wrote:

---

From: John Levine <[email-masked]>
Date: 10 Dec 2007 02:05:40 -0000

> The purpose of SSP is to detect unauthorized domain use.  This can
> not be achieved if the spec assumes that a signature from just
> anybody what-so-ever is OK.

But that's not what Dave said.  He said that if there's a signature, a
receiver doesn't do SSP.  It remains up to the receiver to decide what
to do with the message, including deciding what its opinion is of
the signing domain.

To offer some concrete examples, if I get mail signed by nytimes.com
with your domain on the From: line, I'm going do deliver it no matter
what your SSP says, because I know that the Times doesn't send spam.
Even if you have a firm corporate policy that your users aren't
allowed to send mail from the Times' web site and a fierce SSP to
match, that's not my problem.

Conversely, if I get mail signed by a sleazy domain in Nigeria that's
never sent me mail I wanted, I'm going to junk it.

Incidentally, this chronic misreading of "the signature identifies the
responsible domain" as "accept the message" (not just by one person)
tells me that we have some significant misunderstandings about what
DKIM does and doesn't do.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 9 Dec 2007 22:39:44 -0500

> to do with the message, including deciding what its opinion is of

Right, so we don't do SSP if a signature exists.  Adding signatures is trivial 
and so bad guys quickly add signatures (any old one will do) and SSP is 
obviated.  That does sound like any old signature will do to obviate SSP.

> never sent me mail I wanted, I'm going to junk it.

And what if it's signed by an unkown domain?  Clearly if you have enough data 
and some secret sauce for reputation to understand if a signing domain is 
good/bad, then you'll probably let that over-ride, but reputation is outside 
the scope of the WG.

So what about the middle option where you don't know if the signing domain 
is 'good' or 'bad'?

If the domain has never sent you mail, how do you know it's sleazy?

> DKIM does and doesn't do.

Odd.  I haven't seen anyone doing that.  I've seen people accused of doing 
that, but not the actual doing.

Scott K

---

From: Arvel Hathcock <[email-masked]>
Date: Sun, 09 Dec 2007 22:52:45 -0600

> receiver doesn't do SSP.  

Ok sorry, I had thought that "what-so-ever is OK" would be understood in 
the context of skipping SSP.  Let me state it clearer:

The purpose of SSP is to detect unauthorized domain use.  This can not 
be achieved if the spec allows the existence of any signature from just 
anybody what-so-ever to skip SSP.

> It remains up to the receiver to decide what to do with the message, 
 > including deciding what its opinion is of the signing domain.
 >

The problem is when you get a signature from an identity that you have 
no information on.  This is precisely the case in which SSP is needed 
and precisely the case which is rendered impotent by Dave's proposed change.

> DKIM does and doesn't do.

I'm certainly not making that mistake.  I'm saying that SSP can not be 
skipped just because there's a signature present from anybody at all. 
That doesn't equate to "accept the message."

Imagine a message signed by A but with B as the domain in the From.  If 
A is not a clear-cut case such as those you've cited (Nytimes.com or 
Nigeria) it would be enormously useful to check the policy of B, see 
whether they sign all messages, and then do what you want with the 
message based on this added knowledge.  But checking the policy of B 
would be precluded if the mere existence of a signature by A means you 
don't check with B at all!  This is what I claim would be an epic mistake.

Arvel

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 10 Dec 2007 09:13:28 +0100

> All text that causes SSP to be applied to an already-signed message 

-1

> is present, an organization has taken responsibility for the message.

I don't care about what spammer took the responsibility.  If the PRA -
DKIM by design ignores the envelope sender address, that leaves only
the PRA - says it's suspicious then it IS suspicious, no matter what
anybody else signs.

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Dec 2007 10:41:02 +0100

Dave Crocker wrote:
> Reconciling an existing signature against another identity field, such
> as rfc2822.From moves the use of DKIM from statements about simple
> transit responsibility into assertions of content legitimacy and/or
> accuracy. This is out of scope for DKIM.
>
> d/

While I don't agree with Dave's proposal, I do think there may be a
problem with the text.  In particular I am concerned about mailing list
software that breaks signatures and resigns.  Dave's concern is over the
definition of the message originator.  If a reputation check of some
form is done on a valid signature and found to be positive, I see no
reason to continue the SSP process.  On the other hand, if the
reputation check returns neutral or negative, that could open a gaping
hole into the specification, by avoiding checks that would have
otherwise been performed that would have led to "suspicious".

Eliot

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Dec 2007 08:04:11 -0500

> match, that's not my problem.

But it is a problem and here its Time's problem because it has to 
address people like yourself who A) may be ignorant of DKIM/SSP or B) 
ignorant of SSP or C) plays by its own rules.

When Time did its email verification, if its going to be signing mail as 
a 3rd party, it should of included a check to Arvel's SSP to check to 
see if this is a restricted high-value consideration.

One simple DNS check would of tell them that a subscribing address is 
not allowed to be used at a Times web site.  It helps protect you, them 
and the responsible original domain, all parties.

> never sent me mail I wanted, I'm going to junk it.

And like others pointed out, there is this vast middle world that didn't 
make it into your limited, subjective A/R database system yet which no 
one disagrees or doesn't know is a natural part of a Local Policy 
considerations.

This is all a prime example of how out of scope A/R considerations 
continues to muddy the water and abuses the SSP WG progress.

-- 
Sincerely

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 08:01:30 -0800

> commentary to flesh our a call for "utter" rejection.

   See the entire thread "How to make SSP utterly useless in one short
   step". The one that started with this subject and then you didn't
   respond. From what I can tell, you do not want to be educated, you
   just want to stop SSP, and have said as much.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 08:16:19 -0800

>   just want to stop SSP, and have said as much.

Once again:  on what basis of credible working group management is is 
acceptable for anyone, nevermind an author of a working group document, to be 
tossing out ad hominems, like this, nevermind do it regularly?

d/

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Dec 2007 16:19:38 +0000

Mike,

Michael Thomas wrote:
> From what I can tell, you do not want to be educated, you

That is unhelpful. Please desist from such.

Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 08:25:45 -0800

> That is unhelpful. Please desist from such.

   So exactly how many times are we supposed to respond to the same issue
   from the same poster in good faith?

		Mike

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 10 Dec 2007 11:36:04 -0500

>    from the same poster in good faith?
+1.

I've got 33 messages from one participant in the last two days and I find 
nothing novel or constructive in them in my personal opinion.  Such actions 
are (once again in my personal opinion which may well be wrong) nothing more 
than a denial of service attack on this working group.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Dec 2007 16:37:48 +0000

>   from the same poster in good faith?

How often you respond is your call. Doing so politely
is a basic requirement. I'm sure you know that already.

S.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 08:40:19 -0800

> is a basic requirement. I'm sure you know that already.

   My question actually pertains to the DOS attack.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 08:44:28 -0800

Michael Thomas wrote:
>   respond.

I have looked for this thread and do have a recollection of the subject line, 
but am not finding it.

Please provide an archive url to it.

d/

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Dec 2007 16:46:30 +0000

> than a denial of service attack on this working group.

FWIW, I don't agree that this is just a DoS. At least some of the
issues raised haven't gotten much consideration over the last few
months and if we do want to produce a standards track SSP then we
need to do that level of review.

Let's all stop speculating as to motives.

S.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 10 Dec 2007 11:56:42 -0500

On Monday 10 December 2007 11:46, Stephen Farrell wrote:
> > nothing novel or constructive in them in my personal opinion.  Such
> > actions are (once again in my personal opinion which may well be wrong)
> > nothing more than a denial of service attack on this working group.
>

Sure.  I have my opinion and you're certainly entitled to yours.  As I've said 
previously, I have neither the time nor the energy to sort through all the 
chaff to see if or what bits of wheat are there.

To the extent I understand his flurry of comments I think they are largely 
based on a lack of recollection of what the WG has been through already or a 
fundamental misunderstanding of SSP.  I don't think it's my job to fix either 
of those.

> Let's all stop speculating as to motives.

Done.  Good luck getting through this.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 09:15:39 -0800

Dave Crocker wrote:
> I have looked for this thread and do have a recollection of the subject 
> line, but am not finding it.
> 

The title was "Making SSP useless in one short step". It was no more
than a week ago.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 09:52:19 -0800

Michael Thomas wrote:
> Dave Crocker wrote:
>> I have looked for this thread and do have a recollection of the 
>> subject line, but am not finding it.
>>

Well, in spite of having noted that I couldn't find it and your not providing 
a url, I did manage to track it down.

Now I am concerned that you are not receiving all of the mailing list 
postings, since I see at least 3 postings from me, in that thread.

In particular, please note the one with a 12/5/07 12:54pm date, since it seeks 
to provide a detailed response and you seem to have missed it.

For reference, I suspect the core issue in your saying something like "utterly 
defeated" is that it needs a technical statement that defines "defeat" in 
terms that are specific to this mechanism.  For example, what are the attacks 
and why are they a) important, and b) unique to this issue?

d/
-- 

   Dave Crocker

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 10 Dec 2007 18:42:59 +0100

Scott Kitterman wrote:

> I have neither the time nor the energy to sort through all the 

Then just don't, e.g. I think that he never reads what I write ;-)
 
> To the extent I understand his flurry of comments I think they
> are largely based on a lack of recollection of what the WG has
> been through already or a fundamental misunderstanding of SSP.

As author of 822 and email-arch he knows the difference between
"sender", "author", and "originator", no matter how many folks,
WG or otherwise, wish to redefine the terms outside of 2822upd.

Admittedly it's disturbing that Dave, JohnL, Pete, and JohnK
can come up with three strictly incompatible visions what an 
existing or lacking Sender header means for a mailing list :-(

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Dec 2007 19:28:44 +0100

> than a denial of service attack on this working group.

Message count has nothing to do with this.  Dave followed the plaintive
request I had made to break up his review into separate issues.  Now,
can we all take a breather and step away from our keyboards?

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 11:50:53 -0800

Eliot Lear wrote:
> Dave's concern is over the
> reason to continue the SSP process.
>   

I certainly agree that if this isn't clear it should be made to be clear.
But what's unclear to me is that it has anything to do with the text
in the draft or whether it's some people's preconceived notions. We
can't do much about the latter, but trying to look at this from the
standpoint of a naive implementor would be helpful. In particular,
we need to be extremely clear that when you run SSP (before,
after, concurrently) with respect to any reputation or any other
mechanism (other than dkim verification) is out of scope of SSP.

       Mike

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Dec 2007 21:26:19 +0100

Mike,
> in the draft or whether it's some people's preconceived notions. 

Here are the relevant definitions:

2.3.  Originator Address

   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.

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.

For purposes of our discussion, let us consider the case where I have
received a message from [email-masked] via a mailing list
[email-masked] that has somehow broken the Joe's DKIM
signature, perhaps by appending some text at the bottom.  The MTA for
good-reputation.com has signed the message.  Section 4.4 Step 1 does not
directly state that I can use that signature as a valid signature.  Let
us assume that handling=deny and that dkim=all in this example.  Because
I do not have a valid originator signature I proceed to Step 2 and query
for _ssp._domainkey.StrictSSP.COM.

I believe this is undesirable.  It would be better to have the check
earlier, say in step 1, but I recognize this presents a problem with
strict, because you never make an SSP query to determine if strict
conditions apply.  To solve this one could add a flag to the DKIM DNS
record.

Eliot

---

From: <[email-masked]>
Date: Mon, 10 Dec 2007 15:39:05 -0500

So DKIM aware mailing lists should perhaps delete dkim signatures and
issue their own? Your message in the example is not a message from
[email-masked] as he is a content contributor to the
originator/author 
[email-masked]. Perhaps an effort to create an RFC
track for DKIM aware mailing lists is a better tack than trying to
shoehorn it into SSP. 
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Monday, December 10, 2007 3:26 PM
To: Michael Thomas
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] NEW ISSUE: Limit the application of SSP to
unsignedmessages

Mike,

2.3.  Originator Address

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 13:01:05 -0800

> for _ssp._domainkey.StrictSSP.COM.
     That is the correct behavior, IMO. The SSP protocol should not have
     anything useful to say about third party signatures nor how you might
     combine all of that information into a content delivery decision. What
     seems to be the hangup here is that people are reading SSP qua SSP
     as preventing the receiver from filtering, issuing queries to 
reputation
     systems, tying its shoelaces and whatever else a receiver might want
     to do, and in what order it might desire. I doesn't, and to the 
extent that
     that isn't clear in the text it should surely be corrected.

> conditions apply.  To solve this one could add a flag to the DKIM DNS

    IMO, that is the receiver's decision based on their receive policies. I
    for one don't care if, oh say, Cisco resigns, oh say, Ironport's 
messages
    labeled as strict and Cisco trusts its own signatures over Ironport's
    SSP record. Not our decision, not in SSP's scope.

       Mike

---

From: Tony Hansen <[email-masked]>
Date: Mon, 10 Dec 2007 22:18:01 -0500

Sections 2.3 and 3.4 of draft-ietf-dkim-deployment discuss mailing list
managers. They discuss the various forms of mailing lists and recommend
that some of the types definitely issue their own signatures. The
original version of these sections actually discussed the possibility of
deleting extant dim signatures, but that recommendation has not survived
to the current document.

	Tony Hansen
	[email-masked]

---

From: Jim Fenton <[email-masked]>
Date: Tue, 11 Dec 2007 08:52:31 -0800

-1

As others have noted, bypassing SSP based on a valid signature from any
arbitrary domain permits a trivial attack:  attackers could sign
messages using throw-away domains they control.

Without placing a dependency on a reputation or accreditation service
(both of which are out of scope), it's not possible to specify the
circumstances under which an SSP query should be done when a message is
signed by other than the author domain.  Furthermore, trust isn't an
absolute:  while I might generally trust mail signed by, say, ietf.org,
I wouldn't expect that signature on transactional mail.  Eliminating the
query on signed mail also negates the effect of the SSP expectation
assertion specified in RFC 5016 that manifests itself as the "strict"
practice in SSP.

I fully expect that some verifiers will implement an SSP-like thing that
places signer reputation at a higher priority than the expectation
published by the author domain, and they're welcome to do whatever works
for them, even if it isn't, strictly speaking, SSP.

Your last statement seems to deal with issue 1524 more than 1521.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Dec 2007 09:18:07 -0800

> messages using throw-away domains they control.

It's a shame we don't have an SSP threats analysis, so that this concern could 
be placed in context.

The 'threat' that you are citing is for a signed message, which means that 
there is a verifiable, accountable identity associated.  That identity will 
have a reputation.

It seems that concern for the attack that you cite needs to satisfy a couple 
of preconditions:

1. Clear statement of what it is application of an SSP publication MUST 
achieve.  Otherwise, we cannot evaluate failing to achieve through such an attack.

2. Explanation of the reason that having a verifiable, accountable identity is 
insufficient.

3. Consideration of the relative costs in protecting against this attack.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 Dec 2007 09:27:41 -0800

On Dec 11, 2007, at 8:52 AM, Jim Fenton wrote:

> Without placing a dependency on a reputation or accreditation  
> service (both of which are out of scope), it's not possible to  
> specify the circumstances under which an SSP query should be done  
> when a message is signed by other than the author domain.

Issue #1519 provides additional clarification.  I think this meant  
unsigned by the domain, and perhaps unsigned by an otherwise trusted  
domain.

Even when a message is signed by the domain of the author (using an  
unrestricted key), per the definition of Originator Signature, the  
message will not have a valid signature.

If ietf.org were to make a "strict" assertion, this should only affect  
ietf.org email-addresses that are NOT signed by the ietf.org _domain_.

A "strict" assertion should not affect messages representing a normal  
communiqué initiated by the domain, nor should a "strict" assertion  
change how message signing is defined in the base draft.  In other  
words this assertion should not require multiple signatures from the  
same domain, or prevent the i= parameter from indicating which header  
the message had been signed "on-behalf-of."

The "strict" assertion should mean the domain ALWAYS signs their  
messages AND the domain attempts to avoid services that might corrupt  
their signature.

The "strict" assertion should not mean that their domain's signature  
is only valid when signed "on-behalf-of" the From header.  (An  
exception would be required only for restricted keys.)

A less restrictive view of "strict" empowers domains to decide which  
messages are valid by simply adding their signature.

A less restrictive view of "strict" would not invalidate message  
signing as defined in the base draft.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 11 Dec 2007 13:57:04 -0500

> The 'threat' that you are citing is for a signed message, 
 > which means that there is a verifiable, accountable
 > identity associated.  That identity will have a reputation.

What proof do you have to validates the assertion?

        "That identify will have a reputation."

How is "reputation" defined and how does the generalized network email 
infrastructure reach that conclusion without resorting to 3rd party 
Trust Services?

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 11 Dec 2007 20:00:27 +0100

Jim Fenton wrote:

> As others have noted, bypassing SSP based on a valid signature
> from any arbitrary domain permits a trivial attack:  attackers
> could sign messages using throw-away domains they control.

Yes, valid DKIM signatures from unknown third parties are rather
pointlesss, and using SSP in such cases to determine the opinion
of the PRA (nobody else's opinion is relevant) is a *good thing*.

BUT a valid DKIM signature from a known + trustworthy 3rd party
can be already good enough (JohnL's NY Times example) to ignore
the opinion of the PRA (e.g. skip the SSP check if not yet done),
that's an obvious case of "receiver policy".

And it's not some "out of scope" reputation scheme, it's a mere
white list, any receiver can do this, they don't need an RFC for
this task.

I fail to understand why these two simple scenarios are seen as
contradictions or even SSP-showstoppers here, they're both fine.

> it's not possible to specify the circumstances under which an
> SSP query should be done when a message is signed by other 
> than the author domain.

+1  That's a receiver decision, and the SSP spec. should focus
    on the actions *after* the receiver decided to check SSP.

It can't say "do this no matter what", it can say "if you wish
to do this that's how it's done".  What's so difficult about
this, even RFC 4408 got it right, actually I'd think that a
receiver is free to abort the evaluation of S* at any point
with result "that takes longer than usual, so I give up now".

> trust isn't an absolute:  while I might generally trust mail
> signed by, say, ietf.org, I wouldn't expect that signature on 
> transactional mail.

Fine, add a bit to your white list.  You're the receiver, you
can do anything you like, but don't lie to your users claiming
that you evaluated any S* when you didn't.

 Frank

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Dec 2007 11:25:54 -0800

> contradictions or even SSP-showstoppers here, they're both fine.

   Is anybody actually saying that? I haven't seen it. I've seen
   a fair amount of confusion that somebody, somewhere might have
   said that, but as far as I can tell nobody has said that you
   must put any reputation or any other checks before or after
   SSP. Whether a receiver decides to run SSP at all is its
   decision.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 Dec 2007 14:03:10 -0800

On Dec 11, 2007, at 10:57 AM, Hector Santos wrote:
>
>> The 'threat' that you are citing is for a signed message, which  
>> means that there is a verifiable, accountable identity associated.   
>> That identity will have a reputation.
>
> How is "reputation" defined and how does the generalized network  
> email infrastructure reach that conclusion without resorting to 3rd  
> party Trust Services?

A valid DKIM signature offers a fair amount of information, even  
without it matching an email header.

The typical MTA can accrue a fair amount of DKIM related information  
without reliance on outside services.

When a domain is being assessed, negative points can be assigned when:

  o the domain is new to the receiver
	
  o the domain name server host or IP address is new to the receiver

  o the domain is known to send spam

  o the domain name server host or IP address is known to publish spam  
related domain names

-Doug

---

From: Jon Callas <[email-masked]>
Date: Tue, 11 Dec 2007 19:09:56 -0800

On Dec 9, 2007, at 5:03 PM, Arvel Hathcock wrote:

> The purpose of SSP is to detect unauthorized domain use.

I disagree on this. The purpose of SSP is for the sender to give the  
receiver a hint as to what to do with messages that have broken  
signatures.

In a number of cases, such as a policy of "sign-all," this may have  
the *effect* of lowering unauthorized domain use, because the  
receivers will be more inclined to black-hole a message with a broken  
signature. If my MTA had a checkbox that enabled this, I'd probably  
check it.

Unsigned messages are still something I'm not comfortable with. While  
they are a case of broken-signature-messages, and again, if my MTA  
had a check box that said "Check sender's SSP for unsigned messages,"  
I would probably check that, too.

However, I'm still uncomfortable with declaring that all non-DKIM  
emails are all of a sudden broken-signature-messages.

	Jon

---

From: "J D Falk" <[email-masked]>
Date: Wed, 12 Dec 2007 19:51:36 -0500

Stephen Farrell wrote:

> months and if we do want to produce a standards track SSP then we need
> to do that level of review.

+1

I share many of Dave's concerns, but he explains them better than I
would -- and I'm trying to avoid a flood of +1 messages.

---

From: [email-masked]
Date: Wed, 12 Dec 2007 17:01:51 -0800 (PST)

+1 as well.

> would -- and I'm trying to avoid a flood of +1 messages.

For me it's a question  of dealing with the 300 or so messages sent since
the beginning of the month. I simply cannot keep up with this while also
dealing with all the other IETF work I have to track.

				Ned