Subject: [ietf-dkim] A more fundamental SSP axiom

From: John L <[email-masked]>
Date: Wed, 2 Aug 2006 00:27:32 -0400 (EDT)

How about this one:

   SSP exists so that receivers can make better decisions about
   handling their incoming mail.

Corollary:

   Information not useful to receivers doesn't belong in SSP.

These seem obvious to me, but based on some other correspondence, they're 
not obvious to everyone.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 01 Aug 2006 22:30:26 -0700

>   Information not useful to receivers doesn't belong in SSP.

For this initial round of SSP, the wording of the Corollary probably needs to be:

    Information that is not widely viewed by receivers as essential doesn't
    belong in SSP.

Hence, any suggestion to include something into SSP needs to say 1) how we know
that it is of immediate and substantial benefit to receivers, and 2) why we are
 certain that there is a broad base of receivers who believe they need it
(immediately.)

d/
-- 

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

---

From: wayne <[email-masked]>
Date: Wed, 02 Aug 2006 08:28:20 -0500

>>   Information not useful to receivers doesn't belong in SSP.

I agree, but it is also important to remember that anything that has
no value to the sender will likely not be put into the SSP either.

>     Information that is not widely viewed by receivers as essential doesn't

I think this is very short sighted.  It is rare that a protocol gets
more than one or two revisions.  I don't think it is certain that DKIM
will actually even surpasses DK usage and receives wide adoption, but
I think it is very unlikely that we will get a chance to update DKIM
and have that update receive wide adoption.

There certainly should be a cost/benefit analysis done.  If a feature
is costly to add and has little obvious benefit to both senders and
receivers, then, yeah, drop it.  However, if a feature is cheap or
trivial to add, then just because there aren't people willing to use
it *immediately* is no reason to rule it out.  And, yes, the overall
complexity of the SSP system needs to be added into the cost, I'm not
saying that all features that, in isolation, are "cheap" should be
added, just that we shouldn't design SSP for only today and not for
5-10 years down the road.

-wayne

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Aug 2006 10:35:21 -0700

John L wrote:

> These seem obvious to me, but based on some other correspondence, 
> they're not obvious to everyone.

I think a more fundamental question is who the consumers of SSP information
are.  I think that everybody agrees that DKIM receivers are an important
constituent, but are they the only ones? It doesn't seem very hard to 
envision
other consumers.

          Mike

---

From: Damon <[email-masked]>
Date: Wed, 2 Aug 2006 17:22:44 -0400

Ok.

 Here is a scenario:

 I send a signed message somewhere.

To me, it's that simple.

IMHO this-Works: (some of which flies in the face of the scope- I know -
don't care)
-One signature per message.
-Authentication happens in the SMTP process or a process that knows
everything about the message that the MTA knows about it.
- Relays must not sign messages if the messages have already been signed
unless the content has changed (that makes it a new message right?)
- Let the admins figure out what level the RSA is at. I think they know
better than we do about how to get their mail from place to place. If they
set it too high.. reject it! Why is that so hard?
- If the sig is broken, the email is broken- period. Whose bright idea was
it to forgive broken sigs?!
- SSL is what DKIM *should* be. It is the heart and soul of it.

this doesn't work:
"I sign sometimes" This seemed like a joke to me. What is the point if you
can't tell the user if your mail will be signed by you and when it will be
signed. - Will work by putting in FQDN or CIDR's in the SIG line and using
your MTA or MTA data aware process to check it against the sending IP.
"I sign always" - Unless you are draconian, this will not work for you and
you will have to use 'I sign sometimes or never' and that.... well...
currently is useless.

What did I miss?

Regards,
Damon Sauer

On 8/2/06, John L <[email-masked]> wrote:
> > envision other consumers.
>
> Usage scenarios would be very helpful.  As Dave noted, if people can throw
> stuff into a protocol because it might be useful for something nobody
> actually plans to do, you end up with terminal bloat.
>
> R's,
> John

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Aug 2006 19:34:37 -0700

John L wrote:

> Usage scenarios would be very helpful.  As Dave noted, if people can 
> throw stuff into a protocol because it might be useful for something 
> nobody actually plans to do, you end up with terminal bloat.

Please don't shoot the messanger: I'm just asking. It's a fairly common 
occurrance
that a successful protocol will have many more uses/consumers than was 
originally envisioned.
Especially in the case of spam, it's not very clear what the mutations 
will be so it's
worth questioning, IMO.

          Mike

---

From: John L <[email-masked]>
Date: Wed, 2 Aug 2006 22:51:04 -0400 (EDT)

> Please don't shoot the messanger: I'm just asking.

I hadn't intended to shoot, sorry if it came across that way.  You're 
right, people find all sorts of other uses for successful protocols, but 
those uses tend to be "pull", repurpose info already used for something 
else rather than "push", stick in the data and see if anyone cares.  The 
way we're trying to define SSP is really risky since we have, as far as I 
can tell, no operational experience at all with anything SSP-like so we're 
just guessing about what will be useful.

It seems to me that so far we have two, maybe three, items that a sender 
could publish that would plausibly be useful to a recipient trying to 
decide what to do with an incoming message that isn't self-signed.

"I send no mail" is about the strongest possible hint that the message is 
forged, and the recipient doesn't want it.

"I sign all mail" is the next strongest hint, saying to me that the sender 
believes it has its outgoing mail firmly enough under control that an 
unsigned message is more likely to be a phish than a damaged real message.

The third is "<foo> signs all my mail", if it turns out that there 
actually exist foo's that reliable enough to delegate's one's signing, and 
that it's easier to do that than to sign in the MUA or to provide signing 
keys so that foo can put on the sender's signature.

So my suggestion would be to use a format similar to the one we use for 
the signatures, put the first two items in the spec, and use a syntax that 
permits people to experiment with new items and propose the useful ones 
for later standardization.

R's,
John

---

From: <[email-masked]>
Date: Wed, 2 Aug 2006 23:00:41 -0400

All,
Maybe I am confused on how email works.
Sending,
A. I want to send a message. My MTA looks up the MX record of the
receiving party and initiates a bind and a conversation on port 25 with
the receiver's MTA. As part of that conversation headers are exchanged
one of which is DKIM. I then pass the message itself. The receiving MTA
gives me a gooday then trundles off to do the magic receiving stuff.

B. My MTA must relay to another MTA because I am on a DHCP based static
IP
I initiate the conversation above with my relayer who then repeats the
process with the MTA on the other end of the MX record. If my agreement
with my relaying MTA is to sign on my behalf I have a 3rd party
signature. Plus perhaps my own.

C. Using the B example above my relayer thinks he is talking to the MTA
of the receiver because of the MX record but is really talking to a 3rd
party front end who runs spam filters for the real users (MXLogic comes
to mind) they say thank you very much and may well sign again for the
MTA and MUA of the real recipient behind them.

Now I haven't addressed lists yet. Am I missing any pieces?

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Thomas
Sent: Wednesday, August 02, 2006 10:35 PM
To: John L
Cc: DKIM List
Subject: Re: [ietf-dkim] A more fundamental SSP axiom

          Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 02 Aug 2006 20:02:54 -0700

John L wrote:
> actually exist foo's that reliable enough to delegate's one's signing,
> and that it's easier to do that than to sign in the MUA or to provide
> signing keys so that foo can put on the sender's signature.

Outsourcing for mail sending is already common, so it seems likely that
delegating signing would be, too.

But my question is why it is better to have a "delegation of my domain" scheme
rather than simply having the outsourced sending do its own signature and then
use its domain name for evaluating its own reputation.  If it is a Good Actor,
then it shouldn't need to rely on the domain name of the content author.  If it
is a Bad Actor, then relying on the domain name of the content author would
merely wind up hurting the content author.

> the signatures, put the first two items in the spec, and use a syntax
> that permits people to experiment with new items and propose the useful
> ones for later standardization.

Something this minimalist does indeed seem like the best approach:  1)
standardize a publication mechanism for an extensible list of practices; and 2)
include a tiny number of extremely interesting practices to publish, to seed the
effort.

d/
-- 

  Dave Crocker

---

From: John L <[email-masked]>
Date: Wed, 2 Aug 2006 16:56:35 -0400 (EDT)

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Thu, 03 Aug 2006 08:19:13 -0700

> merely wind up hurting the content author.

One should assume that the recipient _can_not_ recognize the From
email-address.  However, one could also assume that the MUA _can_
recognize an "accepted" the address when annotating the message.  Also
assume the annotation is distinctive in some fashion and can be reliably
recognized by the recipient.  This overcomes the issue of only
display-names being visible, look-alikes, and internationalization or
the recipient paying more attention to HTML content.  This is a High
Impact, High Likelihood concern.

To assist the MUA recognition process, an extremely useful piece of
information will protect the "acceptance" process.  Is this signature
considered "authoritative" by the From email-address domain?  This
suggests that the "authoritative" signing domain _is_ considered to be
doing the right things.  The right things might be authenticating the
sending account and verifying reception of the email-address before
permitting its use by this account.  While the recipient may wish to
override this requirement, they would be doing this at their peril. 

> include a tiny number of extremely interesting practices to publish, to seed the

Actually there is something even more minimal.  The "I sign all mail"
and "I send no mail" and "Foo signs my mail" can be answered using a
list and a single flag.  The flag would indicate that "I do not use
non-designated sources that may or may not sign"  or in other words,
"All my mail is signed by designated sources."  In Hectors view, this
flag represents a statement "Treat non-designated signatures with
extreme prejudice."

"I send no mail" would be an empty list and a flag.

"Just I sign all my mail" would be I's domain and a flag.

"Just Foo signs my mail" would be a list with Foo and a flag.

"Just Foo and I sign my mail" would be list with Foo and I and a flag.

"Don't expect all my mail will be signed, or signed by designated
signing domains" would be an empty list and no flag.  This would be the
default when no policy is found.

"Foo and I and other may sign" would be a list of Foo and I and no flag.
This should be the recommend method of indicating designated domains and
avoiding unexpected prejudicial treatment. Only heavily phished domains
might consider setting the flag, even though Hector may insist
otherwise.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 03 Aug 2006 12:10:24 -0700

John L wrote:

> right, people find all sorts of other uses for successful protocols, 
> but those uses tend to be "pull", repurpose info already used for 
> something else rather than "push", stick in the data and see if anyone 
> cares.  The way we're trying to define SSP is really risky since we 
> have, as far as I can tell, no operational experience at all with 
> anything SSP-like so we're just guessing about what will be useful.
>
> It seems to me that so far we have two, maybe three, items that a 
> sender could publish that would plausibly be useful to a recipient 
> trying to decide what to do with an incoming message that isn't 
> self-signed.
>
> "I send no mail" is about the strongest possible hint that the message 
> is forged, and the recipient doesn't want it.
>
> "I sign all mail" is the next strongest hint, saying to me that the 
> sender believes it has its outgoing mail firmly enough under control 
> that an unsigned message is more likely to be a phish than a damaged 
> real message.

As I've said before, there are really two different subclasses of this one.
You can have your mail very well under control, but you don't have
control over what the damage might be in transit. For some people
like banks and phishing targets, that collateral damage is likely to be
acceptable. For most everybody else it's not.

So I guess it just intrinsically bugs me that the former is a pretty 
rarified
class  of sender, and is SSP really _only_ for them? (leaving I send
no mail aside).  Is there little or no value in knowing that you sign
everything, but transit related damage is possible?

> signing keys so that foo can put on the sender's signature.

This is sort of orthogonal to the previous: it's just saying _who_ is doing
it, so the previous considerations of "I sign all mail" still appy.

>
> So my suggestion would be to use a format similar to the one we use 
> for the signatures, put the first two items in the spec, and use a 
> syntax that permits people to experiment with new items and propose 
> the useful ones for later standardization.
>
I'm mostly on the keep it simple side as well -- I'm mainly pushing on these
things to get issue out in the open so they can be considered and likely 
closed.

I have seen some pushback on "standardize later" tact, but I think 
you're right
that this isn't the same as, say, dkim-base where we're not very likely 
to get an
opportunity for version 2.0. But it shouldn't hurt to just add
stuff to the policy record -- possibly non-standard experimental stuff 
-- and
if it's useful and relevant, users of the protocol will almost certainly 
have an
incentive to upgrade their software to take advantage of it. This is in 
stark
contrast to the -base upgrade problem where the signer has no clue of the
capabilities of the receiver, so backward compatibility is huge concern.

       Mike

---

From: John L <[email-masked]>
Date: Thu, 3 Aug 2006 15:45:22 -0400 (EDT)

>> "I sign all mail" ...

> So I guess it just intrinsically bugs me that the former is a pretty rarified

We have to keep in mind that the recipient is interpreting this stuff, and 
it's up to the recipient to decide what risk they are willing to accept. 
Transit damage is always possible, so I don't see any value in pointing 
that out.  As a receiver, I find a hint that unsigned mail from you is 
probably bogus to be useful.  Your own opinion of the value of that mail 
is not.

I also don't see "I sign everything" as limited to large companies.  My 
lawyer is part of a small firm with their own mail server on a leased 
line.  I expect they have enough sense to tell people that if they want to 
send mail from home or on the road, use the company's web mail.  They'd be 
a perfectly good candidate for "I sign everything", and I don't think 
they're at all atypical.

> But it shouldn't hurt to just add stuff to the policy record -- possibly 
> non-standard experimental stuff -- and if it's useful and relevant, 
> users of the protocol will almost certainly have an incentive to upgrade

Experiments are always a good idea, which is why it's important to be able 
to mix in experimental stuff without breaking other software.  (See, for 
example, X-foo: headers in mail messages.)  I just don't want to 
standardize stuff prematurely and find out that it's not what people need.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Aug 2006 14:12:37 -0700

On Aug 3, 2006, at 12:45 PM, John L wrote:

>>> "I sign all mail" ...
>>
>> As I've said before, there are really two different subclasses of  
>> this one. You can have your mail very well under control, but you  
>> don't have control over what the damage might be in transit. For  
>> some people like banks and phishing targets, that collateral  
>> damage is likely to be acceptable. For most everybody else it's not.
>>
>> So I guess it just intrinsically bugs me that the former is a  
>> pretty rarified class  of sender, and is SSP really _only_ for  
>> them? (leaving I send no mail aside).  Is there little or no value  
>> in knowing that you sign everything, but transit related damage is  
>> possible?
>
> We have to keep in mind that the recipient is interpreting this  
> stuff, and it's up to the recipient to decide what risk they are  
> willing to accept. Transit damage is always possible, so I don't  
> see any value in pointing that out.  As a receiver, I find a hint  
> that unsigned mail from you is probably bogus to be useful.  Your  
> own opinion of the value of that mail is not.

A method to indicate whether other services might be employed that do  
not retain the integrity of the signature and then do not sign or  
sign with a non-designated domain, or originate the message and then  
do not sign or sign using a non-designated domain would be helpful.   
Those with heavily phished domains may be willing to forego these  
related services that are producing such results.  A stipulation  
indicating such abstinence would be useful to the recipient.

> I also don't see "I sign everything" as limited to large  
> companies.  My lawyer is part of a small firm with their own mail  
> server on a leased line.  I expect they have enough sense to tell  
> people that if they want to send mail from home or on the road, use  
> the company's web mail.  They'd be a perfectly good candidate for  
> "I sign everything", and I don't think they're at all atypical.

When DKIM signing is offered by large ESPs, it would be in their  
interest to take the steps to securely authenticate and verify  
reception of the From address prior to use.  This extra effort would  
allow autonomous management of the email-address domain's  
relationship with that of this provider.  Those DKIM providers taking  
the extra step of confirming reception should attract more users and  
gain greater delivery acceptance.  This would also expand DKIM's  
coverage of From email-addresses at a faster rate.

The administrator for a law office could make a policy assertion that  
their "DKIM-SAFE" provider is a designated signing domain.  This  
would permit their staff to make use of this provider.  The law  
office would then be relieved from setting up outbound services or  
making complex arrangements.  A requirement that the From domain  
matches the signing domain could be supplanted by a policy statement  
that lists the "DKIM-SAFE" provider as a designated signing domain.

There would be no need to arrange zone delegations, or exchange  
selector and key information on a regular basis for this to work.  A  
designated signing domain that authenticates and confirms reception  
of the From email-address should be adequate.  This would be in lieu  
of separately establishing DKIM signing or the outbound provider  
selecting prearranged key/domain combinations to enforce From/signing  
domain alignment.

As far as reputation is concerned, there is safety in numbers.  DKIM  
done the right way should also reduce abusive traffic.  Unusual  
confirmation activity could warn that someone may be attempting to  
abuse their service.  Clean-up could be expunging the offending  
confirmed email-address and recommending a scrub to the user owning  
the account.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 05:30:11 -0400

----- Original Message -----
From: "John L" <[email-masked]>
To: "Michael Thomas" <[email-masked]>
Cc: "DKIM List" <[email-masked]>
Sent: Thursday, August 03, 2006 3:45 PM
Subject: Re: [ietf-dkim] A more fundamental SSP axiom

> that out.

I know what you mean John, but that is exactly what a major part of the
problem is.

"Transit Damage" comes in many forms, and the end result is that it adds a
lower
confidence for the receiver and the recipient-user.

Who is the recipient-user going to blame first when his ISP continues to
pass junk his way?

The industry direction for ISVs is to add more direct logic in this equation
and limit pass on the responsibility or risk to the user.   This is also
being coupled with a higher pressure by policitians for the ISP to take on
more responsibility.  I haven't looked at a particular bill status since it
was introduced last year, but ISPs will be required to AVS and security
software installed or they could be fined and liable for mal-practice.  This
is not being a lawyer, but straight forward High Tech/Law/IP industry
information that any responsible CTO must be kept abreast of.

So IMV, you do have to take a look what "transmit damage" really means. I
can understand that adminstrators don't have control over this, but for the
mail mover software vendors, it does.  The goal is to get all software from
point a to z working together with a new standard to maek DKIM work.

> a perfectly good candidate for "I sign everything", and I don't think

If you ask all your customers the simple question, "Do you want your domain
to be protected from any illegal or malicious representation or abuse?" I am
fairly confident you will get a resounding "Yes" as an answer across the
board.  Of course, followed up with "when do I get this update?"  <g>

John, I don't think anyone wants they domain, email address abused or
misrepresented. I know for my own personal experience, as a user of my own
products, that until it started to help to me, it was the final straw and I
began to do something I was philosophically and militantly against doing for
a long time - making decisions on what mail is good or bad.  So the ethical
compromise was to purely based decisions on technical SMTP compliance
considerations and not any subjected mail content intepretations. That we
pass on to our 3rd party AVS vendors.

That's the same design approach I am taking with DKIM-BASE and SSP/DSAP.
Trying to define all the administrator "use" cases will be nearly
impossible, but one thing that can be done is to define a mechanical
protocol with some enforcement protocols that the software are expected to
follow.  In my view, this isn't a hard problem. Complex? Probably expensive?
Requires coordination? Maybe, but not hard.  DKIM-BASE lays the ground work,
so now we need to see what it will take to make it work so that people will
begin to implement it.  Thats the problem to solve it.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 08:04:35 -0700

John L wrote:

>> this one.
> We have to keep in mind that the recipient is interpreting this stuff, 
> and it's up to the recipient to decide what risk they are willing to 
> accept. Transit damage is always possible, so I don't see any value in 
> pointing that out.  As a receiver, I find a hint that unsigned mail 
> from you is probably bogus to be useful.  Your own opinion of the 
> value of that mail is not.

I think my concern hinges on "probably". For a large domain like cisco 
"possibly"
would probably be closer to the truth meaning that it's certainly a good 
candidate
for higher scrutiny, but if your "probably" is good enough to reject, 
you'd defintely
have a high false positive rate -- from this mailing list if nothing else.

Part of the problem here is the past record of SPF with over-zealous 550 if
there's any hint of bogosity. We, for example, would be forced to take down
a "we sign everything" policy if that were to happen with DKIM -- even 
though
we'll be signing everything pretty soon. If there were a qualifier in 
the "I sign
everything policy" that specifically implies that sending a 550 based on 
a missing
DKIM signature alone is extremely bone-headed" then maybe we can both.
The current SSP has o=! t=y which could in a tortured way be construed to
have that semantic: "I sign everything, but hey I'm testing so take it 
for what
it's worth". If we have something more formalized, them maybe we can
accommodate these two pretty different scenarios.

       Mike

---

From: John L <[email-masked]>
Date: Fri, 4 Aug 2006 11:34:58 -0400 (EDT)

> a "we sign everything" policy if that were to happen with DKIM -- even though
> we'll be signing everything pretty soon. If there were a qualifier in the "I 
> sign everything policy" that specifically implies that sending a 550 based on a 
> missing DKIM signature alone is extremely bone-headed" then maybe we can both.

I don't see the point.  That last suggestion is, to the recipient, the 
equivalent of a useless "I sign some mail" since you're telling the 
recipient it's OK to accept some amount of both signed and unsigned mail.

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 08:44:10 -0700

John L wrote:

>> the "I sign everything policy" that specifically implies that sending 
>> a 550 based on a missing DKIM signature alone is extremely 
>> bone-headed" then maybe we can both.
>
>

For us, the amount of mail that is in the false positive quandry is 
really really
small, though the people it would effect primiarly are people who could make
it a living hell in IT. A policy which is more relaxed could, however, 
say that
it's well worth the effort be extremely cautious about such mail -- a 
far higher
barrier to entry than the current one-size-fits-all filters. This would 
be justified
because a) the high scruitiny class would be a small subset so that 
extra scrutiny
wouldn't incrementally cost much (if anything), and b) this is the kind 
of mail
that you really really want to be cautious about anyway since it's where the
phishing attacks are happening.

So no, I don't think it's useless at all. It provides a means to 
classify mail
in much more precise buckets so that the analysis budget can be more
sensibly divided.

       Mike

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 11:52:57 -0400

> recipient it's OK to accept some amount of both signed and unsigned mail.

+1

---

From: John L <[email-masked]>
Date: Fri, 4 Aug 2006 12:04:42 -0400 (EDT)

> really really small, though the people it would effect primiarly are 
> people who could make it a living hell in IT. A policy which is more 
> relaxed could, however, say that it's well worth the effort be extremely 
> cautious about such mail -- a far higher barrier to entry than the 
> current one-size-fits-all filters.

But you're talking about your own mail here, for which I expect that you 
have all sorts of special treatment.

I'm trying to think about what I'll do when DKIM is in wide use, I get 
mail from thousands of sources that publish SSP info.  If SSP says "I sign 
everything" I have trouble figuring a use for it other than a flat reject 
of unsigned messages or at least 4.9 points in a five point scoring spam 
filter.  I REALLY do not want an SSP that says "I sign everything, and 
here is my estimate on a 0 to 10 scale of how much you should care."

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 09:19:02 -0700

John L wrote:

>>> I don't see the point.  That last suggestion is, to the recipient, 
>>> the equivalent of a useless "I sign some mail" since you're telling 
>>> the recipient it's OK to accept some amount of both signed and 
>>> unsigned mail.
>>
>
>> relaxed could, however, say that it's well worth the effort be 
>> extremely cautious about such mail -- a far higher barrier to entry 
>> than the current one-size-fits-all filters.
>
>
> But you're talking about your own mail here, for which I expect that 
> you have all sorts of special treatment.

No, I'm concerned about how others will treat it. I don't have to publish a
policy to differentially treat that mail for myself.

> mail from thousands of sources that publish SSP info.  If SSP says "I 
> sign everything" I have trouble figuring a use for it other than a 
> flat reject of unsigned messages or at least 4.9 points in a five 
> point scoring spam filter.

That's the problem: if you do that, domains like Cisco -- or anybody else
who uses mailing lists -- will *never* publish a "we sign everything" policy
even though we do. I hardly think that Cisco is a outlier here, and in fact
I expect that we'd be pretty similar to just about any medium to large
sized business.

>   I REALLY do not want an SSP that says "I sign everything, and here 
> is my estimate on a 0 to 10 scale of how much you should care."

I assume that you'd complain if it boiled down to a single bit?

0: "mail from this domain may transit manglers, adjust accordingly"
1: "the signature should always be intact"

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 04 Aug 2006 17:16:20 +0100

John L wrote:
>  I REALLY do not want an SSP that says "I sign
> everything, and here is my estimate on a 0 to 10 scale of how much you 
> should care."

Is that because you can't trust the value, or because it opens up an
avenue for a spammer who'll get through if he keeps trying, or
because of something else? (Just wondering.)

Ta,
S.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 04 Aug 2006 09:12:54 -0700

John L wrote:
> sign everything" I have trouble figuring a use for it other than a flat
> reject of unsigned messages or at least 4.9 points in a five point
> scoring spam filter.  I REALLY do not want an SSP that says "I sign

Right.   SSP stands a much greater chance of being useful if it a) answers
questions we believe the receivers will want to have answered, and b) the
questions pertain to *simple* statements about signer/sender behaviors.

Certainly this kind of minimal model is essential for initial adoption and use.

d/

-- 

  Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Aug 2006 09:25:13 -0700

On Aug 4, 2006, at 8:34 AM, John L wrote:

>> Part of the problem here is the past record of SPF with over- 
>> zealous 550 if there's any hint of bogosity. We, for example,  
>> would be forced to take down a "we sign everything" policy if that  
>> were to happen with DKIM -- even though we'll be signing  
>> everything pretty soon. If there were a qualifier in the "I sign  
>> everything policy" that specifically implies that sending a 550  
>> based on a missing DKIM signature alone is extremely bone-headed"  
>> then maybe we can both.
>

John,

In your zeal for simplicity, you appear to be missing valid uses for  
a policy statement.  Mike correctly indicates a potential problem.

Think of the signing domain as representing a newspaper.  When the  
editor of this newspaper allows reporters to be liars, there would be  
primarily less trust in the newspaper.  The first party, from a trust  
aspect, is the newspaper's editor.  By the same token, it should not  
be a requirement that all reporters share the same last name as that  
of the editor.  Reporters should be allowed an easy means to appear  
in other newspapers.  To facilitate this, reporters should be  
provided a means to indicate what newspapers carry their stories.  A  
reporter may need to indicate that they freelance where other  
newspapers not listed may also carry their stories.

When a reader wonders whether the story they are reading in some  
unknown newspaper is really by the reporter they believe it to be,  
the reader could check the list of newspapers published by the  
reporter.  There can be three outcomes:

  1 - If the newspaper is on this list, then the reader has greater
      confidence in who wrote the story.

  2 - If the newspaper is not on this list, and the list is marked
      as being a complete, then the reader would know that the
      story is not likely by this reporter.

  3 - If the newspaper is not on this list, and the list is marked
      as not being complete, then the reader would then need to
      investigate the reputation of the newspaper's editor.

There is value having a list marked incomplete.  Perhaps a small  
population of readers will find the reporter's story in an unlisted  
newspaper.  In these case, the reporter would rather have the  
reputation of the newspaper's editor checked.  Without being able to  
mark the list incomplete, a report may find their story dismissed.   
This can be especially damaging when the reporter does a fair amount  
of freelancing.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 09:30:25 -0700

>Certainly this kind of minimal model is essential for initial adoption and use.
What I have yet to hear is any sort of consituency for a monolithic
"i sign everything" beyond the statements@bigbank scenario. I really
don't buy John's small lawfirm scenario unless he can swear that none
of their users or correspondents use Yahoogroups; nobody is going to
tolerate the false positives except for a narrow class of transactional
mail. As such SSP would be extremely narrow and unuseful for the vast email
population to the point of being: why bother?

In any case, I already outlined a scenario for which a receiver would
find the additional information very interesting.

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Fri, 4 Aug 2006 09:45:24 -0700

On Aug 4, 2006, at 9:19 AM, Michael Thomas wrote:

> John L wrote:
>
>>   I REALLY do not want an SSP that says "I sign everything, and  

0: "I sign some mail"

> 1: "the signature should always be intact"

1: "I sign all mail"

Cheers,
   Steve

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 12:40:56 -0400

> policy to differentially treat that mail for myself.

If I read this right, I think he was saying- Do unto others...

> 0: "mail from this domain may transit manglers, adjust accordingly"

So basically a 0 means: I have a published a record just so you have
to do more CPU/DNS work... because you are going to have to accept it
anyway.

> 1: "the signature should always be intact"

I think this should be assumed. If it's not, refering to the above-
Don't publish a record.

Regards,
Damon Sauer

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 09:50:22 -0700

> Don't publish a record.

I'm beginning to believe that that is the fundamental requirement. At
this point I have yet to see anybody say that they publish this kind
of record. In which case the simplest thing to be to declare victory
now and finish up months ahead of schedule.

       Mike

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 12:53:57 -0400

> > 0: "mail from this domain may transit manglers, adjust accordingly"

A 0 _still_ means: I have a published a record just so you have
to do more CPU/DNS work... because you are going to have to accept it
anyway.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 10:04:10 -0700

>> 0: "mail from this domain may transit manglers, adjust accordingly"

Incorrect. They are *not* the same statement. "some" may mean
in reality (and often does) "none". Versus our domain signing every
piece of legitimate mail even if some of the signatures get broken
due to mailing lists.

>> 1: "the signature should always be intact"

No. "I sign all mail" is merely a statement of fact. "should always be 
intact"
is predictive. They are *not* the same.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 10:08:47 -0700

> to do more CPU/DNS work... because you are going to have to accept it

I'm sorry: how exactly is a protocol forcing a receiver to do anything?
If you can explain that, then maybe there really is hope for 
strangulation-over-ip.

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Fri, 4 Aug 2006 10:09:58 -0700

> piece of legitimate mail even if some of the signatures get broken

If the signature is broken, the mail is not signed, so as far as the
recipient is concerned, they're the same. If you prefer the phrasing
"Some mail from me is signed", that works for me.

> No. "I sign all mail" is merely a statement of fact. "should always  
> be intact"

As far as the recipient is concerned, they are. If you prefer
the phrasing "All mail from me is signed", go with that.

(The underlying problem of DKIM+SSP being unable to avoid
false-positive rejections in almost all cases if "I sign all mail" is
asserted is becoming clear here).

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 10:11:51 -0700

> to do more CPU/DNS work... because you are going to have to accept it

Also: this formulation is completely bogus on its face: if you want to see
if a domain publishes a "I sign everything" policy, you have already done
that CPU/DNS work even if the answer comes back NXDOMAIN or
"we don't".

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 13:14:20 -0400

----- Original Message ----- 
From: "Michael Thomas" <[email-masked]>

> "i sign everything" beyond the statements@bigbank scenario. 

This is probably similar to what some bloke said years ago:

   "What I have yet to hear is any sort of consituency for
    checking the validity of HELO domain or the RETURN PATH.  
    After all, what possible problems can it bring?"

or as it is officially stated in RFC 2821:

   This specification does not further address the authentication issues
   associated with SMTP other than to advocate that useful functionality
   not be disabled in the hope of providing some small margin of
   protection against an ignorant user who is trying to fake mail.

That ignorant user is now $13B world wide problem!!

Why so resistance on having an exclusive policy?

---

From: John L <[email-masked]>
Date: Fri, 4 Aug 2006 13:21:52 -0400 (EDT)

>>  I REALLY do not want an SSP that says "I sign everything, and here is 
>> my estimate on a 0 to 10 scale of how much you should care."

> because of something else? (Just wondering.)

I don't know what a Care Value of 6 means, and I don't think anyone else 
does either.  And I'm quite confident that whatever my CV 6 means, it's 
not the the same thing as what your CV 6 means.

It may sound like I'm channelling Dave here, but I don't want to put 
anything into a protocol that doesn't have a straightforward operational 
value, and I don't think that "stir it into the mix in spamassassin" is 
straightforward.

R's,
John

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 13:24:22 -0400

> piece of legitimate mail even if some of the signatures get broken

You are missing my point: What good are the keys if the ones you are
handing me are to a Waffle House or 7-11?

> is predictive. They are *not* the same.

I was basing this comment on my previous comment that "I sign some
mail" is pointless. So if it is pointless, you now have a binary
choice. I sign all mail or I don't. If you don't, no need to publish a
record. Which as logic would have it, would mean that if you did have
a record, you sign all mail.

Damon

---

From: John L <[email-masked]>
Date: Fri, 4 Aug 2006 13:25:48 -0400 (EDT)

>> If SSP says "I sign everything" I have trouble figuring a use for it 
>> other than a flat reject of unsigned messages or at least 4.9 points in 
>> a five point scoring spam filter.

> even though we do.

And that's a problem because ... ?  There are all sorts of true statements 
that you can make about your outgoing mail, almost none of which are of 
any use to anyone else.  This appears to be one of them.

> 0: "mail from this domain may transit manglers, adjust accordingly"

That's not a bit, that's a fact of life.  None of us have any idea what 
paths our mail might take on its way through the mail morass.

> 1: "the signature should always be intact"

That's someone people could use operationally -- a suggestion to discard 
unsigned mail from you.

Regards,

---

From: John Levine <[email-masked]>
Date: 4 Aug 2006 17:35:38 -0000

>of their users or correspondents use Yahoogroups;

Well, actually, since Yahoo will certainly be DKIM signing its mail,
we can expect their reputation to be the one people use.  In the more
general case, if they publish we sign everything and don't have a
policy against using a work address to join mailing lists, they get
what they get.  Or if the only collateral damage is that people's
posts to Yahoo groups about embroidered kittens get lost, they won't
care.

> nobody is going to tolerate the false positives except for a narrow
> class of transactional mail. As such SSP would be extremely narrow
> and unuseful for the vast email population to the point of being:
> why bother?

Um, because there is a boatload of high value transactional mail? You
and I hardly send any transactional mail, but I recieve a whole lot of
it, and if it were easier to separate the real mail from HSBC from the
fake mail from HSBC, that would be nice.  Or you may be right and SSP
is useless, which has been my feeling all along.

>find the additional information very interesting.

Speaking as a receiver, I have to say I didn't find that info either
useful or interesting.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Aug 2006 11:00:11 -0700

On Aug 4, 2006, at 10:25 AM, John L wrote:

>> That's the problem: if you do that, domains like Cisco -- or  
>> anybody else who uses mailing lists -- will *never* publish a "we  
>> sign everything" policy even though we do.
>
> And that's a problem because ... ?  There are all sorts of true  
> statements that you can make about your outgoing mail, almost none  
> of which are of any use to anyone else.  This appears to be one of  
> them.

A financial institution being heavily phished may wish to explicitly  
state:

"SIGN ALL MAIL" and "DO NOT USE ANY SERVICES KNOWN TO DAMAGE THEIR  
SIGNATURES"

Cisco may wish to only state:

"SIGN ALL MAIL"

The important difference is whether the assertion is _expected_ to  
cover all possible sources carrying their messages.

-Doug

---

From: John L <[email-masked]>
Date: Fri, 4 Aug 2006 14:03:04 -0400 (EDT)

> The important difference is whether the assertion is _expected_ to cover all 
> possible sources carrying their messages.

The more important difference is that recipients can do something based on 
the first statement but not on the second.

Regards,

---

From: John L <[email-masked]>
Date: Fri, 4 Aug 2006 14:05:11 -0400 (EDT)

a) "SIGN ALL MAIL" and "DO NOT USE ANY SERVICES KNOWN TO DAMAGE THEIR SIGNATURES"

b) "SIGN ALL MAIL"

I want to put "ALL MAIL HAS TOM SWIFTIES" in my SSP.

Assuming you agree that's ridiculous, what's the practical difference to 
people using SSP between that and b) above?

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Aug 2006 11:21:17 -0700

On Aug 4, 2006, at 11:03 AM, John L wrote:

> The more important difference is that recipients can do something  
> based on the first statement but not on the second.

Imagine that policy takes the form of a list that can either be  
declared as partial or complete.  In the case of a partial list,  
although that information will not aid the blocking of messages  
outright, it can still serve to clarify genuine relationships between  
the From email-address domain and the signing domain when they  
differ.  A partial list indicates that recipients should consider the  
reputation of the signing domain instead of blocking messages when  
this relationship is not established.  On the other hand, a complete  
list indicates that recipients need not consider the reputation of  
the signing domain and can blocking messages when the relationship is  
not established.  Although a complete list offers greater utility,  
for general use a complete list is not very practical assertion for  
most domains.

-Doug

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 14:22:31 -0400

> "SIGN ALL MAIL" and "DO NOT USE ANY SERVICES KNOWN TO DAMAGE THEIR

We really really really mean it when we say "Sign all mail"

> Cisco may wish to only state:

We _dont_ really really mean it.

So if the sig comes in munged, we will leave it up to the receiver to
decide what to do with it.
As a real live postmaster, thank you for giving me more work to do.
Because operationally, I would treat an email with a munged sig, the
same way I would a message without a sig or "Sign some mail". Possibly
even with more malice.
I really don't have all day to go through all the "special cases" so
the only ones that get my attention are the ones we really really
needed.
So operationally, it would be easier to just treat everyone as "Sign
sometimes" except for those that really really really mean it.

Regards,
Damon

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 14:39:23 -0400

> for general use a complete list is not very practical assertion for

 That is the sender suggesting how I should handle the message on a failure.
I already consider the reputation of the sending domain/ip. If I was
now going to have to start considering the reputations of signing
domains (if they are seperate) I certainly would not leave it up to
the sender to tell me how to do it... unless.. the policy list is
_always_ more restrictive.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Aug 2006 11:55:31 -0700

On Aug 4, 2006, at 11:05 AM, John L wrote:

> Assuming you agree that's ridiculous, what's the practical  
> difference to people using SSP between that and b) above?

The From email-address DKIM policy represents a partial or complete  
list of signing domain (valid sources).  Whether partial or complete,  
this list might allow recipients to verify that 90% of the From  
domains have a valid association with the signing domain.  This  
leaves a remaining 10% that must be treated according to the  
reputation of the smtp client or a non-designated signing domain.   
However, a client DKIM policy transaction offers a means to greatly  
improve the odds of blocking abuse with DKIM.

Require that all DKIM client use a "_dkim.<host-name>" that can be  
verified with a simple Address record lookup.  This would enable a  
DKIM client policy.  The DKIM client policy can assert "ONLY SEND  
SIGNED DKIM MESSAGES."  A client that does not authenticate or does  
not sign with DKIM can then be blocked.

DKIM client policy will prevent a significantly greater number of  
abusive messages without creating delivery issues for valid  
messages.  For DKIM to succeed, it must not cause delivery problems  
or support issues.

-Doug

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 14:51:58 -0400

On 8/4/06, Damon <[email-masked]> wrote:
> > declared as partial or complete.

But I am with Doug in that, without policies, SSP is useless.
Without policies, I would treat everyone in the world as "Sometimes
Sign" and listen to those insignificant few who really really mean it
when they say "Sign All"
You can try expanding that all you want, but unless it is right
_every_ time, there is no point in having it.

Regards,
Damon Sauer

---

From: <[email-masked]>
Date: Fri, 4 Aug 2006 15:15:05 -0400

One would assume that an additional signing algorithm has been introduced and not using the TOM SWIFTY algorithm I would refer to base and treat your message as unsigned.
thanks,

-----Original Message-----
From: [email-masked] on behalf of John L
Sent: Fri 8/4/2006 2:05 PM
To: DKIM List
Subject: [ietf-dkim] SSP thought experiment

b) "SIGN ALL MAIL"

Regards,

---

From: John L <[email-masked]>
Date: Fri, 4 Aug 2006 15:34:19 -0400 (EDT)

> One would assume that an additional signing algorithm has been introduced and not using the TOM SWIFTY algorithm I would refer to base and treat your message as unsigned.

Who said anything about signing algorithms?  You know it's really from me 
because there's a lame Tom Swifty at the end of each message. 
Determining the operation utility of this advice or lack thereof is left 
as an exercise.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Fri, 04 Aug 2006 13:09:24 -0700

>> "i sign everything" beyond the statements@bigbank scenario. 

For reference, we probably DO need to do some consensus assessments.  I think
that there have been some clear preferences by the working group, but I think
they have not been formally stated, assessed and accepted by the working group.

d/

-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 04 Aug 2006 13:11:03 -0700

> value, and I don't think that "stir it into the mix in spamassassin" is

It ain't me.  It's a long-standing pattern of what gets deployed and used.

So if there is any channeling, we are both doing it, on behalf of the God of
Successful Protocols...

d/
-- 

  Dave Crocker

---

From: wayne <[email-masked]>
Date: Fri, 04 Aug 2006 15:54:37 -0500

In <[email-masked]> Michael Thomas <[email-masked]> writes:

> Part of the problem here is the past record of SPF with over-zealous
> 550 if there's any hint of bogosity. We, for example, would be
> forced to take down a "we sign everything" policy if that were to
> happen with DKIM -- even though we'll be signing everything pretty
> soon.

Based on the past record with SPF, is the any reason to believe that,
people won't treat "I sign some email" as the same as "I sign all
email" and reject email that does not have a valid first party
signature?  There are certainly lots of people who treat publishing
SPF records that end in NEUTRAL more harshly than not publishing SPF
records at all and this has caused at least one major ISP to remove
their SPF records.

(Yes, this is assuming DKIM reaches the same level of deployment that
SPF had back in early 2003.  There isn't much danger right now.)

>       If there were a qualifier in the "I sign everything policy"
> that specifically implies that sending a 550 based on a missing DKIM
> signature alone is extremely bone-headed" then maybe we can both.

This is somewhat along the lines of SPF's SOFTFAIL.  You will find
some people who reject based solely on seeing a SOFTFAIL and you will
find others claiming that SOFTFAIL is functionally equivalent to
NEUTRAL.

> The current SSP has o=! t=y which could in a tortured way be
> construed to have that semantic: "I sign everything, but hey I'm
> testing so take it for what it's worth". If we have something more
> formalized, them maybe we can accommodate these two pretty different
> scenarios.

Expect people to ignore the t=y flag also.

Really, anyone who thinks that signing email with DKIM (or DK or IIM)
will not directly cause some of your valid, non-spam, email to be
rejected is fooling themselves.  Receivers are free to do whatever
they want with their servers, including extremely bone-head things.

Personally, I think there is some value in distinguishing between "I
sign everything and never send to mailing lists and other know
mungers", "I sign everything, but also send to known mungers", and "I
know I don't sign everything".

-wayne

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 13:57:01 -0700

> We _dont_ really really mean it.

You and others seem to be having a big problem differentiating between
signing and verifying. I can make a perfectly valid statement that I
sign all of my mail. There is no guarantee that it will survive intact.
Period. Once it's left my domain, I have no control of what intermediaries
do. This is a fact of life, and no amount of glib dismissals or fanciful
reinterpretations of that true statement says alters that.

       Mike

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 17:06:40 -0400

> reinterpretations of that true statement says alters that.
Mike,

You are absolutely and positively correct and _that_ is my problem.
"Sign all mail" is a pipe dream (as you have stated) unless you have
utter control over where it goes and how it gets there. So what is the
point of saying "Sign All" unless you can and ensure it gets there
intact?
Which causes me to repeat myself... Treat everyone default as
"Sometimes Sign" and only set "Sign All" only if you really really
mean it - and are willing to deal with the consequences. Isn't that
what is really going to be happening anyway?

Regards,
Damon Sauer

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 17:16:34 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "John L" <[email-masked]>

> So if there is any channeling, we are both doing it, on behalf of
> the God of Successful Protocols...

Yes, that's true, but we are here fixing things up.  :-)

This time around, lets be even more conservative and not pass on the future
DKIM "Ignore failure" debt to our children.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 14:35:57 -0700

>know I don't sign everything".
Absolutely -- there are all kinds of stupid thing that receivers do and we
can't do anything about them other than try to educate them that that is
wrong. If we just come up with a policy which is "I sign everything" with
no nuance of the kind of people who can and might make that statement,
we're probably worse off than we are now because senders and receivers
will not agree on what it means. Even if we end up _not_ having a way
to publish non-transactional-goes-through-mungers mailers, we can be
guaranteed that there will be lots of confusion by people who really do
sign everything and set that policy only to be punished -- erratically --
by receivers.

          Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 14:25:57 -0700

Damon wrote:

> utter control over where it goes and how it gets there.

No. *Verifying* all mail that was once upon a time correct will be
a long time a coming.

> So what is the

Nobody can once it's outside of your control. I can make a statement
about what I do though, and a receiving piece of software might
be able to make use of that (nb, not the postmaster) as an input
function to all of the rest of the things it considers.

> what is really going to be happening anyway?

Not necessarily. It's not hard to envision a piece of software that
knows that something that ought to be signed needs differnt treatment.
Consider the current dkim policies:

o=~  (sign some)
o=!; t=y;   (sign all, but testing)
o=!; t=n;   (sign all, not testing)

In spamassassin terms,  I might assign:

SSPPOLICY_SIGNSOME 0
SSPPOLICY_SIGNALLTESTING 2
SSPPOLICY_SIGNALLNOTTESTING 10

In the first case, they're telling me to not bother with DKIM because it 
will
be unreliable. In the second case, the signing domain saying that they sign
everything means that there's clearly something amiss and that it would be
good to bias it toward rejection. The third case is the signing domain 
saying
that they'd rather it fail than be accepted.

Thus there really is the potential for a receiver to make use of the two 
flavors
of  SIGN ALL.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 14:48:43 -0700

>posts to Yahoo groups about embroidered kittens get lost, they won't

In other words, you really have no clue as to how these people use email
and what the collateral damage would be. The average small firm/company
doesn't even understand the difference between a mailing list, a blog
or a discussion board. And you expect them to be able to make an informed
decision?

>Speaking as a receiver, I have to say I didn't find that info either
I wasn't aware that you wrote spam filters for a living.

       Mike

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 17:53:35 -0400

> that they'd rather it fail than be accepted.

Which is why I tell my CEO always send the important stuff via FedEX.
(I own stock ;)

Wouldn't it be safer not signing?

On the other hand....
Being an operational guy, I know that 99.999^nth% of my mail is going
to make it unmunged. But I hear so much "sky is falling" that I get
caught up in it too.

But what you are talking about is good mail. Mail we know is good
going bad due to some technical hiccup.
What I am concerned with is the bad mail being treated at the same
level as the good mail. I have to weigh my options....

Do I make my scores very high for failed sig checks and treat someone
who /thinks/ they are going the extra mile to ensure their mail is
getting better treatment at the receiving end by signing it- is
getting exactly the opposite of what they expected to happen because
some two-bit system munged their sig in-between. This mail gets
junked, their reputation takes a hit, and the powerpoint they needed
for today's meeting doesn't get there.

Or

Is this just another luke-warm protocol, that is going to be a pain in
the rear to implement and maintain, just so I can add a few measly
points to their score?

I see room for improvement... lots of room. I can see adding policy to
the record or to the DKIM header.. or both that can provide a
"secondary" check or what to do if the record is munged. I like those
ideas. I can start putting teeth back into my scoring

Regards,
Damon Sauer

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 17:57:41 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Damon" <[email-masked]>

> SSPPOLICY_SIGNALLNOTTESTING 10

and this is what you and others administrators seems to completely ignore.

Before SpamAssasin, comes 2821/SMTP and it will be a Donald Trump "HUGE"
mistake believing Payload abuse is going to be tolerated. Payload abuse
promotes bounce-attacks, lowers the scalarability of operations, and builds
the confidence level of bad guys to bombard systems that depends on
post-smtp MFA frameworks.

I personally don't care how its worded, we are talking about "exclusive"
domain operational considerations where Mail Integrity is still an important
concept in mail systems.  Junk will not get pass 2821.

Regarding testing:

 4.7.  DSAP Tag: t=y

   The t=y tag is optional.  If defined, the domain is currently testing
   DKIM.  Verifiers SHOULD NOT treat testers any different from
   production mode signers.  It SHOULD NOT be used as a way to bypass a
   failed signature classification policies.  However, verifiers SHOULD
   track testers for over extended usage of test signatures and MAY
   consider using the results to provide feedback to the domain.

And other words, the testing flag will not be tolerated as well.

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 18:08:25 -0400

> And other words, the testing flag will not be tolerated as well.

Whew Hector,

 I see what you are getting at but... have any idea how many domains I
am currently tracking for reputation?! How long would I have to keep
that data?
The bots would cause me to get google size boxes alone.
Reminds me of the time I suggested a "auto-expiring" DNS tag. That
went over like a lead balloon.

 Is there another way you could do this?

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 18:14:12 -0400

Or if the only collateral damage is that people's
> posts to Yahoo groups about embroidered kittens get lost, they won't

I am going to go post on the Yahoo embroidered kittens group that John
doesn't care about them or their dang cute and cuddly,
hand-lovingly-stitched, fuzzy kittens with little pink noses.

:-D

---

From: John L <[email-masked]>
Date: Fri, 4 Aug 2006 18:07:50 -0400 (EDT)

> or a discussion board. And you expect them to be able to make an informed

I have a pretty good idea how lawyers use e-mail, since I do a fair amount 
of expert witness work and do all of the routine stuff (i.e., not of 
interest to opposing lawyers) by e-mail.  Lawyers exchange some of the 
highest value e-mail of anyone, case management messages with courts and 
other law firms.  If one of those messages gets lost, it can mean that the 
lawyer loses a case by default.  This is not a hypothetical concern; see 
my blog entry at http://weblog.johnlevine.com/Email/barge.html

So if "sign everything" SSP makes their point to point mail more reliable, 
law firms will use it in a millisecond.  If it means that some other 
people won't see some messages they send to mailing lists, they won't 
care.  If, as I suspect will be more likely, their correspondents will 
ignore SSP and whitelist mail from organizations they know, they won't 
bother.  If a law firm elects to accept e-mailed notices from a court, 
there's a multi-step process to ensure that the mail works, and it'd be an 
obvious place to add people a local whitelist.  But it's a decision they 
can reasonably make for good business reasons.

> I wasn't aware that you wrote spam filters for a living.

I wasn't aware that "receiver" was a synonym for "commercial spam filter 
vendor."  One learns something new every day.

R's,
John

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 4 Aug 2006 15:21:12 -0700 (PDT)

> Is there another way you could do this?

The above text should have had "MAY" in place of "SHOULD", i.e.

    The t=y tag is optional.  If defined, the domain is currently testing
    DKIM.  Verifiers SHOULD NOT treat testers any different from
    production mode signers. It SHOULD NOT be used as a way to bypass
    a failed signature classification policies. Verifiers MAY use
    this flag when tracking usage of test signatures and consider
    using the results to provide feedback to the domain owner.

In other words if program you have already has capability to track
usage you should than use 't' flag as part of that data. If you do
not have capbility to track usage or do not want to use it, then
you would not care about it.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 15:23:23 -0700

John L wrote:

> I have a pretty good idea how lawyers use e-mail, since I do a fair 
> amount of expert witness work and do all of the routine stuff (i.e., 
> not of interest to opposing lawyers) by e-mail.  Lawyers exchange some 
> of the highest value e-mail of anyone, case management messages with 
> courts and other law firms.  If one of those messages gets lost, it 
> can mean that the lawyer loses a case by default.  This is not a 
> hypothetical concern; see my blog entry at 
> http://weblog.johnlevine.com/Email/barge.html
>
> So if "sign everything" SSP makes their point to point mail more 
> reliable, law firms will use it in a millisecond.  

I cannot see how SSP can do anything but make false positives more likely.
The real question is whether the gain in eliminating harmful mail is 
worth the
occassional  false positive. So if what you are saying is true,  law 
firms would
be literally nuts to turn SSP "I sign everything" on, and  so I'm 
surprised to hear
that you think they should.

> I wasn't aware that "receiver" was a synonym for "commercial spam 
> filter vendor."  One learns something new every day.

Meaning that your opinion of utility is not the sole gauge of utility. In
fact, you probably benefit a lot from people who find utility in things that
you don't care about to keep your mail mostly spam free.
   
    Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 18:29:49 -0400

----- Original Message -----
From: "Damon" <[email-masked]>
To: "Hector Santos" <[email-masked]>

>  Is there another way you could do this?

Well, the whole idea for testing is a migration concept, which implies, a
system exposes an attribute that  they are "testing" should be a time
limited operation.

The idea of saying "Look buddy, pardon my mistakes but I am testing so
please don't reject my errors"  is inherently risky to allow indefinitely.

I suggest a time limit concept for implementations as I suggested the same
with SPF to modify the Migration write up to include a default expiration
concept for migration.  I left it open ended but cited examples of 3, 6
months.  This would be for verifiers to implement.  But you wanted to
document this for senders to understand that there is a LIMIT on testing.
See example below:

Back in MARID, I suggested how one could develop a business model on
reporting by charging systems to obtain feedback and I said this
facetiously, because if someone wants a report, they will have to pay for
any overhead involved.   The bad side is that this may be a cat's meow for
the Direct Marketing industry.  They will love to get as much feedback as
they get can. So they might pay a few pennies or whatever to get reports.

Example where Testing is abused:

Check out Microsoft's Callerid record - it is still under testing after two
years!!! <g>

V:\rfc\dkim>nslookup -query=txt _ep.microsoft.com

Non-authoritative answer:
_ep.microsoft.com       text =

    "<ep xmlns='http://ms.net/1' testing='true'><out><m>"
      "<mx/><a>213.199.128.160</a><a>213.199.128.145</a>
       <a>207.46.71.29</a>
       <a>194.121.59.20</a>
       <a>157.60.216.10</a><a>131.107.3.116</a>
       <a>131.107.3.117</a>
       <a>131.107.3.100</a>"
       "</m></out></ep>"

I guess some engineer at MS forgot to remove it. :-)

But this is what I am talking about where a testing flag should not be
tolerated.

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 18:39:51 -0400

> you don't care about to keep your mail mostly spam free.

Really banging my head on this one... the only way I see this working
100% every time is an RFC change to the MTA protocol where DKIM
becomes part of the handshake.

 I see the MTAs willing to take the risk of adding "I SIGN ALL" as the
ones that would be harmed the most with its failure.

Regards,
Damon Sauer

---

From: John L <[email-masked]>
Date: Fri, 4 Aug 2006 18:44:34 -0400 (EDT)

> I cannot see how SSP can do anything but make false positives more 
> likely. The real question is whether the gain in eliminating harmful 
> mail is worth the occassional false positive. So if what you are saying 
> is true, law firms would be literally nuts to turn SSP "I sign 
> everything" on, and so I'm surprised to hear that you think they should.

At the moment, I agree with you.  Considering the value of the messages, 
I'm surprised we don't see more fake mail saying that a case has been 
dismissed or a hearing postponed.  If that happened, the answer might be 
different.

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 15:42:44 -0700

> ones that would be harmed the most with its failure.

I'm sorry, but I don't understand this at all.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 15:54:51 -0700

John L wrote:

>> mail is worth the occassional false positive. So if what you are 
>> saying is true, law firms would be literally nuts to turn SSP "I sign 
> At the moment, I agree with you.  Considering the value of the 
> messages, I'm surprised we don't see more fake mail saying that a case 
> has been dismissed or a hearing postponed.  If that happened, the 
> answer might be different.

Ah, that sounds a *lot* more like they want whitelists than SSP. In any 
case, if
that became prevalent you wouldn't want the defaultish disposition of "I 
sign
everything" to be reject. There would  be far too high a risk for a 
false positive
if what you're saying is true. The best you could hope for is to hope 
all of your
whitelisted domains get through mostly unscathed and then slavishly go 
through
the potentially spoofed ones, mostly likely with wetware. This is, of 
course, a
hard problem and DKIM is only likely to go so far as to help it.

       Mike

---

From: Mark Delany <[email-masked]>
Date: Fri, 4 Aug 2006 23:15:26 +0000

On Fri, Aug 04, 2006 at 06:44:34PM -0400, John L allegedly wrote:
> >mail is worth the occassional false positive.

I guess I'm a little confused about the false policy concern.

If a signer wants to take that risk, isn't that for them to decide?

Also, if the usual strategy of a verifier is to bounce (or be
encouraged to bounce) the offending email, a "I sign all" sender will
almost always know about delivery failures of originally signed
traffic and be able to act accordingly.

Mark.

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 19:34:35 -0400

> If a signer wants to take that risk, isn't that for them to decide?

Yes but.. I don't think that everyone is going to be aware of the risk
or ignore it thinking it can't happen to them. I still haven't stopped
smoking even though the Surgeon General puts all that scary warning
stuff on my smokes. It can't happen to me...

> traffic and be able to act accordingly.

I like the bounce idea too, but then we get into the whole attack
thing. Some poor schmuck with a little sparc2 trying to handle all the
verifier bounce traffic from ohh. let's say... Yahoo ;)

Damon

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 19:45:57 -0400

> stuff on my smokes. It can't happen to me...

I want to add a little more...

It would also be ok if there was an alternative that was useful... and
will just refer to my previous posts as to why I thing "I SIGN SOME"'s
value is not worth the expense.

So without adding flags or some doable mechanism for how to verify the
DK even if it's munged.. I can't see the value in SSP as a whole.
And you know me!... I really would like to see it work. I am not
trying to torpedo it for some ulterior motive.

Regards,
Damon Sauer

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 4 Aug 2006 17:28:30 -0700 (PDT)

> value is not worth the expense.

Before you said you want "I sign some if it comes from this 
server/network". Coming back to this issues, the problem here
is that if signature was actually added and server name is
available you already know it signed it. If the signature is
missing you can't tell it came from that server unless you examine 
Received trace data (unreliable and per RFCs not to be used for
email processing although almost every anti-spam software in
practice violates this now..) or violate RFC2821 session/RFC2822
DATA separation.

Can you think of somethubg else for use in <here> you'd like to
see as part of either
  "I sign all" <here> but may not sign in other cases
  "I sign all" except <here>

Personally cases I see are:
  1. I either sign all myself OR these guys <list domains> sign on
     my behalf
     a. In some special cases it can also be I sign all myself AND
        one of these guys <list domains> will also sign it
  2. I always sign if it comes from[*] <list email address> but
     otherwise I may not add a signature
  3. I always sign when it goes to[*] <list email addresses> but
     otherwise I may not add a signature

[*] From and To are general concepts here and do not necessarilly
     imply "From" and "To" header field specifically

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 20:33:41 -0400

>     imply "From" and "To" header field specifically

Gets a 'Thumbs Up' from me... I like it a lot.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 20:49:54 -0400

> >     imply "From" and "To" header field specifically

My only question is... where are you going to put all those rules?
I remember having a terrible time with a reverse that went back to
500+ domains my DNS kept timing out before I could get to the bottom
of the list.
Should you or could you put a limit on the number of domains?
And if you did, where would you put the extra?
This is why I went with the CIDR idea when we did SPF. You can have
1000 domains pointing at the same IP all owned by the same guy AND be
legit.
In this case wouldn't it be better to put in an IP?

Regards,
Damon Sauer

---

From: Graham Murray <[email-masked]>
Date: Sun, 13 Aug 2006 09:12:41 +0100

Michael Thomas <[email-masked]> writes:

> I really don't buy John's small lawfirm scenario unless he can swear
> that none of their users or correspondents use Yahoogroups;

As Yahoo is supposed to be one of 'sponsors' of DomainKeys and DKIM,
should they not put their own house in order and fix Yahoogroups so
that it does not break DKIM? 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html