Subject: [ietf-dkim] Case for ADSP "dkim=except-mlist"

From: Michael Deutschmann <[email-masked]>
Date: Fri, 16 Oct 2009 06:33:08 -0700 (PDT)

I'd like to more emphatically state the case for adding a
"dkim=except-mlist" policy to ADSP.  It will soon become a practical
issue for me, since my mailserver software (Exim) is going to support
DKIM in its next version.

Without it, I'd have to use "dkim=unknown", which is effectively no ADSP
at all.

To review, "dkim=except-mlist" would mean:

 I sign everything leaving my bailiwick, but may post to mailing lists
 that break the signature.  You are *on your own* in telling the
 difference between mailing list mail (which may be good despite a
 broken signature) and directly sent mail (that is always signed).  If
 you can't tell, then treat as dkim=unknown (ie: assume a message is
 ML traffic unless you know otherwise.).

(Incidentally, anyone have a better name for this policy?)

--

The determination of whether it is good to add a new policy to ADSP
should rest on three issues:

1. Is it backwards compatible?
2. Will senders ever deploy it?
3. Will receivers ever treat it differently than what the senders would
use if it were unavailable?

For #1, it is indeed compatible.  RFC 5617 explictly says that unknown
values are to be treated identically to "unknown".

Under Levine's interpretation of RFC 5617, "unknown" is clearly the best
approximation to "except-mlist".  Under the Thomas interpetation, it is
a small step back, but enough people endorse the Levine interpretation
that it would be foolish to count on sites treating "all" as
"except-mlist".

For #2, do I even need to argue?  Any site that passes all outgoing mail
through a DKIM-aware smarthost qualifies for "except-mlist", but not for
"all" if there are any mailing list subscribers.

#3 is the weakest point, but I can offer my personal testimony that I
have all my mailing lists whitelisted, and could thus only improve my
bad-mail determination accuracy if this extra information was available
in the ADSP records of purported senders.

(By the way, it might be a good idea to pre-reserve a family of policy
names, which would have the property of devolving to "except-mlist"
instead of "unknown" when the validator does not know them specifically.
This would allow 100% backwards-compatible later deployment of schemes
that provide for easier detection of desired mailing list traffic.)

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

---

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

> (Incidentally, anyone have a better name for this policy?)

"dkim=all" If you read ADSP in conjunction with section 3.1 of RFC 5016, 
then "dkim=all" means exactly that: "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."

<http://tools.ietf.org/html/rfc5016#section-3.1>

># 3 is the weakest point, but I can offer my personal testimony that I

-- 
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: hector <[email-masked]>
Date: Fri, 16 Oct 2009 11:30:02 -0400

> (Incidentally, anyone have a better name for this policy?)

IMO  dkim=list would be fine for what you describe.

The concern I have two folds:

   1) Its a threat entry point.

I rather see Doug's TPA or something list the DSAP 3pl=domain-list idea.

   2) Complexity.

It appears to require a rule such as:

    if signed and 3rd party and contains some form of
       a list header, precedence: list perhaps
          then pass (positive classification).

Now, this is GREAT.  Fantastic!  It might work, but we have the same 
problem that is always the case for everything else:

    What do you do when it fails?

Its hard for me to shallow the idea that its ok to accept mail when 
you declare all these parts are needed, but not say anything about 
when its not detected.

> 1. Is it backwards compatible?

+1

> that it would be foolish to count on sites treating "all" as

Hmmm, wouldn't it be nice if we have a WG interpretation?

The Levine doctrine "Do as I say, not as I write" A.K.A IGNORE it, is 
design to have unrestricted 3rd party signers (middle ware). They are 
not going to look at it.

> For #2, do I even need to argue?  

I hope so. Everyone else is required to argue their case. :)

> Any site that passes all outgoing mail

How does a receiver know that the client is sending list mail? Do they 
need to look at some other 2822/5322 header?

Who adds this? senders or author domains?  It sounds like the sender. No?

> in the ADSP records of purported senders.

IMO, it is the weakest point and also the one you need to address.

Our SMTP server is integrated with our LIST Server, so all list agents 
ids are validated at SMTP level (RCPT TO) and its validated like its 
any other hosted user or domain.  Thats not an issue to accept the 
message.

The issue is the failure of the author domain policy.  Lets assume the 
following DNA:

    From: [email-masked]
    To: user2:domain2.com
    Dkim-Signature:  d=mipassoc.org
    Precedence: list

I believe you are saying domain1.com has ADSP++ record:

       dkim=except-mlist

and the domain2.com receiver sees this policy and also maybe 
Precedence: list to determine it was a list message?

Why?  What is gained by checking for some "list" header?

Why not just consider previous polices like in SSP

     op=-  which is a must sign and allows for 3rd party signatures.

Anyway, what I want to know if what happens when you have this:

    From: [email-masked]
    To: user2:domain2.com  (MDA2)
    Precedence: list

and there is no signature, Is this a Discardable message for domains 
with dkim=except-mlist?

---

---

From: Steve Atkins <[email-masked]>
Date: Fri, 16 Oct 2009 08:58:08 -0700

> (Incidentally, anyone have a better name for this policy?)

dkim=all.

dkim=all says that you sign all mail you send, and nothing more. The
difference between that and what you write above for a receiver is
nil, I think.

Cheers,
  Steve

---

From: Michael Deutschmann <[email-masked]>
Date: Fri, 16 Oct 2009 14:33:22 -0700 (PDT)

> need to look at some other 2822/5322 header?

In many cases, they don't.  Then they have to treat dkim=except-mlist as
dkim=unknown.  But they lose nothing from the existence of dkim=except-mlist.

But *I* can treat dkim=except-mlist as dkim=all, because my mailserver is
programmed to specifically recognize the six mailing lists I am subscribed
to, by their bounce addresses.

In theory, a spammer could forge them, since none of them (not even
spf-discuss!!) use SPF.  But guessing which list to forge is an SbO that the
spammers have not pierced yet....  Impersonating any list other than those 6
is futile -- it will bounce off my anti-Bcc filter.

Loosely, you could say that dkim=except-mlist is equivalent to dkim=unknown
when the validator is a big ISP, and equivalent to dkim=all when the
validator is a vanity domain.

But you don't need to be a vanity domain to *advertise* except-mlist, and
us vanity domains would appreciate it if you do.

---

From: [email-masked] (Wietse Venema)
Date: Fri, 16 Oct 2009 19:24:35 -0400 (EDT)

Michael Deutschmann:
> But guessing which list to forge is an SbO that the

It's called spear-phishing, which is a form of targeted attack that
occasionally makes headline news.

Speaking of unintended consequences, this kind of anti-BCC filter
is an example of how a well-intended security feature can actually
help opponents to make email look more authentic (because they know
what list headers to impersonate in order to pass the filter).

You can require that those six approved lists sign such mail. That
requirement makes the proposed DKIM feature even more redundant.

	Wietse

---

From: hector <[email-masked]>
Date: Fri, 16 Oct 2009 19:49:30 -0400

>> ..

> difference between that and what you write above for a receiver is

0.89+ IFF "nothing more" implies additional 3rd party signatures are 
possible.  In other words, there will be two or more, but the 1st 
party signature is expected.

    From: [email-masked]
    Dkim-Signature: d=1ps.com ...
    Dkim-Signature: d=3ps.com ...

Part of the problem is the lost of integrity and 3ps will strip the 
1st party.

    From: [email-masked]
    Dkim-Signature: d=3ps.com ...

So the receiver seeing that 1ps has DKIM=ALL sees a violation and does 
not know what to do.

    Is 3ps.com a known trusted party?  << ---- GOOD! Excellent!
    Is 3ps.com an anonymous party?     << ---- MAYBE BAD?

DKIM=ALL is exactly like the SPF = SOFTFAIL (?ALL rule)

    "Something is wrong, but we don't know why. It could be bad
     it might be a good partner. We don't know, so its probably
     safer if you just record this, maybe score it and watch it.
     If you have other proof that 3ps.com is doing something
     bad or wrong, then you decide."

DKIM=DISCARDABLE is exactly like a SPF=FAIL  (-ALL rule)

    "This is not what we expected, I don't care what went wrong.
     Its not ours. Please do us a favor and you a favor by getting
     rid of it. I promise, I won't sue you."

The point of this discussion, now in its different thread forms, at 
least from my POV, is whether 3ps.com should of preempted this problem 
by seeing the 1ps.com DKIM=ALL and saying:

    "Hmmm, you know, this is a can of worms. I think it is best
     to filter this submission and not forward a 1st party
     broken message. What is the risk assessment here?

       break and forward?    GOOD or BAD?
       filter?               GOOD or BAD?

     hmmmm, I wonder if I should send a report to the domain
     that it was probably hacked? If I don't get a feedback,
     then we can remove its membership if this problem continues."

Who knows steve! :)

==

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Oct 2009 16:13:58 +0100

DKIM colleagues,

You all know that the DKIM discussions have sometimes been
contentious, and some participants have gotten hot under the collar.
We note that that's been particularly true recently, and we'd like
everyone to take a step back and remind themselves of a few things:

1. The purpose of this forum is for people to get together and discuss
the development of standards, with the aim of forming consensus.  That
doesn't mean that everyone will agree on everything, and consensus may
be with you on some points, and against you on others.

2. It helps neither the formation of consensus nor our individual
reputations to be impolite, abrasive, sarcastic, derisive, belittling,
or otherwise snarky.  We all try to be somewhat tolerant of the
occasional bit of snark, but it should be rare -- the group should not
be expected to accept it as normal discourse.

3. We make progress when arguments give technical points for or
against an issue.  We don't make progress by exaggerating,
oversimplifying, or otherwise mischaracterizing others' positions, by
name-calling, by "Is not!"/"Is so!" bickering, and so on.  Messages
that are essentially content-free apart from saying, "You're wrong,"
are not useful.  Messages that say, "You don't know what you're
talking about," or the like, cross the line of acceptability.

Please keep these points in mind when you participate in this -- and
in any other IETF -- working group.  Every time you post, ask yourself
what your post does to further the discussion.  And look at what
you're saying, and ask yourself whether you'd be annoyed if someone
said that about you.  Make sure your messages are polite, respectful,
and useful, even if you feel angry or upset.

A word on the mischaracterization:  If you attribute a point of view
to someone else, make sure what you say is an accurate rendering of
his position, erring on the side of caution.  It's always OK to ask,
"I understand you to be advocating [X].  Is that correct?"  We need to
understand each other's positions clearly.

As an example, it's fair to say, "John says that we should not publish
signing policies at all.  I think he's wrong because [of these clear
arguments]."  John has made his position on that clear, and it can be
addressed directly.  It's not fair to say, for example, "John would
allow the phishers to rob us blind because he won't let us protect
ourselves."  That's the sort of thing we mean by "mischaracterizing".

It's important, as we move the working group into its next phase,
whatever we decide that phase to be, that we all keep the discussion
reasonable.  We will not be as tolerant of impoliteness as we have
been.  Everyone should be aware that from this point on, unnecessarily
abrasive posts, things that violate respectful discourse, will be
subject to administrative action.  That may include suspension of the
right to post to this mailing list.

Everyone here has given useful input to this working group.  We would
like to see everyone continue to.  Thanks for your contributions, and
for your cooperation.

Stephen and Barry, as chairs
---------------------------------------------------------------
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Deutschmann <[email-masked]>
Date: Sat, 17 Oct 2009 09:48:02 -0700 (PDT)

> arrive with an intact first party signature."

You're endorsing the Thomas interpretation, here.

I'd just note that the following, from RFC 5617, section B.1:
# In this situation, it might be appropriate to publish an ADSP record
# for the domain containing "all", depending on whether the users also
# send mail through other paths that do not apply an Author Domain
# Signature.  Such paths could include MTAs at hotels or hotspot
# networks used by travelling users, web sites that provide "mail an
# article" features, user messages sent through mailing lists, or
# third-party mail clients that support multiple user identities.

... seems to endorse the Levine interpretation.  "user messages sent
through mailing lists" is explicitly listed as a contraindication to
an "all" policy.

But whatever, we may need a straw poll followed by a clarification RFC,
to settle once and for all whether Levine or Thomas is canon.

My leaning is that Levine is more faithful to the RFCs as published, but
Thomas would be more useful.  I favor my "except-mlist" as a third option,
allowing us to gain the benefits of Thomas while yielding to Levine.

---

From: John Levine <[email-masked]>
Date: 17 Oct 2009 17:57:30 -0000

>to settle once and for all whether Levine or Thomas is canon.

Mike's version is what the RFC says.  My version is the way that way
too many people will misunderstand it, no matter what it actually
says.

You've illustrated my point very well.  Thanks!

R's,
John

---

From: hector <[email-masked]>
Date: Sat, 17 Oct 2009 19:29:07 -0400

> allowing us to gain the benefits of Thomas while yielding to Levine.

I believe it is important to note the evolution of this, as least as I 
lived it:

What you call as Thomas's Interpretation based on a SSP model that had 
clear and direct semantics about 3d party signatures.  RFC 4686 
(Threat Analysis) and RFC 5016 (SSP Requirements) included consensus 
on discussions regarding optimization, DNS scalability and threat 
entry point resolutions.

I can surmise this with the following key point which was a heated 
debate but one that everyone on all sides compromised on:

    The only time POLICY is important is when a 1st party fails
    (including lack of 1st party signature)

The consensus was to codify in RFC 4686 Thread Analysis and in RFC 
5016 SSP Requirements in section 5.3 item 9:

   5.3.  Practice and Expectation Requirements

   9.  SSP MUST NOT be required to be invoked if a valid first party
       signature is found.

       Refs: Deployment Consideration, Section 4.2.

You have to understand the importance of this from an implementation 
standpoint.  The goal here was to help prevent redundant SSP lookups 
first before DKIM was evaluated.  This conflicted with implementation 
ideas that allowed for POLICY to be looked up at all times.  The DSAP 
proposal was based on the existence of SSP related policies that 
included 3rd party considerations.

If you check the archives, there was deep discussions surrounding this 
point.

The issue then and what continues today is HOW do we authorized 3rd 
party signers in an optimized, scaled fashion.  This is where we could 
not agree with ideas on the table.

So when SSP was taken over by John and replaced ADSP, its intent was 
to 100% removed the 3rd party considerations and make it only a 1st 
party policy protocol.

But as I stated the moment ADSP was introduced in January 2008, (check 
the archives):

    With ADSP, many of the consensus developed with RFC 4686 and
    5017 are not invalidated or in conflict.

 From my perspective, Levine really meant only ADSP is for 1st party 
signatures and domains who are not going to be part of mailing list, 
etc. The believe was that it target market is so low, that it wouldn't 
be used and more importantly it would not interfere with 3rd party 
signers. Check the archive, he clearly say this in more ways than one.

All I am been saying is that ADSP and the promotion to not use it 
conflicts with the written RFC developed over the 3-4 years 
specifically addressing 1st vs 3rd party considerations.

So if you go back to RFC 5016 section 5.3. item 9, with the item that 
ADSP replaces SSP,

   9.  ADSP MUST NOT be required to be invoked if a valid first party
       signature is found.

You have a framework that allows implementators to support ADSP when 
they are is no valid 1st party signature.

All the above is the essence of the issue we have before us from my 
POV.  Its my opinion as an long time and active participant in WG. 
ADSP removed years of discussion and work that help mold the RC 4686 
threat analysis and RFC 5016 guidelines regarding SSP/ADSP.

Finally, the Deployment Guide (RFC pending) came later.  It didn't 
even bother to mention SSP in its first draft.  That changed with WG 
notes (namely by me).  Its current rendition is a total revamp of the 
original and now has detail information about ADSP.   I don't think I 
would be off base that by design, it was left open ended to not tie 
section 6.1/7.4 (ADSP) and 6.5 (Forwarders) together.

---

From: hector <[email-masked]>
Date: Sat, 17 Oct 2009 23:36:37 -0400

> You've illustrated my point very well.  Thanks!

So can you help clarify your RFC 5617 work?

I honestly feel most people who decide to support it are going to 
follow what its says, just like David MacQuigg posted here today:

     http://www.imc.org/ietf-smtp/mail-archive/msg05781.html

So they will follow it verbatim.

RFC 5617 section 4.2.1.  Record Syntax writes:

   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.

However, once  implementators do follow the above, I think you are 
saying, it will be problem for 3rd party signers?

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 this specification.

This this mean, if I read you and thomas right, DKIM=ALL means 3rd 
party signers are possible without valid 1st signatures?

CHAIRS: I believe this are honest WG questions.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 18 Oct 2009 06:41:00 -0700

> party signers are possible without valid 1st signatures?

Manifestly this is possible. "All" just says what the author's sender
does as a matter of policy/practice. It can't build an electric fence
around the message to keep people from altering though. Including
destroying that signature and adding their own. It's up to the
receiver to make sense of that eventuality.

Mike

---

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

> too many people will misunderstand it, no matter what it actually

Then it needs explicit clarification in implementation guides. I think that 
what the RFCs say is good. It's enough to give real benefit to recipients, 
whereas the misinterpretation will make ADSP practically unusable (as if 
only "discardable" existed).

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Oct 2009 13:31:15 -0400

> only "discardable" existed).

[as chair]
You're welcome to suggest specific text for the "deployment" document.
 It still has to go into IETF last call, so changes are still open.

[as participant]
It's still true that no matter how much we say how we want it to work,
deployments will do what seems to them to maximize the blocking of
spam.  Some will prefer to block spam even at the expense of
significant false positives.  We'll just have to see how it works out,
but we can take a cue from SPF, where there was a LOT of deletion
based on SPF failures, even when the SPF records said softfail or
neutral, approximately the same as ADSP's "all".

Barry

---

From: hector <[email-masked]>
Date: Mon, 19 Oct 2009 13:59:08 -0400

> neutral, approximately the same as ADSP's "all".

As among one of the early implementators of SPF, I was never aware 
that SOFTFAIL and NEUTRAL was creating rejections, or at levels that 
was reported as a problem.  However, statements to this were seen 
written by those who never liked SPF.  It just wasn't true. All you 
needed to do is look at the software implementations to show that 
logic did not back that up.

Instead, I was one of the first to point out that relaxed provisions 
such as SOFTFAIL did do anyone a favor and NEUTRAL was a waste of 
people's time.  I advocated people should avoid using SOFTFAIL and I 
believe over time, people began to see this as well.

As I and other stated many times, ALL would become the SOFTFAIL for 
DKIM and we will mostly see nearly the same adoption pattern:

  - people start with NEUTRAL  (DKIM=UNKNOWN)
  - people begin to use DISCARD for some high-value domains
  - people being to use ALL for other less valued domains
  - people see abuse with ALL
  - people begin to switch some to DISCARD

In any case, I don't see how any of this relates to establishing a 
persistent protocol methodology.  ADSP as written is pretty clear:

   DISCARDABLE (HARDFAIL) has explicit mail handling instructions.
   ALL (SOFTFAIL) does not.

How people do the SOFTFAIL should be entirely up to implementations 
and local policy.  This is what we have in our SPF operator 
configuration file (default settings):

; SPF can return low trust results. A pass means the sender has
; a valid SPF record and is accepted. Softfail and Neutral means
; no match is found but rejection is not automatic.  Setting a
; true accept can provide a loop for potential spoofers who have
; SPF records and think they will allow them in.  The options
; below allow you to control this.

Accept-SPF-Pass      True            ; if false, continue testing
Accept-SPF-SoftFail  FALSE           ; if false, continue testing
Accept-SPF-Neutral   FALSE           ; if false, continue testing

I don't see any reason DKIM=ALL will not evolve to the same sort of 
learning we had with SPF.

---