Subject: Re: [ietf-dkim] The mystery of third party signatures

From: Franck Martin <[email-masked]>
Date: Wed, 7 Oct 2009 10:08:31 +1200 (FJT)

Practicalities, which explained the failure of PGP and S/MINE. Great protocol, except they are unworkable for the common user, like most security protocols coming out of IETF (and it is not me who is saying it but I heard it in a variation from Stephen Squires)

The people that want the signing, are not the people that manage the mail server(s) and even less the people that manage the DNS. Now good luck to get them all on a conference call and explain they have to rework their priorities and make all that work.

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Bill Oxley" <[email-masked]>
Cc: [email-masked], [email-masked]
Sent: Wednesday, 7 October, 2009 8:46:57 AM GMT +12:00 Fiji
Subject: Re: [ietf-dkim] The mystery of third party signatures

On 10/06/2009 10:30 AM, [email-masked] wrote:
> C) I can sell the ability to do 3rd party DKIM signing for those companies who are described in A)

If you're getting paid for signing somebody else's traffic, doesn't
it make sense that the service can do some hand holding to get their
DNS set up correctly? In fact, if you're handling their DNS too
-- which seems likely on average -- what exactly is the problem?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Oct 2009 15:22:11 -0700

> The people that want the signing, are not the people that manage the mail server(s) and even less the people that manage the DNS. Now good luck to get them all on a conference call and explain they…

Yeah, yeah, been there, accomplished that. I still don't buy it. People who are *really*
clueless completely outsource their email, including their MX record management as well.
If those outsourcers can't deal with DKIM... they should probably find another outsourcer
who can.

All of this is rather academic though: the big guys are signing now because they can
find some biz justification to do so. Until that biz justification percolates down,
it doesn't really make much difference what we do. When it does, the DNS "problem"
will evaporate.

Mike

> From: "Michael Thomas"<[email-masked]>
> To: "Bill Oxley"<[email-masked]>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Oct 2009 16:36:41 -0400

Mike says...
> it doesn't really make much difference what we do. When it does, the DNS "problem"

I think this is really the bottom line.  Deployment difficulties and
delays always show up with new things.  If the new thing becomes
popular, the difficulties go away, and we wonder why we ever had
trouble with them.

S/MIME has been brought up as an example of the difficulty, and it
actually helps show how this works: there isn't much trouble with
S/MIME any more, not directly.  Most mail programs support it now
(alas, not Gmail), and the level of interoperability is good.  The
trouble now isn't with S/MIME, but with certificate distribution and
management.  There's also very little need for most people to use
S/MIME with most of their email.

DKIM replaces the problems of key management and distribution with DNS
management issues.  Service providers should be used to dealing with
DNS, so these problems should, as Mike says, get sorted out when the
providers see enough of a reason to use DKIM.

I'm not in favour of complicating the protocol, when we can do what we
want to do with what's there.  I'd really need to see significant new
use cases to drive any major change here.

On the other hand, I'd see nothing wrong if someone should want to
write a draft about mailing-list considerations, and propose it as a
working group item.  But I'd want to see it as a draft that we can
review, not just as a few ideas in an email message.

Barry, as participant

---

From: Doug Otis <[email-masked]>
Date: Wed, 07 Oct 2009 13:55:53 -0700

> review, not just as a few ideas in an email message.

A third-party authorization/policy mechanism will not alter the base 
DKIM specification.  I will be happy to clean up the old tpa draft for 
something at which to throw darts.

In my prior email to Daniel, I meant to say that the simple label 
approach is _uncertain_ of then imposing an unreasonable domain length 
constraint.  Where as, the hashed label approach changes the reduction 
that would be greater than 50%, to a reduction of less than 20%.  In 
addition, these the limits would be obvious when authorizing any domain.

-Doug

---

From: hector <[email-masked]>
Date: Wed, 07 Oct 2009 17:08:44 -0400

> something at which to throw darts.

Why bother? These were never was a "few ideas in email messages" but 
real drafts over the last few years.  There has been server write ups 
DRAFT  on mailing list considerations.  There is nothing new here and 
Barry has shown where he stands before and once again. As long as 
Crocker and Levine don't believe in Policy, never did and never will, 
it "ain't going anywhere" and Barry, no one, can't change that 
unfortunately.

It is what it is.

In Other words, if not even RFC 5617 (ADSP) can be supported by its 
author and the main "test bed" mailing list, mipassoc.org DOES NOT 
RESPECT RFC 5617, then whats the point?

--
hls

---

From: hector <[email-masked]>
Date: Wed, 07 Oct 2009 17:23:08 -0400

> use cases to drive any major change here.

DKIM implementation is already complex and confusing.  The goal of 
policy was to make it protocol consistent, "easier" and give it a real 
purpose.

This isn't about "use cases" but business methodologies - allowing for 
opened ended signing "passthru" machines vs having author domain 
controls over that signing process.

> review, not just as a few ideas in an email message.

Barry, there has been drafts written on Mailing List Server (MLS) 
considerations.  But it all a moot point if RFC 5617 will not be 
honored by the MLS.

--
HLS

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 08 Oct 2009 13:48:02 -0600

> use cases to drive any major change here.

+1

> review, not just as a few ideas in an email message.

+1

Whoever wants to take on this project should feel free to borrow from the 
article I wrote in June:

http://www.circleid.com/posts/dkim_for_discussion_lists/

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 08 Oct 2009 16:01:58 -0700

> http://www.circleid.com/posts/dkim_for_discussion_lists/

J.D.

This approach still leaves problems related to ADSP policy restrictions 
running afoul with any mailing-list that modifies (flattens) message 
formats to ensure consistent presentation.

Since many readers of these lists are likely to prefer consistent 
formatting, modified subject lines, and subscription links at the end of 
the message, this is likely to cause DKIM policies to run afoul of 
mailing-lists when they publish any restrictive ADSP assertion.

I have just updated the tpa draft aimed at offering a direct remedy for 
this problem which does not depend upon receivers knowing which mailings 
lists to trust, although we are both in the business of offering this 
advice. :^)

http://www.ietf.org/id/draft-otis-dkim-tpa-label-01.txt

Version 00 of this draft was poorly defined.  I hope the simplified 
definitions make it a bit more understandable.  The off-line feedback 
was appreciated.

-Doug

---

From: hector <[email-masked]>
Date: Fri, 09 Oct 2009 21:53:14 -0400

J.D. Falk wrote:

> Whoever wants to take on this project should feel free to 

 > borrow from the article I wrote in June:

> http://www.circleid.com/posts/dkim_for_discussion_lists/

J.D, the issue with your suggestions is that once again, there is 
ignorance of RFC 5617 ADSP policies by list receivers and especially 
resigners.  At least I don't see any implication for RFC 5617 support 
in your outline.

IMTO, before any automated concept can work well, the supportive DKIM 
network must expect protocol consistency to be established among all 
DKIM nodes.  The receiver MTA or node that will receive and provide 
DKIM verification processing SHOULD honor RFC 5617 if they are going 
to resigned, then it MUST support RFC 5617.

Consider this real situation that happen a few weeks ago.  It opened 
my eyes in how RFC 5617 MUST be interpreted and has altered how it 
must be implemented for our mail API system.

This occurred with the DKIM-DEV list I am subscribed to. I forget the 
exact reasons but the end result is that my MDA began to reject my 
copy of the DKIM-DEV list distributed mail  I thought the sender was 
white listed as I receiving mail fine in the past.

But something changed on either end and I received an automated final 
warning notification that my subscription would be moved if I don't 
response to the notification (click the url and confirm I am a real 
person).  It was odd the notification got thru but normal distribution 
were rejected. So I fixed that by adding more white listing rules for 
this list sender.

That got me thinking about RFC 5617 support as it was being 
implementing as part of our SMTP level scripting filter language.

Out of the box, our inbound MTA will run the "DKIM SCRIPT"  at the 
SMTP level.

So imagine, if a resigned mail was received from mipassoc.org for a 
author domain that happens to have a ADSP = "DISCARD" or "ALL", then 
this would be a failed DKIM/ADSP transaction.

It was already troubling that a list server would not honor RFC 5617, 
but now I saw how the list server can now begin to send notifications 
to subscribers for rejected mail.

If the inbound MTA issues a 55x rejection, then what will happen is 
the MLS will begin to send notifications threatening to auto-remove 
subscribers who's MDA are rejecting the resigned mail.

So I see three possible mitigating options:

1) Update RFC 5617

  1.a) All DKIM-BASE compliant receivers SHOULD supprt RFC 5617

  1.b) All DKIM Resigners MUST respect RFC 5617

  1.c) All receivers who support RFC 5617 MUST use post
       message acception silent discarding of mail and not use a
       SMTP level rejection to avoid bounce issues and mail list
       subscription removals.

2) Extend RFC 5617 with an explicit 3rd party signing option.

3) Deprecate RFC 5617

    If list server developers or operators are not expected to
    support or honor RFC 5617, then we SHOULD declare RFC 5617 has
    as non interoperable with DKIM-BASE, deprecate it and remove
    it from standard track.

Ideally, I think #1 is required if we are going to keep it. I think 
should also be considered as well.

But I don't think we can stick with RFC 5617 if resigners are not 
going to support it when random receivers might support simply because 
its there!

So #3 is an option I am hoping the opponents of policy will finally 
see a legitimate reason to get rid of ADSP.   I saw that because I 
would rather to get rid of ADSP if its not going to be properly 
recognized honored by resigners.

--
Hector Santos, CTO
Santronics Software, Inc.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Daniel Black <[email-masked]>
Date: Sat, 10 Oct 2009 15:08:09 +1100

On Saturday 10 October 2009 12:53:14 hector wrote:
(cut)

> were rejected.
probably sent from the list domain rather than the author domain.

> So I fixed that by adding more white listing rules for
> this list sender.
Whitelisting on the scale of individual receivers is an inhibition to 
adoption.

> to subscribers for rejected mail.
this is useful as at least in this case stuff didn't break silently. lucky I 
guess.

>   1.a) All DKIM-BASE compliant receivers SHOULD supprt RFC 5617
support: +1
>   1.b) All DKIM Resigners MUST respect RFC 5617
support: +1

>        SMTP level rejection to avoid bounce issues and mail list
not sure.

In addition to subscription list removals this would cause silent failure to 
ordinary sender to recipient communication that fails because of sender error  
or intermediary content reformatting when a simple/simple canonicalisation. 

It seems from your case above that automated removal isn't totally there so 
perhaps it could be kept as is even if a few people get scared into 
considering DKIM/list implications fully.

other options:
Receiver temp fails the messages and tells then recipient with a "whitelist 
this if you want" option

keep as reject but use http://tools.ietf.org/html/draft-kucherawy-dkim-
reporting-05 to supplicant processing.
1.d) Standardize http://tools.ietf.org/html/draft-kucherawy-dkim-reporting-05

> 2) Extend RFC 5617 with an explicit 3rd party signing option.

2.a) add a dkim=3p option (which is what I assume you meant from previous 
messages) informing the recipient that the sender isn't adverse that 3rd party 
signers be accepted instead of the ADSP.

2.b)
Extending RFC 5617 to support Sender: as a author responsible party header 
header to be checked in same way. Useful as many maillist already do this. 
This has limited MUA visibility though Outlook does display this in a way to 
avoid some spoofing attacks. Sender was standardized a long time ago so 
encouraging MUA developers to make use of this by making this change could be 
useful and perhaps a path of least resistance/maximum benefit.

Perhaps given the recipient filtering options may differ between between a 
first party and a third party signature perhaps keeping this as a separate RFC 
(also to be listed in 1.a) is needed like.....

4) DKIM Third-Party Authorization Label

pros:
* works for a number of explicit authorizations. In conjunction with dkim-
reporting could provide an automated way for senders to add third party 
authorisations with little ambiguity about what the sender intent is.

cons:
* the scalability on large environments to include all mailing lists that 
author domain use is a little fragile.

5) List Domain Signing Practices (LDSP)
A consideration that email lists, as defined by the domain in the List-ID tag 
(RFC 2919) could be treated in the same way as ADSP

As  Stephen Turnbull mentioned on the mailman-developers list recently which  
was where this was derived from:
"Obviously the amount of trust you put in LDSP-
    authenticated mail is much lower than that you put in ADSP-
    authenticated mail.  Still, in the current environment I'll take
    any bonuses I can get, and as long as I behave, I suspect the big
    ISPs would be willing to allow me to build up some cred."

pros:
* no action required on author domain
* promotes DKIM for list operators
* less whitelisting for recipients
* gives recipients domain reputation as a criteria

cons:
* acknowledges that List-ID's are spoofable and that 4) is probably an answer 
to this before reputation is developed or where delivery is really important.

>From the sympa-dev, dkim-dev and mailman-developers comments I don't think 
there will be any resistance in list server developers or operators honouring 
RFC 5617 and will probably drop/reject dkim=all|discardable if signatures 
fail.

> [2a] should also be considered as well.

#1 DKIM-BASE strengthen: good enabler for all of the below to work
#1d DKIM reporting: to handle incidental failures

Resigner/Mail list benefits by Option number:
#4 DKIM Third-Party Authorization Label: good for explicit third party senders 
of importance to the sender
#2a ADSP add dkim=3p: middle ground that is easy to deploy as a sender and 
gives recipients the ability to not be so strict about ADSP filtering 
dkim=all/discardable filtering
#2b ADSP add Sender as author agent: quick gain for list operators that DKIM 
sign and recipients that choose to implement it.
#5 LDSP: quick gain for list operators that DKIM sign and have a domain 
reputation, easy gain for ISP and large domain verifiers

---

From: John Levine <[email-masked]>
Date: 10 Oct 2009 06:05:13 -0000

People who contribute to mailing lists shouldn't say dkim=all.  We
argued this ad nauseam when we were hammering out ADSP, it shouldn't
come as a surprise to anyone.

My advice to mailing list software developers is to forget about ADSP.
What tiny utility it might have is limited to forgery magnets like
Paypal, not domains with live people who'd subscribe to mailing lists.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Oct 2009 08:25:49 -0700

> come as a surprise to anyone.

That is not true at all. They shouldn't be using discardable. "All" only
says what the sender does, not what the receiver should expect.

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

            discardable
                         All mail from the domain is signed with an
                         Author Domain Signature.  Furthermore, if a
                         message arrives without a valid Author Domain
                         Signature due to modification in transit,
                         submission via a path without access to a
                         signing key, or any other reason, the domain
                         encourages the recipient(s) to discard it.

Mike

---

From: John Levine <[email-masked]>
Date: 10 Oct 2009 17:07:08 -0000

>says what the sender does, not what the receiver should expect.

They certainly shouldn't be using discardable.  I would advise not using
all either, due to the observed tendency of people to pay way too much
attention to DKIM and ADSP failures.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 10 Oct 2009 10:12:55 -0700

> attention to DKIM and ADSP failures.

Folks,

To claim that one signs all mail is to imply that anyone receiving mail from 
them should see a valid signature.

Mail sent through list servers invites the problem of receivers getting mail 
that does not have the promised valid signature, since intermediaries are 
re-posting the message and are free to make whatever changes they see fit.

Hence, saying -all for mail that goes through intermediaries which might affect 
the signature is inviting receivers to treat the received mail with hostile 
prejudice.

d/
-- 

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

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Oct 2009 12:12:15 -0700

> them should see a valid signature.

It most certainly does not.

> re-posting the message and are free to make whatever changes they see fit.

"All" doesn't "promise" anything of the sort.

> the signature is inviting receivers to treat the received mail with hostile

It certainly doesn't help when one of the authors of the document
doesn't know what "all" means.

Mike

---

From: John Levine <[email-masked]>
Date: 10 Oct 2009 19:33:18 -0000

>doesn't know what "all" means.

Maybe it would help if you tried paying more attention to reports
from people trying to implement this stuff.  It's quite clear that
they desperately want DKIM+ADSP to be a magic spam filter, and so
they do silly things like treating all as approximately equivalent
to discardable.

There is no reason to publish all, since there is nothing useful a
sensible recipient can do with it, and some unsensible recipients
do actively bad things with it.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Oct 2009 12:43:01 -0700

> they do silly things like treating all as approximately equivalent

If the document is unclear on this point, exactly whose fault is that?

Mike

---

From: hector <[email-masked]>
Date: Sat, 10 Oct 2009 15:43:47 -0400

> attention to DKIM and ADSP failures.

So overall, you are in favor in deprecating RFC 5617?

My position is now is to agree with you IFF the modus operandi is to 
allow for resigners with no mandate or recommendation to use RFC 5617. 
If this is the recommendation, then we need to get rid of it or fine 
tune the specification to spell out the issues with receivers who 
begin to support it.

---

From: Steve Atkins <[email-masked]>
Date: Sat, 10 Oct 2009 12:58:45 -0700

> tune the specification to spell out the issues with receivers who

It's potentially of value to a subset of senders. That subset does
not include any sender who sends mail to a third party mailing list.

That subset of senders is probably strictly a subset of bulk mailers.

Whether the real value to them is worth the complexity for recipients
is a whole other question, but anyone concerned about the problems
with sending mail from ADSP using domains through third party
mailing lists is way off in the weeds.

Cheers,
   Steve

---

From: hector <[email-masked]>
Date: Sat, 10 Oct 2009 19:10:57 -0400

Steve,

The engineering issues are three folds:

1) Domains who use ADSP in open middle ware environments.  We all 
agreed since day one with similar SSP exclusive policies it would not 
be a good idea for these domains to do this.  It is their 
responsibility to make sure they know what they are doing.

2) Resigners (e.g. list servers) are not respecting the DKIM augmented 
technology on the table -  RFC 5617

3) Receivers in a general implementation of these new suite of DKIM 
technologies do support RFC 5617.

So its not just a matter of domains doing the wrong thing, but 
resigners not even considering the potential the new DKIM augmented 
technology is CAN be implemented, in such an intentionally neglectful 
way understand it can be both a) conflictive with RFC 5617, and b) 
create a real problem for downlink distribution.

If the framers of RFC 5617 do not believe it will work, then I propose 
  the re-chartering consider the deprecation of RFC 5617.

I don't think we can just work on the "Cross our fingers" premise that 
no one will support RFC 5617 - a concept that will ALWAYS be a thorn 
on a side for wide DKIM adoption.

So either resigners support it or we get rid of it.

--
HLS

---

From: Jim Fenton <[email-masked]>
Date: Sat, 10 Oct 2009 17:40:00 -0700

[Sending this from my home domain that publishes dkim=all ADSP. All 
those domains that are dropping messages that fail dkim=all probably 
aren't interested in this message anyway :-) ]

>>>> come as a surprise to anyone.
[Mike Thomas wrote]
+1

[John Levine wrote]
>> attention to DKIM and ADSP failures.
I'm (obviously) not as much of a fatalist when it comes using dkim=all. 
I believe there are things that one can usefully do, such as to "raise 
the bar" on content filtering, if a message fails a dkim=all ADSP. Yes, 
a lot of people are looking for ADSP to be a magic litmus test, just as 
there are domains that drop messages based on SPF softfail. These 
domains need counseling.
> them should see a valid signature.

Hardly. I thought that it was you that was making the point all this 
time that all SSP/ADSP could do is describe the sender's practices, and 
could not imply receipt of a valid signature.

> the signature is inviting receivers to treat the received mail with hostile 

Depends on what "hostile prejudice" means. If it means using other 
filtering measures more rigorously, I'm fine with that.

-Jim

---

From: [email-masked] (牛粥)
Date: Sun, 11 Oct 2009 16:12:17 +0900

> come as a surprise to anyone.

For a while, i thought that people use dkim=all then mailing admins go
with DKIM. Actually i don't care my emails indicates as spam with broken
signatures at mailing lists. Let me say this.. i go you go then all
people go!   
  
Sincerely,

-- 
"He never talks to anybody on the phone. What did he say to you?"
"He told me to help you."
		-- Johnny Fontane and Virginia, "Chapter 12", page 162
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 11 Oct 2009 02:41:08 -0700 (PDT)

> come as a surprise to anyone.

I'm an outsider delurking to say:

If this is indeed the official semantics of the protocol, then I would
petition to add a "dkim=except-mlist" policy.  Which means "I sign
everything that leaves my bailiwick, but may post to signature-breaking
MLs."

I would find the distinction between this and "unknown" to be useful
information when evaluating incoming mail.  I whitelist all mailing list
traffic -- I have to, because I've programmed my mailserver to reject Bcc
traffic otherwise.  *I* would be able to treat except-mlist as all.  But
for an ISP that doesn't know its users well, except-mlist = unknown.

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Oct 2009 11:20:25 -0700

> everything that leaves my bailiwick, but may post to signature-breaking

No need. That is exactly what the semantics of "all" is.

Mike

---

From: hector <[email-masked]>
Date: Sun, 11 Oct 2009 14:45:41 -0400

> No need. That is exactly what the semantics of "all" is.

Wow!

-1

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

These two policies are 100% the same with the difference DISCARD has 
explicit  actionable semantic:

                ....... Furthermore, if a

I read that to say to implementators:

   DISCARD - add rejection/drop Software logic
   ALL     - add logging, recording, tracing "learning" Software logic

I don't see anything that says DKIM=ALL allows for a 3rd party 
signature expectation.  The ADSP name, by WG consensus, was 
specifically titled for "AUTHOR DOMAIN" Signing Practice.  Not 3rd 
party signing practice.

Now, was it was a mistake and the authors really meant DKIM=ALL was an 
ALWAYS signed by someone concept?

That would be a different issue, but come on folks, ADSP was not 
framed to mean anything but the Author Domain signing his mail.

The authors position was one to intentional neglect and ignore any 
considering for 3rd party signatures:

B.4.  Third-Party Senders

    Another common use case is for a third party to enter into an
    agreement whereby that third party will send bulk or other mail on
    behalf of a designated Author or Author Domain, using that domain
    in the [RFC5322] From: or other headers.  Due to the many and
    varied complexities of such agreements, third-party signing is
    not addressed in this specification.

--

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 11 Oct 2009 11:54:46 -0700

Jim Fenton wrote:
> I'm (obviously) not as much of a fatalist when it comes using dkim=all. I
> believe there are things that one can usefully do, such as to "raise the bar"
> on content filtering, if a message fails a dkim=all ADSP.

Jim,

What you write sounds great.  Unfortunately, I have no idea what its software or
operations impact could or should be.

This isn't about being a fatalist; it is about protocol semantics and whether
non-participating intermediaries experience a failure that is not their fault.

If we are to assert conclusions of operational effect or non-effect, we need to 
be very careful that it is based on reasonable methodology. That you are not 
(yet) experiencing a problem by publishing an =all doesn't mean much if, for 
example, virtually no receivers are looking for an ADSP record and/or virtually 
no receivers are making handling decisions based on ADSP records.

Before you report your personal experiences, could you include data about the 
receivers, please?

>> To claim that one signs all mail is to imply that anyone receiving mail
>> from them should see a valid signature.
>> 
> 
> Hardly. I thought that it was you that was making the point all this time
> that all SSP/ADSP could do is describe the sender's practices, and could not
> imply receipt of a valid signature.

Imply is different from dictate.

What is the point of signing?  What is the point of publishing an ADSP record? 
If there is no expectation that it will have some effect at the receiver, then 
what really is the point of all this work.

If there is expectation that an ADSP record will have some impact at a receiver, 
then there needs to be some expectation that the impact will be upon messages 
that have an ADSP record but do not have a valid DKIM signature of the type ADSP 
promises.

>> Mail sent through list servers invites the problem of receivers getting
>> mail that does not have the promised valid signature, since intermediaries
>> are re-posting the message and are free to make whatever changes they see
>> fit.
>> 
>> Hence, saying -all for mail that goes through intermediaries which might
>> affect the signature is inviting receivers to treat the received mail with
>> hostile prejudice.
>> 
> 
> Depends on what "hostile prejudice" means. If it means using other filtering
> measures more rigorously, I'm fine with that.

Publishing ADSP is a proactive step.  Failing an ADSP test is different from 
failing to validate a signature.  It therefore is reasonable to expect that the 
first failure will have a different effect from the second.  In this case, 
"different" seems most likely to mean "worse".

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Oct 2009 12:10:28 -0700

This is surreal. We have both Crocker and Levine claiming that the *published*
semantics of RFC5617 are either not what it says, or should be ignored because
they don't like it.

Jim is under no obligation to produce evidence for you; evidence which is
-- of course -- conveniently a negative which cannot be proved. The obligation
here is to stop the revisionist history about what rfc5617 actual says.

I realize that this is an open and public forum, but the level of contempt
for this working group's output is astonishing.

Mike

---

From: hector <[email-masked]>
Date: Sun, 11 Oct 2009 16:15:31 -0400

+1

+1

> Before you report your personal experiences, could you include data about the 

Why is proper professional engineering simulation excluded?  Not 
everything needs to be put into production to have an engineering 
conclusion what is proper methodology.

--
HLS

---

From: John Levine <[email-masked]>
Date: 11 Oct 2009 20:34:08 -0000

>Before you report your personal experiences, could you include data about the 

Well, here's a little bit of my data.  Over the past day, my busiest
DNS server has seen 2014 lookups of _domainkey records, of which only
38 were for _adsp.

A surprisingly high 806 requests from 486 hosts were for plain
_domainkey with no selector.  I can't tell if they were looking for
the old DK policy record, or if their DKIM implementations were
broken.  I also saw 541 requests for _policy._domainkey, which was
used in a few drafts back in 2005, and 244 for _ssp.

Somewhat to my surprise, the 38 _adsp requests were from 34 different
hosts, but it's still fair to say that the fraction of hosts doing
_adsp lookups is very small, so it's not surprising that there's no
observable effect, good or bad.

---

From: hector <[email-masked]>
Date: Sun, 11 Oct 2009 17:46:01 -0400

Mike,

To his credit, since day one Levine has been militantly against 
Policy. What was surreal was that the IETF chairs allowed an 
individual who never believed in policy and vocally stated so, to take 
over the SSP specification from Eric Allman and Jim Fenton and water 
it down to uselessness.  This was a classic example of a "Poison Pill".

Nonetheless, the issue was not that POLICY was not desirable by the 
resigner market of people here, but the lack of proper engineering 
performed for the watered down version and the interoperability 
consequences caused by not supporting it even at this watered down 
level.  The latter being the main mis-engineering calculation.

Overall, the result was an inherent protocol inconsistency with DKIM 
resigners.  The issues were and still are very clear and the concerns 
were documented over and over again. Unfortunately, these concerns 
were excommunicated from the WG.

Either a) we update RFC 5617 to make sure resigners support it,  b) 
add a 3rd party policy to it, or c) we get rid of it.

--
Hector Santos

---

From: hector <[email-masked]>
Date: Sun, 11 Oct 2009 18:02:27 -0400

John,

You can't use STATISTICS - you must use protocol methodology - LOGIC.

You can't tell the world RFC 5617 is available as a DKIM "Add-on" 
technology YET support the intentional ignorance of its existence or 
hope that no one will support it.

You can't have it both ways.  Either you will support RFC 5617 or you, 
as the author of RFC 5617 propose to get rid of it.

Either way, as a SMTP and LIST SERVER developer, it will at least give 
us and in the general sense, all SMTP and LIST SERVER developers, a 
protocol consistent methodology to increase DKIM adoption and unleash 
it to our customers.

--
HLS

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 11 Oct 2009 15:26:52 -0700 (PDT)

> No need. That is exactly what the semantics of "all" is.
That appears to be a contentious issue.

While I don't think the Hector/Levine interpretation is very useful, I
think it would be a sound strategic move to yield to them regarding
dkim=all, and instead create our own dkim=except-mlist space where our
semantics are in place with *no ambiguity*.

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 11 Oct 2009 15:35:55 -0700

> semantics are in place with *no ambiguity*.

Whatever the semantics that you have in mind, the underlying question is who 
will adopt it and what is your basis for claiming they will adopt it?  The next 
question is whether the answers to the first question justify the considerable 
costs of pursuing this suggestion.

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Oct 2009 15:46:05 -0700

> semantics are in place with *no ambiguity*.

Not really. If there's some confusion with the current rfc -- and
"all"'s text is pretty spartan, though not in 5016 -- filing an errata
against it to clear up the confusion would be better. My guess is
that there's exactly zero appetite to opening up this can of worms
again beyond that.

Mike

---

From: hector <[email-masked]>
Date: Sun, 11 Oct 2009 18:48:50 -0400

First, I was probably and still am, the biggest promoter for 3rd party 
considerations, even wrote the DSAP proposal. So I was not too happy 
with ADSP with its exclusion of 3rd party considerations.

Second, I think the Hector/Levine interpretations are the same as it 
was always expected.  Unlike SSP, ADSP was 100% never about 3rd party 
signatures.

But its never going to be a surprise to me that others, such as 
yourself, will desire 3rd party considerations.  That was the problem 
with ADSP - its ignorance of this very high potential and worst, its 
lack of support by its author which doesn't help the process.

So what happen?

DKIM become a hop to hop resigning concept. ADSP POLICY in inherently 
conflictive with this.

A mailing list is just one form of a resigner.  You don't have to a 
mailing list server to be a DKIM resigning clearing house.

So again, as strong supporter of policy, how do authorize the resigner.

With all the work done over the last few years, I think simplest 
solution to add two new policies:

   DKIM=NEVER
   DKIM=ALWAYS

DKIM=NEVER is designed for the migration market who wish to add DKIM 
signing support to their domains but during the migration or 
development period, they want a policy that says this DOMAIN never 
signs its mail.

DKIM=ALWAYS says my mail is always signed by someone.

I always felt the benefits are not in proving the positive assertion 
by proving the negative assertion or deviation from the assertion.

In other words, a VALID 1st or 3rd party signature proves nothing. 
Reputation or Domain Certification helper technology of some sort is 
still required.

But for failures, there is a strong assertion that it is not what the 
domain expected.

o Current Policies:

DKIM=DISCARD

    When no 1st party signture is found - REJECT

DKIM=ALL

    When no 1st party signature is found - No Semantics.

o Extended Policies:

DKIM=ALWAYS

    When no signature is found - REJECT

DKIM=NEVER

    When a signature is found - REJECT, not expected must be spoof.

Hope this clarifies my position.

--

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 11 Oct 2009 20:25:43 -0400

>semantics are in place with *no ambiguity*.

Except that the ADSP RFC is already published and so it is what it is.  It is definitely 
premature to crack ADSP open again (of course I thought that about DKIM too).

Scott K

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 12 Oct 2009 07:41:15 +0530

I'd say just deprecate ADSP.  It has a niche application if at all and
I dont foresee any kind of widespread deployment beyond in a few
senders / ESPs.

That kind of technology doesnt need an RFC for it.

---

From: Daniel Black <[email-masked]>
Date: Mon, 12 Oct 2009 12:56:12 +1100

Taking a list of subscribers from a set of mailing lists (lists.cacert.org) I 
found 964 unique domains.

one had dkim=all
two had dkim=unknown

Looking for _ssp._domainkey records for the same subscriber domains:
one domain had "t=y; dkim=unknown" (which was one of the two that had ADSP 
dkim=unknown).

Looking through the email archives for all these list those with a DKIM-
Signature value:

There were 24 unique d= values.

These mailing lists have been configured so they don't break Author DKIM 
signatures.

Potential Conclusions:

a) this sample size isn't sufficient to draw conclusions.
b) its too early in the process to say
c) people don't bother deploying dkim=unknown because its pretty much the 
default
d) no-one is comfortable in deploying a ADSP record (including high value 
domains like paypal)
e) more domains are comfortable with DKIM-signing than verification or policy
f) people actually understand that dkim=all is harshly filtered when 
signatures could break

>From the WG Charter:
"Take[n] together[policy and signatures], these will assist receiving domains 
in detecting (or  ruling out) certain forms of spoofing as it pertains to the 
signing domain."

If the policy adoption level is so low and indecisive ("unknown") how can mail 
receiving domains detect spoofing on all but the ~0.1% of domains that deploy 
policy other than "unknown"? Even on the ~0.1% what action can they take when 
signature breaks are common?

---

From: John Levine <[email-masked]>
Date: 12 Oct 2009 04:16:36 -0000

>If the policy adoption level is so low and indecisive ("unknown") how
>can mail receiving domains detect spoofing on all but the ~0.1% of
>domains that deploy policy other than "unknown"? Even on the ~0.1%
>what action can they take when signature breaks are common?

This line of discussion has been rehashed many, many, many times
already, so it would be a good idea to look at the archives.

Short summary: DKIM and ADSP offer no meaningful defense against spoofing.

* A few domains are spoof targets, but the vast majority are not.  For
that vast majority, even if they do try to sign their mail, the myriad
ways that legit mail can arrive with a broken signature makes it a
poor practice for recipients to do anything with a broken or missing
signature other than ignore it.

* At this point, the only significant spoof targets that sign all
their mail are Paypal and ebay.  If you want an ADSP-like feature in
your spam filters, you're better off just checking those domains than
checking everyone who imagines that they are a) a target and b) sign
all their mail.

* Bad guys can and do trivially circumvent any ADSP-like feature by
using lookalike domains, from line comments that resemble e-mail
addresses, and a variety of other well known techniques.

The way DKIM can be useful to deter phishing is by helping recipients
to recognize the small fraction of mail that is good, not the vast
flood of bad mail.

R's,
John

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 11 Oct 2009 21:18:45 -0700 (PDT)

> costs of pursuing this suggestion.

At the sender side, dkim=except-mlist would be very attractive if the Levine
interpretation of dkim=all stands.  No large ISP could deploy the Levine all.
But as a practical matter, any organization with DKIM-supporting smarthosts,
that already uses SPF's "-all", could deploy dkim=except-mlist at minimal
risk.

At the receiver side, it's a little less useful, since no means is given to
tell whether a message is exempt mailing list traffic or must-be-signed
normal mail.  Hence big ISPs are forced to accept some false negative risk by
treating except-mlist as unknown.

However, for people like myself who have whilelisted all incoming mailing
lists, except-mlist would be so much more helpful than unknown.

---

From: hector <[email-masked]>
Date: Mon, 12 Oct 2009 00:32:56 -0400

Michael D.,

The key point that is being missed here is that doesn't matter if we 
all agree to add 3rd party or mailing list support to an extended RFC 
5617 policy protocol. If resigners are going to be exempt from any 
mandate to support it, it will remain to be conflict with receivers.

Remember that is the key concern and issue here.

Even if your DKIM=except-mlist proposal was accepted, endorsed, 
standardized and implemented by domains by exposing this domain policy 
to the world, if resigners continue to ignore it, the problem remains.

The fundamental question is whether resigners MUST|SHOULD support RFC 
5617 and/or RFC 5617bis.

--
HLS

---

From: Daniel Black <[email-masked]>
Date: Mon, 12 Oct 2009 16:19:03 +1100

> Short summary: DKIM and ADSP offer no meaningful defense against spoofing.
Shorter summary: The WG charter says there should be

> * A few domains are spoof targets, but the vast majority are not.
The scope of what targets there are is increasing because:

1. general service providers are putting out email payment requests for things 
like phone and electricity. The motivation to spoof @payments.actewagl.com.au 
that could be protected by ADSP would just be as successful as a spoof from 
@actewagl.com.au which cannot because of its user base.

2. governments are getting increasing involved with emailing their citizens 
and lucrative social engineering possibilities exist there.

3, governments departments would like to be sure that email from other 
government departments isn't spoofed. The efforts to ensure trusted email 
paths exist for all interconnections locally and globally is not possible.

> For
so lets get tpa going AND a ADSP amendment dkim=except-mlist going 
so they can do something meaningful.
> their mail are Paypal and ebay. 

Who notably haven't deployed ADSP despite their strong business case.

> to recognize the small fraction of mail that is good, not the vast
that looks very different that the WG charter wording.

---

From: Michael Deutschmann <[email-masked]>
Date: Mon, 12 Oct 2009 00:54:13 -0700 (PDT)

> mandate to support it, it will remain to be conflict with receivers.

I don't like the term "resigners" here.  Many mailing lists will do no
signing at all.  For whitelisting purposes, they may instead rely on SPF,
or just the hope that spammers won't guess the List-Id: or envelope sender
domains of the lists their victims subscribe to.

Compared to the more elaborate schemes bandied here, dkim=except-mlist's
strength and weakness is the same thing -- it leaves the question of *how*
to recognize legitimate mailing list traffic in the recipient's hands.

Those of us with vanity domains have hands quite capable of handling that
problem without recourse to some hypothetical third-party-signatures
standard (which will likely flop among ML admins just as SPF's SRS flopped
among forwarders...).  "dkim=except-mlist" is all *we* need.

---

From: [email-masked] (Wietse Venema)
Date: Mon, 12 Oct 2009 10:04:17 -0400 (EDT)

> everything that leaves my bailiwick, but may post to signature-breaking

Are you going to announce all your users mailing list subscriptions
in the policy record? If you do, that could be a privacy problem.

If you don't, then the spammer can add any mailing list header to
the message, and they can drive their truck through this hole.

	Wietse

---

From: Michael Deutschmann <[email-masked]>
Date: Mon, 12 Oct 2009 08:00:34 -0700 (PDT)

> the message, and they can drive their truck through this hole.

The only other option for a sender domain with any subscribers to
signature-breaking mailing lists, is dkim=unknown.  Which is just as big
a hole.

At least with dkim=except-mlist, the recipient can narrow the loophole to
cover only those mailing lists he is actually subscribed to.  If those
mailing lists use SPF, the spammer can't get in even if he knows which
ones to forge.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 12 Oct 2009 16:21:59 +0100

> the message, and they can drive their truck through this hole.

Surely that's OK, if that's the policy. The point is that the recipient 
must assign reputation to the list, not the original sender. If the list 
proves trustworthy (presumably it applies its own DKIM sig, or has an SPF 
pass, and also has a good reputation with the recipient), then the 
recipient might go on to assess the reputation of the author - on the basis 
that a trusted list is likely to be making a DKIM assessment of inbound 
mail.

I've come a bit late to this conversation, but it seems to me that the 
problems under discussion are really all about how a recipient should treat 
inbound messages. If list managers were routinely testing inbound DKIM 
and/or SPF, then a list with a good reputation should be able to deliver 
mail by re-signing and applying SPF.

It also seems to me that there must be a difference between "dkim=all" and 
"dkim=discard". Publishing "discard" should mean that there's no 
expectation that the sending domain will be sending mail to discussion 
lists. These domains ought to be reserved for purposes like sending 
personal banking notifications. I don't think I have any such domains, but 
I guess I could think of some use cases for a University.

Domains publishing "all" ought to be able to get mail through a mailing 
list. Recipients of such mail that has been corrupted by a list should 
accept it only on the basis that the list itself has a good reputation, 
combined with a verifiable DKIM signature, or SPF pass. Simply inserting 
list-id headers shouldn't be enough.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 12 Oct 2009 16:02:51 +0100

On Sat, 10 Oct 2009 07:05:13 +0100, John Levine <[email-masked]> wrote:

> People who contribute to mailing lists shouldn't say dkim=all. ...

But the user within some large domain that wants to join some mailing list  
has no control over what ADSP his sysadmins have set up - so it all gets  
caught up in company policy and what the company management has descreed  
(without, as is customary, consulting the people affected).

But, as I have explained many times before, there is a simple solution to  
this problem. If the listadmin has munged the message so as to break the  
original signature, he will be aware of the fact and so should insert an  
Authentication-Results header testifying that the signature was fine when  
he received it, and he should then resign the message INCLUDING THE  
AUTHENTICATION-RESULTS IN MIS SIGNATURE.

Then all will be OK if the ultimate recipient trusts the listadmin. But if  
that is to be a recomended pratice, then it needs to be documented as such.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Deutschmann <[email-masked]>
Date: Mon, 12 Oct 2009 09:36:25 -0700 (PDT)

> "dkim=discard". Publishing "discard" should mean that there's no

My understanding is that the all/discard distinction is orthogonal to
the mailing list issue.

I think the motivation for discard is to give guidance when someone
realizes a message seems to be forged after it has already been accepted
by their MX.  This could happen, say, if a user at a DKIM-unaware ISP
installed a DKIM-analysing plugin into their MUA.

In this situation, there are only three choices:

1. Send a bounce message
2. Drop it silently
3. Ignore the validation failure and show it to the user anyway.

#1 is clearly unacceptable in this day and age, since in the frequent
case that the message was indeed forged, the bounce would be backscatter.
(Unless perhaps SPF asserted the provenance of the bounce address.)

dkim=discard hints that people in this situation should take option #2.
It would be appropriate for sites that really, really, don't want their
users to ever see a phish.

dkim=all hints that people in this situation should take option #3.  It
makes mail less likely to be mysteriously lost if there is a screwup in
the signing of the legitimate mailstream.

Ideally, of course, all improperly signed mail would be rejected at CR LF
'.' CR LF, and this distinction would be irrelevant.

discard, all, and except_mlist thus cover three corners of a
square.

In theory we could have a fourth option, that provides for silent discard
of mail that fails DKIM and is clearly not legitimate mailing list
traffic.  But I don't think anyone would ever use it.

---

From: Doug Otis <[email-masked]>
Date: Mon, 12 Oct 2009 09:42:26 -0700

> in the policy record? If you do, that could be a privacy problem.

When a domain of a mailing list is publicly known, often so are the 
lists themselves.  The tpa-label approach will not indicate which 
specific list is used, only that a domain is authorized to act on behalf 
of the Author Domain.  When some non-public domain is being used by a 
mailing list, then the tpa-label itself would not be immediately apparent.

> the message, and they can drive their truck through this hole.

Agreed.  Which is why it makes sense to have Author Domains indicate to 
their recipients the specific domains being used to originate messages 
carrying their Author Domain.  Perhaps it might become common to have an 
Intra-net web page where users request specific mailing-lists to be 
included in the auto-generated tpa-label list.

Part of the concepts behind the tpa-label approach was to provide a 
means to authorize sources for the domain's messages by-name as a means 
to help limit the sources that might generate abuse feedback reports.

Rather than checking with some reputation service, what better source 
would there be than checking with Author Domain themselves?

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 12 Oct 2009 09:45:51 -0700

> that a trusted list is likely to be making a DKIM assessment of inbound 

Agreed, but the fact that it's a mailing list that is doing this isn't
significant.  It could be any intermediary that is willing to take
responsibility for the message by signing it.  Their reputation now
becomes a factor in the disposition of the message.

-Jim

---

From: hector <[email-masked]>
Date: Mon, 12 Oct 2009 16:34:28 -0400

The only thing self-asserting POLICY can do with some benefit it to 
help prove the negative assertion - failure detection.

Positive assertions prove nothing and more information is required. 
Currently, although it is out of scope, the WG consensus and 
specifications has leaned towards Reputation and Domain certifications.

POLICY is about what is expected by the domain and anything short of 
that expectation is evidence that there is some form of failure.

This is a solid engineering concept, Failure Detection, used 
throughout the society inventions and processes of the world, e.g, a 
nuclear power plant operations conditions - deviations from normal 
expectations signals events.

For the non-nuclear simple email concept, the closest analogy is a SSL 
certificate.  When there is a detection of current SSL certificate 
expectations, the BROWSER will inform the user:

   - Expiration
   - Common Domain mismatch  A.K.A  3rd PARTY SIGNATURE!!

So there is really odd about using Self-Asserting DKIM POLICY methods 
to emulate the receiver detection for policy failure.

Now, here is something that might be attractable to the CA market - 
the OCSP "Online Certificate Status Protocol".

This use to be optional for the browsers. Today, browsers like FF 
enabled it by default.  OCSP is a 3rd party PING to the CA OCSP 
servers to validate the certificate.

That is what the Reputation and Domain Certificate would desire and if 
it can be pulled off, it might work.

But that is the "Batteries Required" problem for DKIM adoption.

For wide adoption, it would be useful for original domains to have a 
self-assertion policy that allows receivers to easily detect failure.

--

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 12 Oct 2009 14:34:51 -0600

hector wrote:

> DKIM nodes.

Why are we arguing about it now, then?  It'll be years until we reach that 
point.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: hector <[email-masked]>
Date: Mon, 12 Oct 2009 21:12:32 -0400

> Why are we arguing about it now, then?  It'll be years until we reach that 

+1, however.

Don't you think a common ground (standard protocol methodology) 
understood by all to even begin this long term process is necessary?

It wasn't my intent to create the illusion this is an argument. DKIM 
is about mail integrity. Intermediary (re)signers are natural 
contentious with this philosophy. I am simply stipulating that 
intermediary (re)signers need to also support any ADD-ON protocol that 
is designed to help mitigate DKIM integrity problems domains and for 
the resigner itself.

I'm thinking with my Developer Hat on.

We have RFC 4871 (DKIM-BASE) and RFC 5617 (ADSP).  How do we implement 
this for signers and verifiers components in a logical "fit" that will 
also be compatible with other systems also considering DKIM-BASE and 
possible ADSP?

Note that in the deployment guide section 6.5, it already says:

   Any forwarder that modifies messages in ways that will break
   preexisting DKIM signatures SHOULD always sign its forwarded
   messages.

However, there is no implication about resigner restrictions in 
section 6.5.

And thats part of the problem with the deployment guide:

   - ADSP semantics in section 6.1
   - Forwarder signing semantics in Section 6.5

Simply put, there is no engineering consistency between the two.

In order to correct this, Section 6.5 needs a statement such as:

Proposed "draft" additional text for Section 6.5

  Before any forwarder attempts to modifies messages and add
  a new signatures to the message, it SHOULD look at the
  ADSP record for the 5322.From domain.   If the domain has
  an ADSP record with "dkim=all" or "dkim=discardable", the
  forwards SHOULD NOT forward the message.

     Note: Forwarders who do not support ADSP should be aware
     rejected or bounce mail may be result.  For mailing
     list systems, false subscriber removal notifications
     can occur when the subscriber MDA is supporting ADSP.

  See section 6.1 for ADSP support recommendations.

---

From: John Levine <[email-masked]>
Date: 13 Oct 2009 02:16:06 -0000

[ this is well trodden ground, so I will try and keep this short ]

>Agreed, but the fact that it's a mailing list that is doing this
>isn't significant.  It could be any intermediary that is willing to
>take responsibility for the message by signing it.  Their reputation
>now becomes a factor in the disposition of the message.

Right.  As JD and others have often pointed out, mailing lists should
sign their mail like anyone else, and recipients handle it based on
the list's reputation.  If we're going to encourage list operators to
change their software to deal with DKIM, sensible changes would help
them be sure that unwanted mail doesn't leak onto the list, perhaps
using DKIM and ancillary reputation systems.  That will help all
subscribers getting mail from the list, whether they use DKIM or not.

A few milliseconds of thought should reveal that a scheme that allowed
a list to assert that incoming mail was signed would instantly be
abused by spammers who would start sending from "lists" that claimed
to be passing through signed mail from domains with good reputations.
You'd have to decide whether you trust the list, and if you're going
to do that anyway, just deliver the mail from people you trust like
you do for any other mail and you're done.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 12 Oct 2009 22:24:01 -0400

[ this is also well trodden ground, so I will again try and keep this short ]

> Shorter summary: The WG charter says there should be

Yes, there was considerable naive optimism in the charter.

We all agree that it would be great to have a scheme to spoof-proof mail. 
But ADSP isn't it, for the reasons we've all gone over, no matter how much 
we might wish that it were.

> Who notably haven't deployed ADSP despite their strong business case.

I can assure you that Paypal and eBay are quite aware of DKIM and ADSP, 
and I have personally heard them encourage ISPs to drop unsigned mail 
purporting to be from them due to the amount of forgery.  Nonetheless, 
they don't publish ADSP.  This tells me that I'm not the only one who 
thinks that there isn't a business case for ADSP.

R's,
John

---

From: hector <[email-masked]>
Date: Tue, 13 Oct 2009 00:49:05 -0400

> subscribers getting mail from the list, whether they use DKIM or not.

So what you are saying is that LIST SERVER developers SHOULD NOT add 
ADSP features to restrict signing of ADSP domain nor bother to see if 
it should allow these restrictive domains to subscribe?

    List name:  ieft-dkim

    DKIM/ADSP Options:

       [_] Do not allow subscription from ADSP domains
       [_] Do not accept domains with DISCARD, ALL policies

       [X] Sign list mail:

           [X] Remove any old signatures

           Signing Selector: k00001
           Signing domain  : mipassog.org  [ GENERATE KEY ]

       [X] Checking Reputation Services

           [ CLICK TO SEE REPUTATION SERVICE LIST ] None-Defined

> to be passing through signed mail from domains with good reputations.

hmmm so why do you want to tell developers not to support ADSP to 
protect those domains from getting leaked into the network with 
signing that should never happen in the first place?

> you do for any other mail and you're done.

Where is this written in ADSP?

If the list server is blindly going to sign, can that be done 
confidently that all RECEIVERS has decided not support RFC 5617 even 
thought it exist to be implemented by receivers?

How does the list member tell his host to accept these RFC 5617 
violations?

Do all the DON'T SUPPORT RFC-5617 Host systems now provide a Web Based 
Application or Form to define the exceptions?

  o User Email Settings:

    [ Click Here to enter white listed lists names ]

      Example entry form:

      list-name:  ieft-dkim
      (_) Always accept
      (o) Accept only if signed by domain: mipassoc.org

Is this the Levine Idea for a DKIM PRODUCT which everyone must do or a 
widely adopted IETF standard protocol methodology based on voodoo 
operators and hope?

This is all very simple john - If you don't want RFC 5617 to be used, 
then either resign from further RFC 5617 and allow others to develop a 
working protocol or support it and help the WG come to agreement by 
all parties to finally get this done.

But I hope the we don't continue based on "HOPE" for non-RFC 5617 support.

Is it possible to take more than a few milliseconds, m2aybe about 5 
mins, to thing more about what you are suggesting?

You are telling developers to IGNORE RFC 5617 and to continue to sign 
mailing list with a total disregard that RFC 5617 may exist.  Yet that 
will only work if no receivers support RFC 5617.

How can you be sure that all list distribution downlinks:

    - Are ignoring RFC 5617?
    - Have added User Settings DKIM list server filter support?

Why so complicated? Why not get rid of RFC 5617 or update it?

--

---

From: hector <[email-masked]>
Date: Tue, 13 Oct 2009 01:14:18 -0400

John R. Levine wrote:

> But ADSP isn't it, for the reasons we've all gone over, 

which were?

> no matter how much we might wish that it were.

-1.  The only wish I have is that stop injecting misinformation.

Any domain that publishes a DKIM=DISCARDABLE and for any receiver that 
supports ADSP will immediately protect the Author Domain and the 
receiver system from further abuse from:

   1) ALL legacy (non-signed mail) DOMAIN spoof attempts at
      the receiver.

   1) All 3rd party signed mail NOT EXPECTED by the Author Domain
      regardless if its was a malicious reply or a stupid list
      server ignoring RFC 5617.

Both are huge immediate payoffs for the domain and receiver.  To deny 
this high benefit is being intentionally ignorant.

> they don't publish ADSP.  

Well, maybe if the WG can get a true champion of POLICY and not one 
that selfishly took over SSP with the sole clever confessing purpose 
of creating a non-working protocol poison pill, then could change.

No one can take any POLICY opposition serious from one that author's a 
document he doesn't support.

Your input is extremely bias and a conflict of interest to the WG 
participants who have interest in seeing a POLICY system work.

But you know, I don't blame you. I blame the CHAIRS for allowing this 
to occur. It is surreal! It is completely wrong to have you as the 
author of a draft standard you don't even want PEOPLE to support.

Is that crazy or what?

> This tells me that I'm not the only one who 

Thats crazy!

--

---

From: Steve Atkins <[email-masked]>
Date: Mon, 12 Oct 2009 23:26:36 -0700

>> But ADSP isn't it, for the reasons we've all gone over,

See below.

> this high benefit is being intentionally ignorant.

To recap, for those who are just joining us, or who haven't been  
paying attention...

There are two entirely separate things connected to the sender domain  
that one might consider protecting. One is the byte sequence used in  
the domain name. The other is the "brand".

The byte sequence can be protected (sort of) via ADSP, but has close  
to no value for brand protection or phishing protection.

The "brand" cannot be protected solely via ADSP, at all, not in any  
manner.

By that I mean that it's possible to protect the byte sequence paypal.com 
  to some limited degree, but that that is operationally meaningless  
without any way to distinguish between "paypal.com" and "paypa1.com",  
or between "citibank.com" and "citibankonline.com", including more  
opaque homoglyph domain names based on non-ascii character sets, and  
so on and so forth. Unicode technical report #36 is well worth a read  
for anyone unfamiliar with the homoglyph issue.

paypa1.com can be protected using DKIM and ADSP in any way that paypal.com 
  can, so if ADSP can make paypal.com a "safe" or "unforged" or "not a  
phish" domain then it can do exactly the same thing forpaypa1.com.

In order to protect the paypal.com brand from brand dilution or  
phishing you need a way to differentiate the two cases.

This has been explained repeatedly on this list, and there's been no  
credible suggestion that it's not true. ADSP can protect byte  
sequences. But protecting byte sequences cannot, in itself, provide  
much in the way of brand protection or anti-phishing functionality.

As a rule of thumb, if you are going to assert that any protocol will  
protect the "paypal" brand you need to demonstrate that the protocol  
can return a binary "good" vs "bad" result, and that that protocol  
will return different results for "paypal.com" and for "paypa1.com".  
DKIM cannot do that. Nor can ADSP. Therefore, neither protocol can  
provide any brand protection, nor any phishing protection.

It's possible (likely, in fact) that a protocol that uses DKIM or ADSP  
as part of it's implementation could provide some level of brand  
protection, but discussing just the ADSP or DKIM part in the context  
of phishing or brand protection without discussing the section of the  
protocol that actually provides the brand protection is simply wasting  
everyones time.

Cheers,
  Steve

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 13 Oct 2009 00:01:05 -0700

Steve Atkins wrote:
> The "brand" cannot be protected solely via ADSP, at all, not in any manner.
> 
> By that I mean that it's possible to protect the byte sequence paypal.com to
> some limited degree, but that that is operationally meaningless without any
> way to distinguish between "paypal.com" and "paypa1.com", or between
> "citibank.com" and "citibankonline.com", 

If anything, Steve is being generous, because it's actually muss worse than 
that...

The name variants are one line of attack, with respect to the From: field 
address - which is what's being discussed here.

But then there are all the attacks on the From: field visible name -- which is 
all most recipients ever see -- the Subject line attacks and the Body attacks. 
None of these is even touched by an ADSP approach.

When someone asserts that a mechanism offers protection, they are obligated to 
account for the cases that are /not/ covered.  If they are diligent, they will 
then assess the relative costs and benefits of this protection proportion, 
versus the unprotected proportion.

d/
-- 

   Dave Crocker

---

From: hector <[email-masked]>
Date: Tue, 13 Oct 2009 04:13:39 -0400

> phishing you need a way to differentiate the two cases.

+1. It was well establish that there little defense using DKIM, Policy 
and anything else for that matter, against domain phishing.

We are talking about direct domain spoofs which does still exist in 
high volume.  Policy has an immediate protective value for these two 
types of direct domain spoofing, not phishing, abuse:

      1) Legacy Domain Spoofing
      2) 3rd party Signed Domain Spoofing
          - Direct Attempt by DKIM exploiters
          - Indirect via Exploited Resigners

No one can deny legacy domain spoofing does exist and no one can say 
that all bad guys are going to even use DKIM to try to get around it. 
  Even if they do, ADSP DKIM=DISCARDABLE can protect this as well.

> credible suggestion that it's not true. 

Any no one every deny this Steve.

You can't lump the two - Spoofing and Phishing are two difference 
problems.

> provide any brand protection, nor any phishing protection.

All any high-value domain that seeks exclusive DKIM signing protect 
needs to do is add a DIRECT domain policy.

Will it protect against phishing?  No. No one, not even policy people 
have ever said it will.  But you can't use that to throw out the baby 
with the bath room.  Spoofing and Phishing are two different problems.

I think you are saying that because you can't protect against a 
serious hacker going the extra mile with Phishing, that you shouldn't 
even bother with simple common sense domain spoof protection controls. 
Its like saying a club bouncer, a bartender or a traffic cop all thinking:

     "You know, all are IDS are easily forged, faked anyway.
      I'm not going to bother to ask and check it."

Yet, you and I and that white picket fence post knows its all possible 
to create fake ids. But I don't think that mean checking should not be 
done.  If it does mean that, then we have no SPOOF protection as well.

> protocol that actually provides the brand protection is simply wasting  

I agree because no one, on all sides, including the policy camp have 
every said phishing is addressable with DKIM, POLICY or anything else.

Short of a receiver having a phish database locally or remotely, 
whatever, of commonly exploited domains, there is nothing you can do 
about that.

But no one ever said policy addresses phishing so please lets stop 
using this as a reason to kill policy development that have a clear 
and direct high protection benefit against spoofed, not phished, domains.

--

---

From: hector <[email-masked]>
Date: Tue, 13 Oct 2009 04:36:29 -0400

> address - which is what's being discussed here.

We are taking about Domain spoofs, not phishing.  There are two 
different set of problem and there was long agreement that DKIM or 
POLICY can protect against phishing.

This is about domain spoof protection and nothing more.

> None of these is even touched by an ADSP approach.

and no one ever engineered any of the proposed Policy Protocols, from 
SSP to ADSP, to address mail alterations as you described. That is 
what DKIM-BASE is suppose to do.  However, see below.

> account for the cases that are /not/ covered.  

Dave, this is a false premise because you are indicating concepts that 
were never designed to be part of any policy protocol proposal.

> If they are diligent, they will 

Again, Policy, since day one, was about Domain Signature practices. 
Not about domain phishing nor mail integrity changes.  However, since 
mail integrity changes are possible reasons for a policy violation, 
as RFC 4871 mandates:

      invalid signature is promoted as no signature

this allows POLICY and specifically ADSP DKIM=DISCARDABLE to offer 
high protection for Author Domains who expect protection against 
Domain Spoofs and Mail Integrity Violations at DKIM/ADSP supportive 
receivers.

This issue here is whether intermediary signers are obligated to also 
support unauthorized 3rd party signing protection sought by ADSP domains?

--
HLS

---

From: hector <[email-masked]>
Date: Tue, 13 Oct 2009 04:38:16 -0400

>> The name variants are one line of attack, with respect to the From: 
>> field address - which is what's being discussed here.
> 

Correction:

We are talking about Domain spoofs, not phishing.  These are two 
different set of problems and there was long agreement that neither DKIM 

nor POLICY can protect against phishing.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 13 Oct 2009 10:59:48 +0100

--On 12 October 2009 09:36:25 -0700 Michael Deutschmann 
<[email-masked]> wrote:

>> It also seems to me that there must be a difference between "dkim=all"
>> and "dkim=discard". Publishing "discard" should mean that there's no
>
> by their MX.

You don't have to accept a message just because you've seen the body. You 
can still reject it at SMTP time without generating a bounce message. Oh, 
but of course if you have accepted it, then you want to know whether you 
can discard it.

> This could happen, say, if a user at a DKIM-unaware ISP
># 1 is clearly unacceptable in this day and age, since in the frequent

Right. Now, if you're a mailing list operator, and you see a message with a 
good dkim signature that you're about to break, what should you do with it? 
I don't think you should deliver it if ADSP says "discard". I think you 
should bounce it while it's still bounceable, or even reject at SMTP time.

If ADSP says "all", I think you should add your own signature, covering the 
list headers that you've added and the rest, and deliver the message. Let 
the recipients measure your reputation, since the original signature is 
broken, they can't measure the OP's reputation.

So, I don't think this is orthogonal.

> discard, all, and except_mlist thus cover three corners of a

What are the dimensions on that square?

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 13 Oct 2009 11:27:31 +0100

> it should allow these restrictive domains to subscribe?

They should add features. But "DISCARDABLE" ('discard' isn't a value, and 
'discardable' doesn't mean 'discard'), should not be treated the same as 
"ALL". It's reasonable for a list to rejected mail that it is about to 
render discardable, but there's no reason to reject mail with "ALL".

Remember RFC5617 says " 3.2 ... o  If a message has a Valid Signature other 
than an Author Domain
      Signature, the receiver can use both the Signature and the ADSP
      result in its evaluation of the message."

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 13 Oct 2009 12:30:57 +0100

--On 13 October 2009 00:01:05 -0700 Dave CROCKER <[email-masked]> wrote:

>> By that I mean that it's possible to protect the byte sequence
>> paypal.com to some limited degree, but that that is operationally
>> meaningless without any way to distinguish between "paypal.com" and
>> "paypa1.com", or between "citibank.com" and "citibankonline.com",
>
>
> If anything, Steve is being generous, because it's actually muss worse
> than  that...

I understand the issue here, but part of the point of DKIM/ADSP is to allow 
automated systems to assign reputation to an email domain or email address 
- a byte string. Those automated systems will be able to distinguish 
between paypal.com (likely with high positive reputation) from paypa1.com 
(likely to acquire a very high negative reputation quite quickly.

So, sure, if the paypa1.com email is delivered, the recipient isn't 
protected. Except, perhaps if the MUA fails to mark the email as from a 
trusted source - a bit like the way browsers are beginning to identify web 
sites with Extended Validation certificates.

Furthermore, such systems could be designed to look for close mismatches, 
using Hamming distance functions, for example. My bet is that paypal don't 
own any domains with a Hamming distance of one from paypal.com, though they 
may well own domains with a Hamming distance of three - like paypal.org

It might be nice if paypal could publish in the DNS a set of related 
domains, that it is willing to share the reputation of paypay.com with. 
Positive reputation could flow from paypal.com to the shared domains, and 
negative reputation in the reverse direction.

> But then there are all the attacks on the From: field visible name --
> which is  all most recipients ever see -- the Subject line attacks and
> the Body attacks.  None of these is even touched by an ADSP approach.
>
> When someone asserts that a mechanism offers protection, they are
> obligated to  account for the cases that are /not/ covered.  If they are
> diligent, they will  then assess the relative costs and benefits of this
> protection proportion,  versus the unprotected proportion.
>
> d/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Oct 2009 11:45:26 +0100

Hi Hector,

We need to keep the tone here under control and in particular
the text below is inappropriate. Please desist from making
assertions like this on this list.

> of creating a non-working protocol poison pill, then could change.
...
> participants who have interest in seeing a POLICY system work.

And just to be clear, your blaming us as you say below, is not
a problem for me.

> to occur. It is surreal!

If you feel the need to discuss this further please do that
off-list with Barry & I.

Stephen.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 13 Oct 2009 08:00:42 -0700

On Oct 13, 2009, at 4:30 AM, Ian Eiloart wrote:

> own any domains with a Hamming distance of one from paypal.com,

(Just as an aside, you'd lose that bet. Ebay buy an awful lot of  
domains,
with no intention of ever using them. One of those is...  
paypa1.com. :) )

> though they

All of this is something that could be done with DKIM assured  
identities.

None of this requires ADSP. If anything, your observation is an argument
against needing ADSP as ADSP is *solely* about the sender of email  
making
assertions about themselves, while you're talking about receivers of  
email
making decisions based on previous behaviour.

> negative reputation in the reverse direction.

Paypal is a good example for when that's not needed. They send all
their legitimate email as paypal.com. Even if they do own paypa1.com,
they're not going to send you mail claiming to be paypa1.com.

(And for those cases where it would be useful the DKIM answer is
"just sign all your mail with the same d= tag, and it'll share  
reputation".)

Cheers,
   Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Oct 2009 09:32:20 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John R. Levine
> Sent: Monday, October 12, 2009 7:24 PM
> To: Daniel Black
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Is anyone using ADSP? - bit more data from the
> receiving side
> 

Another data point: Google Mail won't use ADSP because they will not discard someone's mail outright without a written agreement from the sending domain agreeing to same, absolving them of responsibility for mail that never arrives.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 13 Oct 2009 10:36:28 -0700

Ian Eiloart wrote:
> - a byte string. 

First, d= is only a domain, not an address.

Second, DKIM semantics do not claim that that any part of a message is "valid", 
except for the d= string.  As a side-effect of the mechanism used to achieve 
this, DKIM also claims that the bits covered by the authentication hash are the 
same at verification as they were at signing time, but that's quite different 
from claiming that they are "valid".

Third, there is a very basic difference between assigning a reputation to a name 
that is voluntarily provided -- such as the d= string -- versus trying to catch 
deceptive, unsigned messages.  They cover completely different philosophies and 
technologies.

The intent behind ADSP is to create an overlap for the otherwise-independent 
topics.  It works for some very narrow -- but still useful -- scenarios, and 
very much does not work for any other scenarios.

We need to be careful that we distinguish between scenarios that are reasonable 
to include in any mechanism that requires end-to-end perfection, versus other 
legitimate scenarios that are not subject to such tight controls.

Those automated systems will be able to distinguish
> between paypal.com (likely with high positive reputation) from paypa1.com 

A message from a Bad Actor either will not be signed or will not have a 
reputation history.  So the idea that there is a task of "distinguishing" 
between paypal.com and paypa1.com really misses the point:  For DKIM reputation, 
all that matters is paypal.com.

> Furthermore, such systems could be designed to look for close mismatches, 

Such systems could be designed to use an infinite array of heuristics; in fact 
they already are.  What is not clear is how this is relevant to a standards 
discussion about DKIM or ADSP.

> domains, that it is willing to share the reputation of paypay.com with. 

Why?  What would it take to maintain it?  Who would use it?  Why do you believe 
they will use it?  Why is it not sufficient for those "related" domains to 
develop their own reptuation?

d/
-- 

   Dave Crocker

---

From: hector <[email-masked]>
Date: Tue, 13 Oct 2009 15:04:50 -0400

+1

It SHOULD|MUST also be reasonable to recognize and acknowledge the 
conflicts between the two introduced by subjective incomplete 
scenarios who are ignoring IETF written proposed draft standards that 
was specifically designed to protected against these subjective 
incomplete scenarios creating unreasonable and unexpected 3rd party 
signatures.

The result - interoperability issues and unintentional victims.

---

From: John Levine <[email-masked]>
Date: 13 Oct 2009 23:07:58 -0000

This is really much simpler than you're making it out to be.

>automated systems to assign reputation to an email domain or email address 

For DKIM, that's basically right, it ties a domain to a mail stream so
receivers can assign a reputation to the mail stream.  For ADSP that's
completely wrong, all it does is allow senders to make assertions that
receivers may or may not find credible or useful, but that have
nothing at all to do with managing the mail stream's reputation.
(Remember that ADSP only applies to mail not in the signed mail
stream.)

>domains, that it is willing to share the reputation of paypay.com 

Why would they do that?  Remember that DKIM is not SPF nor Sender-ID,
and you can put your domain's signature on any mail you send.  Paypal
signs their mail with paypal.com.  If I send you a Paypal payment,
they will send you a mail with my return address announcing the
payment.  That message is signed with d=paypal.com because Paypal
takes responsibility.  (They really do this, I just tried it.)

>negative reputation in the reverse direction.

Positive reputation flows from paypal.com to the mail they sign.  If you
think they need a lot of signing domains, you're misunderstanding the
way that DKIM works.

R's,
John

---

From: hector <[email-masked]>
Date: Tue, 13 Oct 2009 19:47:53 -0400

> render discardable, but there's no reason to reject mail with "ALL".

IMO, as a software developer, it is programmatically inconsistent to 
create an potential problem for list distribution when the downlinks 
can results in negative results.  As it was outlined in the archives, 
discussed and proposed in the DSAP  draft:

     http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-12

specifically outlining the MLS concerns and considerations, I can not 
in good conscious claim or work with the idea of RFC 5617 ignorance 
knowing full well there exist an IETF standard that receivers can use 
to cause MLS problems.

> than an Author Domain Signature, the receiver can use both the Signature 

 > and the ADSP result in its evaluation of the message."

What is most important to receivers is what section 3.2 items 3 says:

    o  All messages from this domain are signed with an Author
       Domain Signature and are discardable, i.e., if a message
       arrives without a valid Author Domain Signature, the
       domain encourages the recipient(s) to discard it.

coupled with section 4.2.1 with direct semantics for exclusive 1st 
only signature semantics.

Coupled with the deployment guide sections 6.1, 7.3.1

    http://tools.ietf.org/html/draft-ietf-dkim-deployment-08

Coupled with the Threat Analysis RFC 4686 summary recommendation:

   DKIM is effective against the use of specific identities only
   when there is an expectation that such messages will, in fact,
   be signed. The primary means for establishing this is the use
   of Sender Signing Practices (SSP), which will be specified by
   the IETF DKIM Working Group.

All in all, allows for a wide interpretation and implementation for 
POLICY to be a natural part of the DKIM total solution.

This issue on the table is whether resigners, a direct threat to DKIM 
mail integrity, are obligated to play by the same rules and follow all 
the semantics, provisions and recommendations peppered throughout the 
documents.

Thanks

-- 
HLS

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 14 Oct 2009 11:50:48 +0100

--On 13 October 2009 19:47:53 -0400 hector <[email-masked]> 
wrote:

>> They should add features. But "DISCARDABLE" ('discard' isn't a value,
>> and  'discardable' doesn't mean 'discard'), should not be treated the
>> same as  "ALL". It's reasonable for a list to rejected mail that it is
>> about to  render discardable, but there's no reason to reject mail with
>> "ALL".
>
>
> create an potential problem for list distribution when the downlinks can
> results in negative results.  As it was outlined in the archives,
> specifically outlining the MLS concerns and considerations, I can not in
> good conscious claim or work with the idea of RFC 5617 ignorance knowing
> full well there exist an IETF standard that receivers can use to cause
> MLS problems.

I think you've misread my message. I'm simply saying that "ALL" doesn't 
mean "DISCARDABLE". As far as I can tell, ADSP gives no guidance to 
recipients about how to treat unsigned messages from the domain at all. 
Recipients need to make their own, intelligent judgements.

As a recipient, I know to treat trusted lists differently that other 
forwarders. And, if I know that they're going to change a DKIM signature, 
then I frankly don't care that ADSP told me that the message should 
originally have carried a good signature. What I care about is the 
reputation of the list. If the sender doesn't want their messages forwarded 
by lists, then can they not use "DISCARDABLE"?

>> Remember RFC5617 says " 3.2 ... o  If a message has a Valid Signature
>> other  than an Author Domain Signature, the receiver can use both the
>> Signature
>
> coupled with section 4.2.1 with direct semantics for exclusive 1st only
> signature semantics.
>

I reckon that the guide needs to caution recipients to expect that mailing 
lists might break signatures, and to assess the reputation of the sender, 
not the purported message author. Except where the policy is "discardable", 
of course. In fact, section 5.5 would be the place to insert 
recommendations, would it not?

The alternative, recommending that lists should not pass on messages from 
ADSP domains will simply inhibit domains like mine from publishing ADSP 
records. We're in a position to do that because we already do insist that 
our users send mail through our servers. However, we do make a great deal 
of use of mailing lists, both local and third party.

Specifically, I don't see how ANY organisation can be sure that its email 
won't go through a mailing list.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 14 Oct 2009 12:09:11 +0100

--On 13 October 2009 23:07:58 +0000 John Levine <[email-masked]> wrote:

>> I understand the issue here, but part of the point of DKIM/ADSP is to
>> allow  automated systems to assign reputation to an email domain or
>> email address  - a byte string.
>

OK. What ADSP adds is the ability to assign reputation to a specific email 
claiming to originate from a specific domain. Except for "unknown".

> Why would they do that?

For brand reputation protection - you've cut the relevant quote that I was 
responding to. It's not really a DKIM issue, but if I get email from 
paypal.co.uk, then how do I determine whether that email is from paypal? 
Nothing in the paypal.com ADSP records tells me anything about that domain. 
I don't know whether to expect email from it. The absence of DKIM and ADSP 
records tells me nothing.

My idea is that a company might publish an exhaustive list of domains that 
they use, so that I can automatically detect domains that may be attempts 
to defraud recipients. I'd probably only apply this to high value domains, 
but the algorithm would look like this: "if the domain is similar to, but 
different from PAYPAL.COM, then bump up the spamassassin score". After all, 
that's what we hope that users will be doing when reading messages.

> Remember that DKIM is not SPF nor Sender-ID,

They use a third party return-path? Presumably not, with the implications 
for domains that publish spf -all records. Or you mean some message header? 
The From: header? That would have ADSP implications.

>> Positive reputation could flow from paypal.com to the shared domains,
>> and  negative reputation in the reverse direction.
>

Actually, that isn't something that occurred to me, but it's useful to 
know.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 14 Oct 2009 12:52:38 +0100

--On 13 October 2009 09:32:20 -0700 "Murray S. Kucherawy" 
<[email-masked]> wrote:

> Another data point: Google Mail won't use ADSP because they will not
> discard someone's mail outright without a written agreement from the
> sending domain agreeing to same, absolving them of responsibility for
> mail that never arrives.
>

You mean that they won't publish ADSP records? Or that they won't respect 
any ADSP records? Or that they won't discard "discardable" messages?

Logically, none of these things follow. Publishing ADSP records doesn't 
mean that Google will discard anything, though it does grant permission for 
others to do so. They have lots of other things that they can do as a 
result of ADSP fails. Presumably, they'd be more aggressive with 
quarantining mail if there's an ADSP record that renders a specific email 
discardable. Heck, they could even argue that publication of 
"dkim=discardable" does absolve them.

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2009 09:27:01 -0400

> claiming to originate from a specific domain. Except for "unknown".

No, ADSP adds the ability for senders to make unverified assertions about 
their signing practices.  Unless you already have some knowledge about the 
domain, you have no idea whether it would be useful to believe it.

>>> domains, that it is willing to share the reputation of paypal.com
>> 
>> Why would they do that?
>
> responding to. It's not really a DKIM issue,

Oh, if we agree it's unrelated to DKIM, I agree that there's all sorts of 
hacks that might, hypothetically, help deter phishing, maybe.  In the 
meantime can we agree that a domain with a good reputation like paypal 
should sign all its mail, just like it does now?

> but if I get email from paypal.co.uk, then how do I determine whether 
> that email is from paypal?

That appears to be a mistake, that they sign mail from paypal.co.uk with 
d=paypal.co.uk rather than d=paypal.com.  I say this because when I did a 
transfer from my UK account, some of the mail they sent was signed with 
paypal.co.uk, some with paypal.com.  I hope you agree that mail signed 
with d=paypal.com is paypal, regardless of what the other headers say.

>> If I send you a Paypal payment, they will send you a mail with my 
>> return address announcing the payment.  That message is signed with 
>> d=paypal.com because Paypal takes responsibility.  (They really do 
>> this, I just tried it.)
>
> They use a third party return-path?

Once again, DKIM has nothing, repeat nothing, to do with anything in the 
envelope.  Perhaps you are confusing it with SPF again.  If you want to 
try it yourself, send me private mail and we can send each other matching 
tiny payments between out UK accounts and see what the mail looks like.

R's,
John

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 10:06:26 -0400

> "dkim=discardable" does absolve them.

+1 and that is a very critical point for product engineers especially 
when there new legal terms like "domain responsibility" peppered 
throughout the documents.  This is just asking for trouble one way or 
another.  That alone can scare people away (raises the barrier to 
adoption).

POLICY provides indemnification for receivers with a clear DOMAIN 
publication for its expectation for signatures.

ADSP also provides a newly IETF sanctioned and officially authorized 
protocol mechanism for silent discarding of accepted mail without 
notifications.  And its not a coincidence, the new 2009 RFC 5321 for 
SMTP did finally recognize the backscatter industry problem and added 
a provision that allows for reasonable discarding of mail due to 
abuse. ADSP provides that reasonable classification.

That said....

I can understand a RECEIVER not supporting RFC 5617. The idea here 
there is a final deposition. It is not pushing mail back into the mail 
stream.  Passthru systems are traditionally not expected not to alter 
mail (there is legal case history here) with the exception of adding 
network control lines (trace headers).

Regardless of what ADSP is suppose to mean, the issue is forwarders, 
relays, intermediary (re)signer ignorance for ADSP domains, 
effectively pushing DKIM/ADSP violating transactions back into the 
network mail stream and thus causing down links consequences.

In effect, ADSP (LEVINE) is saying:

      This is possible useful for MDA to use.
      But MTA (intermediary signers) can ignore it.

I don't think that is sound engineering.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 14 Oct 2009 07:10:54 -0700

> claiming to originate from a specific domain. Except for "unknown".

A DKIM signature says nothing about "origination".  A signature is typically by 
an organization that handles the message, but it need not be the originator or 
even a sender.  An independent trust service, such as Goodmail, could sign it, 
for example.

>  It's not really a DKIM issue, but if I get email from 

Mapping from a domain name to a brand name or company name or the like is indeed 
an interesting topic.  As you say, it has nothing to with DKIM.

d/

-- 

   Dave Crocker

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 10:19:36 -0400

> even a sender.  An independent trust service, such as Goodmail, could sign it, 

So are you saying that all receivers should whitelist goodmail.com

    dkim-signature: d=goodmail.com ....?

regardless of what the Author Domain has declared for ADSP?

Should we take for granted that the author domain has paid 
GOODMAIL.COM to certified its mail?

Conversely,  what happens when mail from author domain does not arrive 
with GOODMAIL.COM signatures?

How does the receiver handle this?

--
HLS

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 10:58:55 -0400

This is a good example of the problem here.

On the one hand we have a nobel cause and wish to protect the brand 
reputation with a trusted service using a positive Domain Reputation 
Assertion.

But on the other hand, we don't want want to follow any violation or 
deviations of this positive Domain Reputation Assertion.

Lets make perfectly clear there is NO ISSUE with this idea.

Assuming this is the way we want to go with a undefined Reputation 
Protocol, this is ok, but we need to also follow what Dave Crocker 
recently wrote:

    "When someone asserts that a mechanism offers protection, they
     are obligated to account for the cases that are /not/ covered.
     If they are diligent, they will then assess the relative costs
     and benefits of this protection proportion, versus the
     unprotected proportion." [1]

What I have been speaking of all long is that POLICY would provide for 
Failure Detection against protocol violations.  That would include a 
protocol based on reputation.

A reasonable compromise can be produce if receivers, including 
intermediaries follow the same standard protocol methodology:

   Step 1) Lookup the reputation, Resolve

   Step 2) Lacking Reputation Indicators or indeterminate
           signer resolution, Lookup ADSP to resolve Domain
           Signature Expectations.

Crocker and Levine, if you guys can accept this, I think you will go a 
long way to getting a final resolution the 4-5 year year policy 
debates and more importantly, show a green light and light at the end 
of the tunnel to begin getting more developers to implement DKIM and 
get wider network adoption of DKIM using a persistent protocol 
methodology.

I don't think #2 interferes with your Reputation schemes and 
promotions, but it will require to accept standard provisions that 
intermediaries follow by the same consistent rules.

--
Hector Santos, CTO
Santronics Software, Inc

[1] http://mipassoc.org/pipermail/ietf-dkim/2009q4/012655.html

hector wrote:

> Dave CROCKER wrote:
> 
>>
>> Ian Eiloart wrote:
>>> OK. What ADSP adds is the ability to assign reputation to a specific 
>>> email claiming to originate from a specific domain. Except for 
>>> "unknown".
>>
>> A DKIM signature says nothing about "origination".  A signature is 
>> typically by an organization that handles the message, but it need not 
>> be the originator or even a sender.  An independent trust service, 
>> such as Goodmail, could sign it, for example.
> 
> 
> Should we take for granted that the author domain has paid GOODMAIL.COM 
> to certified its mail?
>

---

From: Doug Otis <[email-masked]>
Date: Wed, 14 Oct 2009 09:27:28 -0700

> an interesting topic.  As you say, it has nothing to with DKIM.

Agreed.  But this does affect ADSP, the DKIM policy layer. It is not 
practical to have all agents that might operate on behalf of some domain 
to have previously exchanged keys allowing them to position selectors at 
or below the Author Domain.

Currently, most DKIM recommendations in these cases depend upon 
reputation services as a means for recipients to make acceptance 
decisions, which mostly works.  However, a reputation service is twice 
removed from that of an Author Domain that may wish to assert a DKIM 
policy that might be seen as being restrictive.

Even slight restrictions make other agents appear to be in conflict with 
the Author Domain policy.  Unfortunately, only rarely are Author Domains 
not dependent upon a number of other agents that have not previously 
shared keys in some manner. Nor would it be practical or safe for an 
Author Domain to widely share their keys in some manner.

There is a way to solve this DKIM policy problem without always needing 
to rely upon reputation services, or the impractical and unsafe sharing 
of keys.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Oct 2009 09:44:33 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 14, 2009 4:53 AM
> To: Murray S. Kucherawy; John R. Levine; Daniel Black

They won't honour ADSP "dkim=discardable" records posted by others.

> "dkim=discardable" does absolve them.

I'm only relaying what I was told at a conference.  You're free to contact them for an explanation beyond what I've said.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Oct 2009 09:47:15 -0700

> From: HLS [mailto:[email-masked]] On Behalf Of hector
> Sent: Wednesday, October 14, 2009 7:06 AM
> To: Ian Eiloart
> Cc: Murray S. Kucherawy; Daniel Black; [email-masked]

I don't think such a claim holds any weight unless it's written down in a law book somewhere.  I wouldn't be the least bit surprised if that's Google's position.

> I don't think that is sound engineering.

Until someone proposes a way to force all MTAs, including legacy ones, to pay attention to ADSP, all of this recent hysteria about ADSP is little more than academic.

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 13:29:40 -0400

You do realize that this just give people ammunition to throw the book 
at anyone for violating IETF standards.  Its a fact, they would be 
violating a IETF standard if they break mail knowing FULL well there 
is an technology specifically designed to protected against such abuse.

If a ISP or anyone is intentionally violating an RFC and pushing back 
into broken mail into the network that can potentially harm a domain 
or end-users, they are no doubt putting themselves at risk and any 
smart high tech lawyer would be licking his chops if the VENDOR is a 
big buck organization.

Why continue with this nonsense contentious issue when the solution is 
simple:

    1) Respect RFC 5617
    2) Update it to support resigners
    3) Or get rid of it.

This on-going idea that it can exist but IGNORED is not a good idea 
and is bound to bite people in the butt.

--

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 13:40:17 -0400

Murray S. Kucherawy wrote:

> Until someone proposes a way to force all MTAs, including 

 > legacy ones, to pay attention to ADSP, all of this recent
 > hysteria about ADSP is little more than academic.

Murray, we are not talking forcing anything.

We are talking codifying the IETF specifications because they are real 
engineering and implementation conflicts.  This is how IETF protocol 
design is done to make sure we continue to offer interoperability to a 
maximum extent. Thats the purpose of all this.  Eventually, under 
steady state, everything will fit better. Sure, they will be legacy 
systems, but I'm also sure they will be interested in fixing it too. 
Par for the course like other things, like 821 SMTP vs 2821 SMTP vs 
5321 SMTP.

Its really has simple solutions. Unfortunately we are dealing with 
stubborn obstacles that don't wish to address the issue but ignore it, 
which would be all good if RFC 5617 didn't exist - but it does.

--
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Oct 2009 10:45:31 -0700

> [email-masked]] On Behalf Of hector
> Sent: Wednesday, October 14, 2009 7:20 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] brand protection, was Is anyone using ADSP?
> 
> typically by

You're trying very hard to infer something that was not stated or implied in either what Dave said above or in the specs themselves.

In general, people are trying very hard to infer something from DKIM signatures and from ADSP that simply can't be safely inferred from the protocols as they have been defined so far.

The simple answer to the question is: "We don't know yet."  I'm sorry that this is the case, and I do understand that it's frustrating, but right now that's where we are.

Some constructive work would be really helpful here rather than all this fist-pounding and finger-pointing that only serves to degrade things further.  I for one would love to either write or see a draft that provides a third-party version of ADSP (FDSP, "F" for "forwarding"?  LSP for "list signing practices"?) that considers the general list and forwarder cases, including discussion of possible attacks and why the proposal is resilient to them.  TPA, for example, proposes an idea for authorizing third-party signatures where the third parties are known a priori, but thus doesn't cover mail through a list some user might want to use that signs/resigns.  DSAP is something closer to useful in the general case but is in need of examples and something more than an outline in the area of security considerations, thus demonstrating its usefulness.

I would happily implement either or both as experiments if there's even partial consensus that they are potentially workable solutions.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 14 Oct 2009 10:51:10 -0700

> You're trying very hard to infer something that was not stated or implied in
> either what Dave said above or in the specs themselves.
> 
> In general, people are trying very hard to infer something from DKIM
> signatures and from ADSP that simply can't be safely inferred from the
> protocols as they have been defined so far.
...
> 
> Some constructive work would be really helpful here rather than all this
> fist-pounding

All of which begs the basic question of why this thread is being pursued?  The 
questions and answers aren't new.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Oct 2009 11:00:41 -0700

> Sent: Wednesday, October 14, 2009 10:30 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]; Daniel Black; [email-masked]
> at anyone for violating IETF standards.

I have completely missed your logic, I'm afraid.  No, I don't realize this at all.

> Its a fact, they would be

What exactly would the penalty be for Google Mail choosing not to apply ADSP, which is 0% mandatory?

> smart high tech lawyer would be licking his chops if the VENDOR is a

What mail would they be pushing back into the network?

If Google Mail wishes to put itself at risk (and I disagree they're doing so), isn't that their choice?  If it's really such an atrocious decision, won't the users go someplace safer, or won't industry apply pressure for them to come around?

> Why continue with this nonsense contentious issue

+1 to that bit, especially all this senseless intensity.

> when the solution is

Sorry, I don't agree that these are the only options.  How about a different proposal, orthogonal to ADSP, covering lists and forwarders?  How about proposing extensions to ADSP that cover the areas you feel aren't covered?

How about something, anything, that seeks to encourage co-operation rather than friction?

> and is bound to bite people in the butt.

Oh, I can list a pretty large number of mail-related RFCs, some of them standards track, that are not universally implemented and the world hasn't blown up yet.

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 14:07:45 -0400

> questions and answers aren't new.

Here we go again - Ignore the problem, slam others, tell others to 
ignore posters and the concerns.

There is a different now Crocker.

By adding DKIM to your list server, and intentionally violating RFC 
5617, you have PROVEN that you can create interoperability problems 
for yourself, downlinks and list members..

If for once, you get your head out of the sand, with the REAL CROCKER 
come out, and stop ignoring this real issues which you know in your 
heart you agree, you would address the issue.

The question I poise is why are list server (re)signers exempt from 
supporting RFC 5617 which is specifically designer to protect again 
resigner abuse?

Provide a answer please.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 14 Oct 2009 12:15:58 -0600

> Oh, I can list a pretty large number of mail-related RFCs, some of them standards track, that are not universally implemented and the world hasn't blown up yet.

Maybe the world will only blow up after we argue about this for another few 
years?

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Oct 2009 11:19:07 -0700

> They won't honour ADSP "dkim=discardable" records posted by others.

So is it that they won't honor it as the sole criteria, or that they
won't pay any attention to it at all? I can understand the former,
but the later would be pretty weird since it's a pretty large hint
that something's really wrong.

		Mike

---

From: Jim Fenton <[email-masked]>
Date: Wed, 14 Oct 2009 10:53:08 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 14, 2009 4:53 AM
To: Murray S. Kucherawy; John R. Levine; Daniel Black
Cc: [email-masked]
Subject: Re: [ietf-dkim] Is anyone using ADSP? - bit more data from the
receiving side

You mean that they won't publish ADSP records? Or that they won't
respect
any ADSP records? Or that they won't discard "discardable" messages?

I recall also having heard that they would like to get feedback on what
(and how much) is being discarded.  Something along the lines of
draft-shafranovich-feedback-report most likely, although someone would
need to confirm that's sufficient.  I'm not sure this WG is the place
to take that on as a work item, but if not here, where?

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Oct 2009 11:30:12 -0700

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, October 14, 2009 11:19 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]; John R. Levine; Daniel Black; ietf-
> [email-masked]

I really don't want to be seen as speaking for Google based on two or three sentences I exchanged with someone that works there.

So let me answer this way: My own inference from the conversation is that they wouldn't discard/reject mail based on ADSP without a legal agreement to do so, but it might be used as a hint to move such mail into a spam folder.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 14 Oct 2009 11:40:27 -0700

J.D. Falk wrote:
>> Oh, I can list a pretty large number of mail-related RFCs, some of them
>> standards track, that are not universally implemented and the world hasn't
>> blown up yet.
> 

Maybe the world will blow up /because/ we argue about these for years.

d/
-- 

   Dave Crocker

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 14:53:21 -0400

> So let me answer this way: My own inference from the conversation is that they wouldn't discard/reject mail based on ADSP without a legal agreement to do so, but it might be used as a hint to move…

But there are already rejecting mail with forged DKIM signatures.

The last time I tried, replaying a DKIM signed message I grabbed from 
here, it never arrived.  Done again by REMOVING the DKIM-signature and 
the message came in.  I recall repeating this a few times to duplicate 
what I was seeing.

If this is true today, then your conversation was probable high-end 
and not actually about what is being done.  Google is indeed 
discarding invalid DKIM messages.  No, it didn't go into a spam folder.

Further, as it was noted, no one in their right engineering mind, not 
GOOGLE, not even us, can take POLICY serious when the author is doing 
everything to sabotage it and telling people not to suppose it.

--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Oct 2009 11:55:32 -0700

> Sent: Wednesday, October 14, 2009 11:53 AM
> To: Murray S. Kucherawy
> Cc: Michael Thomas; [email-masked]
> and not actually about what is being done.

That's not correct.  It was one of their lead engineers.

To avoid the risk of spreading hearsay, I'm not going to comment on this further.

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 15:02:08 -0400

> To avoid the risk of spreading hearsay, I'm not going to comment on this further.

Good idea.

But you can easily attempt to repeat what I observed to prove whether 
or not they are discarding forged DKIM signatures.  There was no 
bounce, so you can't call a SMTP reject.  Then on the 2nd test take 
the same message and remove the DKIM-SIGNATURE and see what happens.

I think this is besides the point.

The real issue is given the state of the system now, RFC 5617 exist, 
are intermediaries exempt from supporting it knowing full well that it 
will create interoperability issues?

That is not a hard question to answer.

---

From: Doug Otis <[email-masked]>
Date: Wed, 14 Oct 2009 11:54:48 -0700

> questions and answers aren't new.

Good question.

While email reputation has managed to retain a semblance of email 
functionality, this often results in more than 90% of the email stream 
being refused.  These refusals are often based upon the reputation of 
the IP address used by SMTP clients.

DKIM offers an opportunity to leverage names as a mechanism for 
acceptance and to authorize third-party domains that might act on behalf 
of the Author Domain without formal arrangements.  The authorization 
could be done in a safe and economical manner to allow Author Domains a 
means to benefit from the other domains reputation and services, and to 
better ensure messages are accepted.

While DKIM is still in the early deployment stages and has not served 
much as an acceptance vehicle, over a comparatively short period of 
time, inclusion of IPv6 addresses will likely make ferreting out bad 
actors based upon an IP address less practical.  In addition, the IPv4 
crunch is also likely to cause a greater level of sharing of outbound 
SMTP servers which will then emit a mixture of good and not so good 
messages.  By providing a lightweight authorization scheme to bolster 
the use of DKIM policy assertions, this should help establish 
relationships between domains and to better help guide acceptance 
decisions upon a domain by-name basis.

-Doug

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 15:39:12 -0400

> better ensure messages are accepted.

+1.

However, I think the answer is Dave is seeking is evidence of problems 
which in his mind because RFC 5617 is only a standard by name and not 
supported by anyone, there is no problem.   I guess that is only 
possible if indeed RFC 5617 will never be used by anyone.

==

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 15 Oct 2009 11:44:37 +0100

> domain, you have no idea whether it would be useful to believe it.

On the contrary, it adds the ability for domain owners to make those  
asertions. Assuming that the domain owner has control of his own DNS  
records, those assertions are as reliable as the reputation of the  
relevant Domain Registrar (you can argue about how reliable that is, if  
you wish).

---

From: hector <[email-masked]>
Date: Thu, 15 Oct 2009 07:37:19 -0400

>> No, ADSP adds the ability for senders to make unverified assertions
 >> about their signing practices.  Unless you already have some
 >> knowledge about  the domain, you have no idea whether it would be
 >> useful to believe it.

> assertions. Assuming that the domain owner has control of his own DNS  

+1.

I sounds like everyone is saying the same thing in different ways.

I like to view it as a failure to detect a positive assertion.

For Policy, the classic "Expect Only Signatures From Me" and you don't 
see one as the same as some Reputation concept that says "Mail Signed 
by Acme.Com can be trusted" but you also don't see that signature.

In both cases, its failure detection of Policy and/or Reputation 
assertions.

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

---

From: John Levine <[email-masked]>
Date: 15 Oct 2009 15:19:36 -0000

>relevant Domain Registrar (you can argue about how reliable that is,
>if you wish).

Huh?  Maybe things are different where you live, but in this part of
the world, registrars like Godaddy have millions of customers and know
nothing more about them than that their credit card charge for $8 was
approved.  It's hard to imagine how anyone could think that a
registrar would know anything at all about its customers mailing
practices.

To put it concretely, your registrar is JANET, which is a fairly
reputable organization.  Are you claiming that means that ADSP
published by random ac.uk subdomains are all going to be accurate and
useful?

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 16 Oct 2009 11:48:50 +0100

> published by random ac.uk subdomains are all going to be accurate and

Mine's JANET, too. Sure, they won't all be accurate, but if they're 
inaccurate then I know how to get hold of someone to fix the problem. 
Anyway, the person who cares most about the accuracy is the domain owner 
(or their customers).

As an admin, I'd like to be able to reject mail for lacking a DKIM 
signature. Without a supporting ADSP, I risk the ire of my users. With a 
supporting ADSP, I can point the finger at the publisher of the policy.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 16 Oct 2009 11:37:35 +0100

--On 14 October 2009 10:51:10 -0700 Dave CROCKER <[email-masked]> wrote:

>
>
>> You're trying very hard to infer something that was not stated or
>> implied in either what Dave said above or in the specs themselves.
>>
> All of which begs the basic question of why this thread is being pursued?
> The  questions and answers aren't new.
>
> d/

I'll guess that it's because the conversation helps its participants to 
understand the issues. If I've come across as fist-pounding, or repetitive, 
then I apologise. I do, however, have a better understanding of the issues 
than when I started, and I hope that others do, too.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 16 Oct 2009 11:51:25 +0100

--On 14 October 2009 15:39:12 -0400 hector <[email-masked]> 
wrote:

>>> All of which begs the basic question of why this thread is being
>>> pursued?  The questions and answers aren't new.
>>
>> Good question.
>>

+2

> possible if indeed RFC 5617 will never be used by anyone.

It may never be. But, it's relatively new, so it doesn't surprise me that 
it's not in use. However, It's also not surprising that people who may use 
the RFCs wish to understand the implications, and explore the problems 
before implementing.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 16 Oct 2009 12:37:45 +0100

> registrar would know anything at all about its customers mailing

I think you have missed the point. A malicious registrar might add/change  
an ADSP record, contrary to the instructions of the domain owner who is  
paying him.

But I doubt Godaddy is that malicious. Generally speaking, if you see an  
ADSP resord, you can be 99.9% sure that it is there on the instructions of  
the domain owner, and therefore does not require further verification.

---

From: hector <[email-masked]>
Date: Fri, 16 Oct 2009 10:28:01 -0400

> the RFCs wish to understand the implications, and explore the problems 

I couldn't agree more.

But I think the current advisement is not to use it, so R&D, 
exploration, experimentation, and developing corrective measures is 
next to nil.  Under such conditions most systems won't bother or can't 
afford to deal with alpha ware in a production environment.  So to me, 
it shouldn't be a surprise that there is little support, even thought 
that might be high interest.

Its not very hard to create a DKIM simulation based on establishing 
your boundary conditions for this process with the current specifications.

ADSP has three possible boundary conditions:

     unknown
     all
     discardable

DKIM-BASE has five possible boundary conditions:

      not signed
      signed by 1st party - valid
      signed by 1st party - invalid
      signed by 3rd party - valid
      signed by 3rd party - invalid

when can be reduced to three using the RFC 4871 semantics that 
promotes/demotes an invalid signature to no signature (never signed) 
status:

      not signed
      signed by 1st party - valid
      signed by 3rd party - valid

Therefore you have nine theoretical possible outcomes:

                       ADSP RECORD
      +=============================================+
      |       |  UNKNOWN  | ALL      |  DISCARDABLE |
      |=============================================|
   D  | NONE  |  pass     | discard? |   discard    |
   K  |-------+-----------+----------+--------------|
   I  | 1PS   |  pass     | pass     |   pass       |
   M  |-------+-----------+----------+--------------|
      | 3PS   |  pass     | discard? |   discard    |
      +=============================================+

IMO, we have seven high confidence deterministic possibilities.  For 
the DISCARD? results, as you said, DKIM=ALL is open-ended with no 
semantics (by design) so its left to ambiguous interpretation and 
local policy.

Now, consider the following:

IMV, I think the RFC 4871 semantics for promoting/demoting a broken 
signature to no signature is somewhat flawed.   IMV, it was not when 
policy was a major consideration of the DKIM specification and such a 
semantic naturally fit the valid signature requirement policies.

But when you separate POLICY from DKIM-BASE, "data" was now lost for 
augmented technologies to learn, explore, etc.  In other words, when 
the WG decided to separate the two developments, it invalidated this 
semantic. It should of been removed IMO. The reason is because we lost 
intent.

In the NONE/DKIM=ALL cell, this could be the result of two different 
mail scenarios:

      NO (REAL) SIGNATURE
      INVALID SIGNATURE

To me, that is two different classification or weights.

I don't have the answer, but I believe it begins with the question, 
which message do you trust more, one that didn't have a signature or 
one that was broken?

For the former (Missing), one can argue it is a genuine spoof or a 
roaming user using the domain address from some 3rd party service 
(i.e. hotel).  One can also say the roaming user is a thing of the 
pass as most users now have direct internet access to their main 
hosting service from anywhere in the world.

For the latter (broken), one can argue there was malicious intent but 
it could be some relay that innocently broke the integrity.

So the RFC 4871 promotion (or demotion depending on your POV) of 
Broken to no signature status hides intent.  This can become important 
if we are going to be looking at other evidence, headers, scoring or 
classification concept.

Anyway, my 2 pennies.

--
HLS

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 16 Oct 2009 17:06:00 +0100

>                        ADSP RECORD

I'd reduce it to this:
                       ADSP RECORD
      +=============================================+
      |       |  UNKNOWN  | ALL      |  DISCARDABLE |
      |=============================================|
   D  | NONE  |  pass     | reject*  |   discard    |
   K  |-------+-----------+----------+--------------|
   I  | 1PS   |  pass     | pass     |   pass       |
   M  |-------+-----------+----------+--------------|
      | 3PS   |  pass     | pass**   |   discard    |
      +=============================================+

* reject rather than discard, so that the sender has a chance of detecting 
their error. Especially true if you have an spf pass, for example, and the 
domain has a reasonable reputation score.

** pass, provided the third party signature passes, and you have some 
explanation for the breakage - eg, the message has been through the list. 
However, in this situation, you must rely on the reputation score for the 
third party signing domain, not the original signing domain or the author. 
This is a case where I'd (very slightly) prefer to see a broken signature, 
than none at all, I think. I might even give credence to an 
authentication-results header for the original signature, if that header 
were signed, and the list domain had a reasonable reputation.

---

From: hector <[email-masked]>
Date: Fri, 16 Oct 2009 13:21:34 -0400

> --On 16 October 2009 10:28:01 -0400 hector <[email-masked]> 

The problem with rejects is that it can cause a MLS to initiate 
sending subscriber removal notification messages. For example, the 
mipassoc.org list server will send you a "Last Warning" removal 
notification if your hosting server rejected a list message X number 
of times.  That was the key issue and reason I posted the concern; we 
now have concrete proof of an interoperability problem caused by the 
intermediary intentionally ignoring RFC 5671 restrictive policies. 
IOWs, we now have user victims who with no fault of their own are now 
subject to removal threats due to MLS signer *neglectfully* not 
filtering this ADSP domains.

In regards to the **pass, IMV, I am not concern about how we can 
accept 3rd party signatures.  There are ideas for this.  But its 
probably better to use another policy and not DKIM=ALL unless the 
specs were changed to provide those semantics. But as it stands, it 
clearly does not say that 3rd party signatures are implied in shape or 
form.  I see no proof or wordings whatsoever that DKIM=ALL allows 3rd 
party signers. The fact that it is open-ended with no explicit action 
semantics does not mean 3rd party signatures are allowed. If that is 
the desire then IMV it needs to be updated to say so.  Otherwise we 
have what we have now - confusing.  With all due respect to Mr. 
Deutschmann, Mr. Levine wrote RFC 5617. Not Mr. Thomas. Mr. Levine's 
interpretation is what counts.

--

---

From: "John R. Levine" <[email-masked]>
Date: 16 Oct 2009 13:33:26 -0400

>> To put it concretely, your registrar is JANET, ...
>
> inaccurate then I know how to get hold of someone to fix the problem. Anyway, 
> the person who cares most about the accuracy is the domain owner (or their 
> customers).

I have to disagree.  The person who cares most about the accuracy of ADSP 
is the recipient who has to decide whether to believe it.

If you say that Janet gets involved in fixing individual DNS records, I 
find that hard to believe, but you know them better than I do.  For 
commercial registrars such Godaddy and Tucows, whose service I resell to a 
few friends, I can assure you they know nothing, and I mean nothing, about 
their registrants beyond their credit card number what's in the WHOIS.  If 
someone complained to Tucows about one of their registrants, the most they 
could do is point to the reseller, who in most cases can't do much more 
than point to the WHOIS info.  In particular, they have no control over 
the registrant's DNS servers and couldn't fix them if they wanted to, 
which in most cases they wouldn't.

Really, reputation is about individual registrants and domains, and as we 
all know, you don't need ADSP for people you already know something about.

> As an admin, I'd like to be able to reject mail for lacking a DKIM signature.

With or without ADSP, you're going to have a very, very, very, very long 
wait.

R's,
John

---

From: hector <[email-masked]>
Date: Fri, 16 Oct 2009 13:47:52 -0400

> all know, you don't need ADSP for people you already know something about.

John we all concur with you. we always have.  But you continue to 
ignore what others are saying; with no reputation information, no 
dkim-signature d=thirdparty.com to base it on,  the domain is at risk 
for abuse in the same way its done today - legacy spoofed domain with 
no attempt DKIMized it.

POLICY allows you to cover those security holes when the reputation is 
indeterminate.

Of course, thats besides the fact that we have no reputation standard 
to work with anyway and certainly not even a dozen or more if they 
were available that everyone can use with equal results.  Is that 
going to change any time soon?  Sound like a very very long wait.

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 16 Oct 2009 12:27:48 -0600

> supporting ADSP, I can point the finger at the publisher of the policy.

That's (more or less) the exact receive-side use case we were discussing 
when developing ADSP.

---

From: John Levine <[email-masked]>
Date: 16 Oct 2009 22:04:31 -0000

>an ADSP record, contrary to the instructions of the domain owner who is  

Hmmn.  You might want to stop and familiarize yourself with the way that
domain registrations work.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 19 Oct 2009 11:59:30 +0100

> The problem with rejects is that it can cause a MLS to initiate sending
> subscriber removal notification messages. For example, the mipassoc.org
> list server will send you a "Last Warning" removal notification if your
> hosting server rejected a list message X number of times.  That was the
> key issue and reason I posted the concern; we now have concrete proof of
> an interoperability problem caused by the intermediary intentionally
> ignoring RFC 5671 restrictive policies. IOWs, we now have user victims
> who with no fault of their own are now subject to removal threats due to
> MLS signer *neglectfully* not filtering this ADSP domains.

I understand that issue. That's why receivers should NOT reject messages 
with broken DKIM records when they come from a trusted mailing list. They 
should assess the list, not the original sender. That's sensible, because 
list recipients usually know more about the list than they do about all the 
people subscribed to the list.

> In regards to the **pass, IMV, I am not concern about how we can accept
> 3rd party signatures.  There are ideas for this.  But its probably better
> to use another policy and not DKIM=ALL unless the specs were changed to
> provide those semantics. But as it stands, it clearly does not say that
> 3rd party signatures are implied in shape or form.  I see no proof or
> wordings whatsoever that DKIM=ALL allows 3rd party signers.

It's there. Section 1 of rfc5617  "The basic requirements for ADSP are 
given in [RFC5016].  This
   document refers extensively to [RFC4871] and assumes the reader is
   familiar with it."

rfc4817 is DKIM, rfc5016 is "Requirements for a DomainKeys Identified Mail 
(DKIM) Signing Practices Protocol"

rfc5016 section 3.1 gives a use case that is implemented with the tag 
"dkim=all": "Domain Alice provides information that it signs all outgoing 
mail, but places no expectation on whether it will arrive with an intact 
first party signature. Domain Bob could use this information to bias its 
filters to examine the message with some suspicion."

The interpretation is left to the recipient. In my view, if the recipient 
sees no good reason that there's no intact first party signature, the mail 
could be rejected but not discarded, thus allowing senders to be alerted to 
false positives. If the receiver sees a good reason that a signature is 
broken, they should accept it. A good reason would be that the message has 
been forwarded by a mailing list (DKIM or SPF validated) that the recipient 
is subscribed to.

Also, read section 5.3 and note the difference between requirement 3 and 
requirement 4. I believe that 3 is implemented with dkim=all and 4. is 
implemeted with dkim=discardable.

And, note 4.3: "...remailers that break DKIM first party
   signatures can be potentially assessed by the receiver based on the
   receiver's opinion of the signing domains that actually survived."

> The fact that
> it is open-ended with no explicit action semantics does not mean 3rd
> party signatures are allowed. If that is the desire then IMV it needs to
> be updated to say so.  Otherwise we have what we have now - confusing.
> With all due respect to Mr. Deutschmann, Mr. Levine wrote RFC 5617. Not
> Mr. Thomas. Mr. Levine's interpretation is what counts.
>

And, Mr Levine appears to agree with Mr Thomas, but be concerned about 
misinterpretations. I agree that the implementation guide needs to be very 
explicit about this scenario, and it might even be useful for the ADSP RFC 
to be updated to provide guidance here.