Subject: [ietf-dkim] Refocusing on the re-charter

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Oct 2009 11:43:19 -0400

Allow me to give a little summary, if I may.

I see at least the following arguments about ADSP in the conversation
of the last couple of weeks:
- ADSP is of no use at all.
- ADSP will entirely stop spoofing, if it's widely adopted.
- ADSP will partially stop spoofing / make it harder to spoof.
- ADSP is a tool that can be used in other anti-spoofing mechanisms.
- "All" and "Discardable" are effectively the same, because that's how
the spec is written.
- "All" and "Discardable" are effectively the same, because of how
recipient domains are implementing them.
- "All" and "Discardable" are entirely different; why can't you see that?
- We need a new "Except-mlist" option to make sure we have something
really really different.
- There's essentially no implementation of ADSP anyway.
- Some domains that are major targets of spoofing have not implemented
/ will not implement ADSP.
- Some domains that handle a lot of mail from major targets of
spoofing will not implement ADSP.
- ...etc...

As a participant, I have opinions of my own on some of these.  But I
don't think it matters.  We've put a protocol out there that we think,
at least through rough consensus, is useful for something.  We have
two operational guides that we've created, which are meant to help
implementors figure out what to do.

And now we have to wait, and see what gets deployed, how it's used,
and how well it works.  It's far too early to make any judgment about
ADSP based on current deployment.  Now we're talking about the "Thomas
interpretation" and the "Levine interpretation", and I posit that it
doesn't matter, at this point, whether they have different
interpretations (actually, I like John's most recent post on that),
and we won't know who's "right" until we have time to get more data.
And, as JD implies, we can argue about this until the world explodes,
and it won't accomplish anything for the working group.

The best it will do, as I can see from the discussion, is boost sales
of ramipril [ http://en.wikipedia.org/wiki/Antihypertensive_drugs#ACE_inhibitors
].

If people really want to continue arguing about this, I don't really
want to stop you, though I'll ask you to stick to one subject thread,
and to avoid pugilism.  Or perhaps you can get Dave to start up a new
mailing list called "[email-masked]", or some such.

But what's bothering me about the discussion, as chair, is that it's
distracting everyone from the issue at hand, which is what to do about
rechartering the working group.  Let's please get back to that, and
hold off on tangential discussion until we've settled on a new
charter.

Separate message coming about that.

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

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 18 Oct 2009 09:34:05 -0700 (PDT)

On Sun, 18 Oct 2009, Barry wrote:
> Now we're talking about the "Thomas

It is of some actual importance to resolve this schism.

If receivers are afraid senders will follow the Thomas interpretation,
and say "dkim=all" despite posting to mailing lists that break their
signatures, they will not act on "dkim=all".

If senders are afraid receivers will follow the Levine interpretation,
rejecting broken signatures at CR LF '.' CR LF without first whitelisting
mailing list traffic, they will not post "dkim=all".

Result: ADSP doesn't block a thing.

> and to avoid pugilism.  Or perhaps you can get Dave to start up a new

I haven't noticed any incivility in these discussions.

And while I lean towards Levine, it doesn't really matter to me which
side wins.  Indeed, a decisive Thomas victory would remove the need for
except-mlist.  It's only the ambiguity that is a problem.

(So as someone in authority, if you *choose one side* and close the book,
it just might stay closed...)

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

---

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Oct 2009 17:58:22 -0400

> mailing list traffic, they will not post "dkim=all".

My point, Michael, is that it doesn't matter what we "decide" in the
working group.  As John pointed out, what's relevant is not that he
and Mike Thomas disagree about what we intended with ADSP or whether
we think it's useful.  What's relevant is how it will actually be
deployed.  No amount of arguing one way or the other will tell us
that.  We've written our specifications and our deployment guides, and
now we have to wait and see what happens in the wild.

It isn't a question of choosing one side or the other.  It's a
question of moving the discussion to things that will matter, and that
will let the working group make progress.

Barry

---

From: Michael Deutschmann <[email-masked]>
Date: Mon, 19 Oct 2009 07:56:17 -0700 (PDT)

> working group.  As John pointed out, what's relevant is not that he

I'd disagree.  All we need is an explicit statement in an RFC as to which
policy is "correct" in the common case that the sender is very confident that
all non-mailing-list mail will have an unbroken signature, but cannot make
any promises otherwise.  Once it is explicit, we won't have to worry about
private interpretations.

If you really want to close this, I can't stop you.  I just think publishing
an "except-mlist" policy to cover this common case, or at least clarifying
which of the existing policies to use, would have been low-hanging fruit
allowing us to improve the quality and quantity of ADSP deployment.

But for now, once Exim 4.70 is released, giving me the ability to
actually participate in DKIM, I shall be publishing a dkim=unknown
record.  (If you build "except-mlist", I will come...)

---

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

> any promises otherwise.  Once it is explicit, we won't have to worry about

The RFC already says what to do, and the "except-mlist" proposal seems
to me indistinguishable from "all", as stated in the RFC.  The point
isn't what's in the documents, but what actually happens in the
implementations (given that we have no control over what verifiers do,
beyond what the spec says).  And we don't know that yet.

> If you really want to close this, I can't stop you.

It's not a question of what I want, but what the consensus of the
working group is.  If there's consensus in the working group that we
need to discuss this further and work on an "except-mlist" option,
I'll put that in the charter.  I don't see consensus for it yet, but I
can certainly be convinced.  Though not by further argument from you
-- I already know and respect your view on it.  We'd need to see
support from others.

Barry, as chair