Subject: [ietf-dkim] Mailing lists and signatures (fwd)

From: "John R. Levine" <[email-masked]>
Date: 21 Aug 2010 10:40:09 -0400

Yes, I am a nitwit, but you knew that.  This time I'll tell Alpine to sign 
it with S/MIME.

---------- Forwarded message ----------
Date: Fri, 20 Aug 2010 23:27:05 -0400 (EDT)
From: John R. Levine <[email-masked]>
To: DKIM List <[email-masked]>
Subject: Mailing lists and signatures

We've had a lot of arguments about the importance of verifying the identity of 
contributors to mailing lists.  If you think that's important, take a look at 
this message.

Even though Mailman has added a subject line tag and a message footer, the 
S/MIME signature still verifies, and your MUA should show a green star or 
whatever, at least once you've told it to import my S/MIME cert.  Mailman 
automagically wrapped the multipart/signed in multipart/mixed.  And the signing 
cert has both my full e-mail address and my True Name.

So I suggest we update the DKIM MLM draft to take out all the stuff about 
signatures surviving lists, and just say that if it's important for your 
signature to survive, S/MIME already does that, with a suitable pointer.

R's,
John

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

---

From: Hector Santos <[email-masked]>
Date: Sat, 21 Aug 2010 11:04:40 -0400

John R. Levine wrote:
> Yes, I am a nitwit, but you knew that.  This time I'll tell Alpine to 
> sign it with S/MIME.

Hahahaha, I figured someone will catch this. Glad it was you. :)

If anything John, it shows the power of POLICY and also the concern of 
FALSE POSITIVES.

To a HUMAN, this was a good message by John Levine, but under a wide 
general automated operations world that includes the unknowns, 
including people that don't know you John (domain), we need general 
software guidelines all can follow. IMO, it would be better to REJECT 
your flawed message for your sake than to make it an indeterminate 
condition.   With POLICY, its no longer indeterminate.

To even begin get this right, we need some level of protocol 
consistency among WG documents.  To continue with the subjective and 
one WG document conflicting with another WG document, seems to be an 
very problematic issue to address for this WG.

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

---

From: Hector Santos <[email-masked]>
Date: Sat, 21 Aug 2010 11:38:46 -0400

John R. Levine wrote:

> Yes, I am a nitwit, but you knew that.  This time I'll tell 
> Alpine to sign it with S/MIME.
> ....

John,

For your reposted message with Alphine, I am still not seeing any 
S/MIME based certified mail indicator in Thunderbird 2.0.

What I do see an a single attachment (part 1.2) with the "Note Well" 
block.

The only "stars" I see is under Thunderbird 3.0 and they are next to 
the From: and To: address in the message view header display block and 
thats because the addresses are in my contact list as people I have 
sent mail to or added to my contact list.

    From: John (star)
    To: DKIM List (star)

I believe TBIRD 3.0 uses this as a "white list". I believe I saw that 
as an option in 3.0 somewhere when I installed in with the last 6 
months (but I don't like it - too slow for me, so I remained with 
TBIRD 2.0 usage).

I do see on occasion a "Gold" Certified mail star from various people, 
so I know the MUA supports it.  But not with this message of yours 
created with Alpine.

In any case, I think we should take a step back and critically think 
about any suggestions regarding S/MIME.  I think it is a bad idea to 
introduce another dependency, especially if its an out of scope idea.

But as a software guy, I am all about protocol consistency and I see 
one approach to this.  This might be a new I-D:

        Using S/MIME as a DKIM verification indicator for MUAs.

When a MTA or MLS DKIM verifier successfully validates a message using 
whatever means, to help "expose" this DKIM validation to the MUA, it 
may consider adding a S/MIME certification MIME blocks to the resigned 
message.

I'm not sure what are all the bindings in a S/MIME signed message at 
this moment, so this may not be workable for a LIST distribution. But 
it appears that it might work and may require the automated creation 
of self-asserting S/MIME certificates for DKIM resigner message stamping.

The nice thing about this is that many MUAs do support S/MIME, so 
maybe an augmented DKIM idea can take advantage of that, but it should 
the MTA that does this and not depend on all original mail authors 
using S/MIME to sign their mail first in their MUAs.  Maybe the I-D 
can include a provision for recommending a MSA for adding it - but 
isn't that somewhat what DKIM is all about here?

---

From: "John R. Levine" <[email-masked]>
Date: 21 Aug 2010 11:57:42 -0400

> S/MIME based certified mail indicator in Thunderbird 2.0.

T'bird for some reason doesn't see signatures wrapped inside another part. 
Try another MUA like Evolution and it should work better.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sat, 21 Aug 2010 09:06:31 -0700

John R. Levine wrote:
> T'bird for some reason doesn't see signatures wrapped inside another 
> part. Try another MUA like Evolution and it should work better.
> 

Which is to say that "just use S/MIME" isn't an especially good option either.
Quelle Surprise.

And that doesn't even touch the fact that cert enrollment is not a task that
mortal men or elves can do.

Mike

---

From: Hector Santos <[email-masked]>
Date: Sat, 21 Aug 2010 13:46:01 -0400

> part. Try another MUA like Evolution and it should work better.

I don't have it installed, however, I trust you when you say it will 
work Evolution MUA.

But overall John, I'm sure you agree and understand we are not in 
position to dictate what "Favorite MUA" users will have.

That was evident again in a recent NNTP Proxy project I had for the 
Microsoft Web-Based Forums when they began to force software 
developers to use the web based forums by deprecating the Microsoft 
NNTP news servers and their microsoft.public.* newsgroups starting in 
June and by the EOY, all of the newsgroups will be gone off their nntp 
servers.

The MS Forums has a SOAP-based WEB service API which allowed three 
NNTP proxies to be written to allow to provide emulated NNTP access 
for MUAs.

The #1 issue we all had was surprisingly how widely different MUAs are 
being used.  One guys swears by Agent, the other guy swears by Opera 
browser Mail component, others use old outlook vs new LiveMail, others 
use the old and new TBIRD, so on and so on.

Let me try LiveMail because I have an alias LiveID (hotmail) account 
for this group....  No.  If interested, this is what I see with 
LiveMail showing this message:

    http://beta.winserver.com/public/files/levine2.png

As a side note, no body is shown as you can see.  This is telling me 
the software at mipassoc.org has some issues here maybe.  Users with 
LiveMail (a good chunk of the corporate world and PC world) will not 
see what you have to say here john. :)

If you like, send a direct test message to [email-masked] so I can 
see how LiveMail shows your S/MIME signed mail.

---

From: Hector Santos <[email-masked]>
Date: Sat, 21 Aug 2010 14:18:01 -0400

>     http://beta.winserver.com/public/files/levine2.png

John, a closer view, the Message Listing view at the top does have a 
little white letter icon with a ribbon(?) on it.

But no body view with LiveMail is still there. I looked for options 
about displaying text attachments - wasn't apparent to me.

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 21 Aug 2010 11:44:20 -0700

On 8/21/2010 8:57 AM, John R. Levine wrote:
> T'bird for some reason doesn't see signatures wrapped inside another part. Try
> another MUA like Evolution and it should work better.

The general form of this issue is that MIME processing varies widely and maybe 
wildly.  This is especially true for matters of nesting.  Any design that relies 
on consistent handling of nested MIME constructions is likely to fail.

(I got another example of this earlier in the week, with a multipart message 
sent through a mailing list, with different forms of the same content.  The MLM 
stripped all but the raw text version.  Not nearly as pretty to the recipient.)

I don't see this as profound insight, but merely another example of designing 
with modest expectations for a variable Internet.

d/
-- 

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

---

From: "John R. Levine" <[email-masked]>
Date: 21 Aug 2010 15:57:31 -0400

>The general form of this issue is that MIME processing varies widely
>and maybe wildly.  This is especially true for matters of nesting.
>Any design that relies on consistent handling of nested MIME
>constructions is likely to fail.

You're quite right, and I would extend it to say that any design that
relies on MUAs to do anything consistently is in trouble.

But I do think that S/MIME is as close as anyone's likely to get to a
robust signature that is linked to an individual sender.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 21 Aug 2010 13:04:26 -0700

> relies on MUAs to do anything consistently is in trouble.

That level of generalization can't be correct.  Otherwise basic interoperability 
at the MUA level could not exist.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 21 Aug 2010 16:59:08 -0400

> That level of generalization can't be correct.  Otherwise basic 
> interoperability at the MUA level could not exist.

My MSA contains quite a lot of code to fix the mechanical mistakes in the 
messages that MUAs inflict on it.  MUAs do reasonably well at the things 
that people really depend on, e.g. putting the right strings in the From: 
and Subject: lines, and the right strings in the submitted envelope. 
These have to work, since if they didn't people couldn't send mail, and 
the MUA vendors would get complaints.

>From there, it goes downhill fairly rapidly.  Consider, for example, the 
wide range of garbage purporting to be HTML that they create for formatted 
mail.  Validating S/MIME signatures appears to fall in the range of 
features that are nice to have, but not a big deal if they don't really 
work.

R's,
John

---

From: Daniel Black <[email-masked]>
Date: Sun, 22 Aug 2010 11:06:41 +1000

> We've had a lot of arguments about the importance of verifying the identity
> of contributors to mailing lists.  If you think that's important, take a
> look at this message.
> 
> S/MIME signature still verifies

It was going well until Date: 21 Aug 2010 16:59:08 -0400 when the message of 
John's failed to verify. So 25% failed.

> , and your MUA should show a green star or
> automagically wrapped the multipart/signed in multipart/mixed.  And the
> signing cert has both my full e-mail address and my True Name.

At a conceptual level how the MUA shows validity information is important 
going by John's descriptions. In the quick illistration here S/MIME sometimes 
works and sometimes doesn't. Enhancing the MUA display with DKIM validity 
information could be an important differenciator for an end user.

> signature to survive,

The DKIM standard has gone a long way to ensure interoperatibility and the 
ability to survive canonicalisation changes, header field additions and is 
careful about which header fields are recommended for signing purely based on 
survivability. Taking an approach saying we don't care if DKIM survives MLMs 
is a step in the opposite direction. This is not a proposal I support.

> S/MIME already does that, with a suitable pointer.
Not always. If S/MIME had a wider adoption perhaps DKIM wouldn't be needed. 
Either way S/MIME hasn't got a wide adoption yet so abandoning guidance for 
DKIM-Friendly lists seems premature especially if the hope in an takeoff in 
S/MIME adoption after all its years of existance.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Sun, 22 Aug 2010 08:42:58 -0400

> is a step in the opposite direction. This is not a proposal I support.

I know this is background noise, but I have no interest in restoring 
broken signatures or passing on ones we broke.

Aren't people tired of dealing with iffy iffy mail?  If so, why 
contribute to it with even more iffy iffy mail?

Maybe we should come up with a new idea called DKIM Amplifiers 
(DKIM-AMP) whose purpose is to restore the signal strength of DKIM 
signatures from hop to hop, from resigner to resigner.

Maybe we should have a new DKIM-PREDICT, whose purpose it allow the 
source point to create a PREDICTED PATH header on how mail will 
travel.  DKIM-PREDICT learns by looking at Received lines and sending 
feedback to the source point, providing tips on the ORCP (OBSERVED 
RECEIVED COMMON PATH).

Maybe we should have a new DKIM-FUZZY, whose purpose is to allow for 
non TRUE or FALSE conditions or MAYBES, wait, we already have a 
DKIM-FUZZY framework. :)

Seriously, this stuff is really complex - anyone who says this is easy 
stuff to implement, well ............  Sure it is easy to sign - if 
you don't care what was there to be begin with.   Sure it is also easy 
to verify - but what is the end result of that?  A continuation of 
iffy iffy mail world with the biggest beneficiaries - the BAD GUYS who 
will continue to do nothing to remain in a iffy iffy mail world.

Again, just background noise. :)

---

From: "John R. Levine" <[email-masked]>
Date: 22 Aug 2010 12:18:25 -0400

> information could be an important differenciator for an end user.

Based on the copies of the messages that come back here, the signatures 
are fine (other than the one I didn't sign in the first place) and the 
failure to show the signature is due to bugs in user MUA's S/MIME code. 
S/MIME has been around for a decade, and I've been a little surprised to 
find that the support in MUAs is so buggy once you get beyond the simplest 
cases.  Why would you expect DKIM support to be any better?  If this is 
important, wouldn't it be a lot quicker to file S/MIME bug reports (or for 
open source, bug fixes) with the MUA maintainers?

> is a step in the opposite direction. This is not a proposal I support.

I'm sorry, this gets the history wrong.  We had a lot of arguments about 
this when we were doing 4871, and I believe you will find that we added l= 
over substantial opposition under the theory that it would compensate for 
a significant fraction of MLM modifications.  I think we now have found 
that was overoptimistic.  The right thing to do is to deprecate l=, not 
make more mistakes.

> Either way S/MIME hasn't got a wide adoption yet ...

Um, every popular MUA for Windows, Mac, Linux, FreeBSD, and so forth, 
supports S/MIME, including Kmail.  I'm still trying to figure out why 
people who think it's important for list subscribers to verify the 
identity of contributors aren't using it.  It took me about 15 minutes to 
get Usertrust to generate keys (no charge for individuals) and install 
them into my three MUAs.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sun, 22 Aug 2010 10:32:30 -0700

John R. Levine wrote:
> this when we were doing 4871, and I believe you will find that we added 
> l= over substantial opposition under the theory that it would compensate 
> for a significant fraction of MLM modifications.  I think we now have 
> found that was overoptimistic.  The right thing to do is to deprecate 
> l=, not make more mistakes.

This is, as usual, shamelessly wrong. We showed that over 90% of mlm signatures
could be verified. Real life data, from a large company's mail stream. You have
no data other than blatant assertions.

Mike

---

From: Hector Santos <[email-masked]>
Date: Sun, 22 Aug 2010 16:01:35 -0400

Michael Thomas wrote:

> We showed that over 90% of mlm signatures could be verified. 

Any insight, breakdown or feel for that 10% failure?  Multiple hops 
for downlinks? More resigners, buggy DKIM verifiers?  Was these all 
DKIM or did it include DKEY?

---

From: "John R. Levine" <[email-masked]>
Date: 22 Aug 2010 20:54:31 -0400

>> cases.
> Looking at this list of RFC's required to implement it I'm not surprised
> (http://tools.ietf.org/wg/smime/).

Remember, the basic support works.  If your MUA can't verify the signature 
on the copy of this message I'm sending to you directly, I'll be 
surprised.  The bugs are in arcane cases (pardon me for shouting) THAT 
NOBODY CARES ABOUT.

> Wouldn't it be easy to add DKIM support to a few opensource MLMs and have the
> option of DKIM-Friendlyness available to all?

No, of course not.  See previous mail.

R's,
John

---

From: Daniel Black <[email-masked]>
Date: Mon, 23 Aug 2010 09:41:53 +1000

On Monday 23 August 2010 02:18:25 you wrote:
> > going by John's descriptions. In the quick illistration here S/MIME
> > sometimes works and sometimes doesn't. Enhancing the MUA display with
> > DKIM validity information could be an important differenciator for an
> > end user.
> 

> Why would you expect DKIM support to be any better?

The DKIM interoperability report boasts how well everyone implemented it and 
only a few misreadings of the spec needed to be corrected.

Alternately processing an Authenticated-Results header of course is a lot 
easier.

> If this is important, wouldn't it be a lot quicker to file S/MIME bug 
reports (or for open source, bug fixes) with the MUA maintainers?

Wouldn't it be easy to add DKIM support to a few opensource MLMs and have the 
option of DKIM-Friendlyness available to all? Same economy of effort and much 
more relevant to the DKIM WG.

> > The DKIM standard has gone a long way to ensure interoperatibility and
> > the ability to survive canonicalisation changes, header field additions
> > and is careful about which header fields are recommended for signing
> > purely based on survivability. Taking an approach saying we don't care
> > if DKIM survives MLMs is a step in the opposite direction. This is not a
> > proposal I support.
> 

(Answered by Michael)
> > Not always. If S/MIME had a wider adoption perhaps DKIM wouldn't be
> > needed. Either way S/MIME hasn't got a wide adoption yet ...
> 
> identity of contributors aren't using it.

John hasn't listened to the previous explanations and I'm not going to make 
this working group suffer endless reiterations of the same opinion again - 
there is far too much of that immature behaviour here already.

> It took me about 15 minutes to

To correct blatant assertion #2 adoption had to do with the number of users 
who elect to use the SMIME MUA support which is totally unrelated to how 
materially easy John, Dick or Harry found to use it.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 23 Aug 2010 01:52:48 -0000

>This is, as usual, shamelessly wrong. We showed that over 90% of mlm
>signatures could be verified. Real life data, from a large company's
>mail stream. You have no data other than blatant assertions.

Hmmn.  Unless I have misread previous mail, this verification process
involved a variety of heuristics unrelated to RFC 4871 such as
replacing the headers with stuff derived from the z= tag and guessing
that strings in the subject line might be tags added by the MLM.

There's nothing wrong with doing that for your private use, but it's
not DKIM.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 23 Aug 2010 20:05:38 -0700

On 8/21/2010 6:06 PM, Daniel Black wrote:
>  Taking an approach saying we don't care if DKIM survives MLMs

Not really, since it was known from the start that survival through an MLM is 
highly problematic and the steps towards helping survival were known to be quite 
limited.

Requiring survival is a change in DKIM's goals, as well as raising a massive 
barrier to adoption, given the history of a) challenge in adoption for any 
infrastructure sequence, and b) resistance by MLM developers and operators.

In other words, this line of efforts is seeking to raise the requirements for 
DKIM.  Absent compelling and demonstrated functional need, that makes it at best 
a distraction and at worst counter-productive for DKIM's main purpose.

DKIM's main purpose is assessment by reputation filtering engines.  The most 
important reputations to assess are the entities that are 'responsible' for 
message.  An MLM creates the message.  That the message might look a lot like 
one sent /to/ it is nice, but it's also confusing.  The original author is not, 
ultimately, responsible for what the MLM chooses to send.

>> S/MIME already does that, with a suitable pointer.

S/MIME was design to protect body content, not an entire message.

All of this prompts a repeat of an underlying question:  What is the purpose of 
this exercise and how is it justified within the charter?

With respect to MLMs, I thought the focus was on documenting realities and 
passing through MLMs and to explore issues and opportunities better integrate 
MLMs into DKIM.  That's quite different from trying to alter the core DKIM 
capability to support survival through MLMs.  I'm pretty sure that changing DKIM 
Core is not within our charter.

As for MUA considerations, anyone making claims about what is needed for utility 
in an MUA needs to cite their sources, providing empirical justification, not 
merely mathematical logic for why utility "ought" to be improved.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Mon, 23 Aug 2010 23:33:51 -0400

Dave CROCKER wrote:

> DKIM's main purpose is assessment by reputation filtering engines.  

Is this locked in stone as the only utilization of DKIM now and into 
the future?  Is POLICY (an "official" WG work product where reputation 
concepts are not), no longer included as part of a possible purpose 
for DKIM?

Lets suppose tomorrow I add DKIM signature support, and I use your 
statement above to document the purpose for DKIM,  what do I tell my 
customer base regarding the "batteries required" (reputation filtering 
engines) they need to get? Who, what and where are these engines? 
Where do you buy or get these batteries?

IMO, it is these statements that continues to raise confusion and 
raise the barrier of industry wide adoption that includes the general 
population of MTA developers and operators from tiny to small to even 
large.

It would be really sweet if we can finally get some consistency Dave, 
for all parties across the board.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 24 Aug 2010 09:42:54 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Dave CROCKER
> Sent: Monday, August 23, 2010 11:06 PM
> To: Daniel Black
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Mailing lists and s/mime & dkim signatures -
mua
> considerations
The
> most
> important reputations to assess are the entities that are
'responsible'
> for

Dave,

Please show us in RFC4871 where it says DKIMs main purpose is assessment
by reputation filtering engines.

In re-reading 4871 I find the following references:

6.3.  Interpret Results/Apply Local Policy

   It is beyond the scope of this specification to describe what actions
   a verifier system should make, but an authenticated email presents an
   opportunity to a receiving system that unauthenticated email cannot.
   Specifically, an authenticated email creates a predictable identifier
   by which other decisions can reliably be managed, such as trust and
   reputation.  Conversely, unauthenticated email lacks a reliable
   identifier that can be used to assign trust and reputation.  It is
   reasonable to treat unauthenticated email as lacking any trust and
   having no positive reputation.

Nothing here that begins to imply that the main purpose is assessment by
reputation filtering engines.

Perhaps this paragraph slightly down the page:

Once the signature has been verified, that information MUST be
   conveyed to higher-level systems (such as explicit allow/whitelists
   and reputation systems) and/or to the end user.  If the message is
   signed on behalf of any address other than that in the From: header
   field, the mail system SHOULD take pains to ensure that the actual
   signing identity is clear to the reader.

But again, no verbage that matches your assertion. The modifying clause
that begins with "such as".... gives examples but only explicitly states
that the information must be conveyed to higher level systems.

 May be that you are basing your assertion on section 8.5 regarding
replay attacks.... except that begins with "Partial solutions" in
referring to reputation systems, so that can't be it.

If we look at additional DKIM related RFCs, the only explicit use of the
identifier is found in the ADSP RFC which is certainly not reputation
system based but assertion based. But I forget.... one of the authors of
that RFC says don't use it because it is bad, bad, bad.

Looking forward to your response and explanation of where we find the
main purpose of use in reputation systems in the RFC.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 24 Aug 2010 08:54:25 -0700

> by reputation filtering engines.

It's a fair question, but answering it encounters three core problems.

The first is that 4871 is not a systems specification.  It's a component 
specification.  So it might or might not contain language about the way a 
signature is intended to fit into a larger processing environment.

The second is that we've been struggling with finding the right language for 
describing systems issues about DKIM.  Note that we even managed to write a 
protocol document without defining the protocol's output, which is why we needed 
an errata document. So we need to be careful about using RFC 4871 outside of the 
larger context of work done since it was published.

As I recall Mark Delany's explanation of the original intent for Domainkeys, it 
was considered a primary goal to design the system in a way that targeted 
implementation in the email infrastructure rather than email end systems.  The 
reduced granularity, of having an organization rather than user identifier, was 
an example of this. It massively reduced administrative overhead.

And third, if DKIM has a "main purpose" for something involving end user 
processing, where is the detailed specification or guidance that would encourage 
interoperable use of it?  Without that, use becomes idiosyncratic and therefore 
non-interoperable.  (This is a version of the same logic we all debated we had 
about i=/d=, concerning signer intent and assessor interpretation.)

> 6.3.  Interpret Results/Apply Local Policy
...
>     and reputation systems) and/or to the end user.

Is at least nicely in the right arena, IMO.

> But again, no verbage that matches your assertion.

I wasn't aware that my statement was offered as a quotation.  I certainly didn't 
intend it to be.

On the other hand...

>> identifier is found in the ADSP RFC...

You missed the relevant, related RFCs:

Errata, RFC 5672:
> 8.  RFC 4871, Section 2.11, Identity Assessor
...
>       A module that consumes DKIM's mandatory payload, which is the
>       responsible Signing Domain Identifier (SDID).  The module is
>       dedicated to the assessment of the delivered identifier.  Other
>       DKIM (and non-DKIM) values can also be delivered to this module as
>       well as to a more general message evaluation filtering engine.
>       However, this additional activity is outside the scope of the DKIM
>       signature specification.

Overview, RFC 5585, <http://dkim.org/specs/rfc5585.html#rfc.section.5>:

>      .        +-----+--+----+      +-------+              .
>      .              |  |          / Check   \<............+
>      .              |  +-------->/  Signing  \
>      .              |           /   Practices \<..........+
>      .              |          +-------+-------+          .
>      .              |                  |                  .
>      .              |                  V                  .
> +----+--------+     |            +-----------+     +------+-----+
> |Reputation/  |     |            | Message   |     | Local Info |
> |Accreditation|     +----------->| Filtering |     | on Sender  |
> |Info         |                  | Engine    |     | Practices  |
> +-------------+                  +-----------+     +------------+

and:

> verifying:
...
>If the signature passes, reputation information is used to assess
 >   the signer and that information is passed to the message filtering system.

and <http://dkim.org/specs/rfc5585.html#rfc.section.5.5>

> 5.5. Assessing
...
> A popular use of reputation information is as input to a Filtering Engine
 > that decides whether to deliver -- and possibly whether to specially
 >  mark -- a message. Filtering Engines have become complex and sophisticated.

Deployment, RFC 5863,
<http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#system>:

> 2.1 A Systems View of Email Trust Assessment
...
> The recipient then makes handling decisions based on a collection of
 > assessments, of which the DKIM mechanism is only a part. In this model, as
 > shown in Figure 1, validation is an intermediary step, having the sole task
 > of passing a validated Responsible Identifier to the Identity Assessor.
...
 >      The Identity Assessor uses this
 > single, provided Identifier for consulting whatever assessment data bases
 > are deemed appropriate by the assessing entity. In turn, output from the
 > Identity Assessor is fed into a Handling Filter engine that considers a range
 > of factors, along with this single output value.

and the accompanying figure:

   <http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.figure.1>

along with:

   <http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.section.2.4>
and
   <http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.section.2.5>

d/

-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 24 Aug 2010 12:11:38 -0400

Let's rock!

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Tuesday, August 24, 2010 11:54 AM
> To: MH Michael Hammer (5304)
mua
> The second is that we've been struggling with finding the right
language
> for
> describing systems issues about DKIM.  Note that we even managed to
write
> a
> protocol document without defining the protocol's output, which is why
we
> needed
> an errata document. So we need to be careful about using RFC 4871
outside
> of the

Why yes we do need to be careful <G>

> implementation in the email infrastructure rather than email end
systems.
> non-interoperable.  (This is a version of the same logic we all
debated we
> had

I think a better way of describing it would be that reputation systems
are a nice subset of what is in the right arena.

> I wasn't aware that my statement was offered as a quotation.  I
certainly
> didn't

Your statement was taken (at least by me) as an assertion that begged
for supporting evidence.

> 
> On the other hand...
> 
> >> If we look at additional DKIM related RFCs, the only explicit use
of
> the

I read it and I reread it and I still nothing that supports your
assertion that the main purpose is assessment by reputation filtering
engines.

> Overview, RFC 5585,
<http://dkim.org/specs/rfc5585.html#rfc.section.5>:
>  >   the signer and that information is passed to the message
filtering
> system.

Still doesn't indicate "primacy", only that reputation can be part of
the process.

>  >  mark -- a message. Filtering Engines have become complex and

"popular" does not equal primary.

>  > assessments, of which the DKIM mechanism is only a part. In this
model,
> as
>  > shown in Figure 1, validation is an intermediary step, having the
sole
> task
>  > are deemed appropriate by the assessing entity. In turn, output
from
> the
>  > Identity Assessor is fed into a Handling Filter engine that
considers a
> range
>    <http://dkim.org/specs/draft-ietf-dkim-deployment-

And yet again I read and I reread but find nada that says reputation is
primary. Perhaps if you had said "In my humble opinion reputation is the
primary...."

I remember that we collectively kicked the can down the road by saying
what someone did with the value returned in evaluating a message for
DKIM was out of scope.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 24 Aug 2010 09:31:30 -0700

On 8/24/2010 9:11 AM, MH Michael Hammer (5304) wrote:
>> certainly didn't intend it to be.
>
> Your statement was taken (at least by me) as an assertion that begged for
> supporting evidence.

I thought you were questioning the precise wording.

As for 'supporting', sorry for assuming that folks on this list were 
sufficiently familiar with the follow-on work done by this group...

>>> A module that consumes DKIM's mandatory payload, which is the responsible
>>> Signing Domain Identifier (SDID).  The module is dedicated to the
>>> assessment of the delivered identifier.
...
> I read it and I reread it and I still nothing that supports your assertion
> that the main purpose is assessment by reputation filtering engines.

Wow.

You don't think that "The module is dedicated to the assessment of the delivered 
identifier." has that meaning?  What exactly do you think it /does/ mean?

>>> If the signature passes, reputation information is used to assess the
>>> signer and that information is passed to the message filtering system.
>
> Still doesn't indicate "primacy", only that reputation can be part of the
> process.

Really?  You want this exchange to hinge on my use of an emphasis?

As for my use of 'reputation', that's a convenient label that is popularly used 
to refer to an assessment phase.

Perhaps the question should be:  If you are that uncomfortable with the language 
I used, what alternative language would you offer.  Having that would allow some 
best-fit comparison.

>> and<http://dkim.org/specs/rfc5585.html#rfc.section.5.5>
>>
>>> 5.5. Assessing
>> ...
>>> A popular use of reputation information is as input to a Filtering
>>> Engine that decides whether to deliver -- and possibly whether to
>>> specially mark -- a message. Filtering Engines have become complex and
>>> sophisticated.
>

By some popular measures, it does.

I'll assume that it's too early in the day for you to have started drinking, so 
I'll have to admit to confusion about this exchange.  If it's just to take shots 
at me, while I readily acknowledge my convenience as a target, that's better 
done offline.  If it is for a constructive purpose, such as improving group 
understanding about DKIM, please suggest superior language.

Although I certainly thought that the citation base I supplied was more than 
sufficient, you appear to be particularly sensitive to specific vocabulary.

> I remember that we collectively kicked the can down the road by saying what
> someone did with the value returned in evaluating a message for DKIM was out
> of scope.

First, I believe in self-awareness.  For better or worse, at the least, this 
requires my acknowledging that I never view my opinion as humble.

Second, you appear to be seeking to enforce a linguistic etiquette for the list 
that is exceptional.  Possibly a good idea, but certainly not well-established.

Third, I think that the citation base did amply justify the focus of my 
statement.  Most especially, the diagrams and accompanying discussion that I 
cited entirely supported my comment, IMNSHO.

Fourth, there is a difference between saying that the /details/ are out of scope 
and saying that the /construct/ is out of scope.  This is tied directly to the 
construct of DKIM's delivering a specific payload.  The delivery crosses a 
processing line, to another module.  While DKIM does not get to specify the 
internal details of that module, it has to have some basic sense of what the 
module is for.

Otherwise, there's no understanding of the purpose that DKIM is intended to satisfy.

Oh.  Wait.  That's exactly the confusion that is so often demonstrated on this list.

Such as right now.

Perhaps we should endeavor to fix that?

Oh.  Wait.

I thought we did...

d/
-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 24 Aug 2010 13:43:19 -0400

And the bell rings for the next round....

> Sent: Tuesday, August 24, 2010 12:32 PM
mua
> responsible
> assertion

One can assess based on policy rather than reputation. In fact I can
think of several companies that popped up recently in this general space
(email authentication) to do just that.

the
> Really?  You want this exchange to hinge on my use of an emphasis?

Absolutely. Primary as you used it has a very specific meaning..... or
are we introducing fuzzy logic to the world of standards development and
implementation?

> As for my use of 'reputation', that's a convenient label that is
popularly
> used

Reputation is one subset of the possible implementations of assessment.

> Perhaps the question should be:  If you are that uncomfortable with
the
> I used, what alternative language would you offer.  Having that would

I am quite comfortable with what Wietse wrote. I was going to respond to
his post with a +1 for each of his points.

> By some popular measures, it does.

Careful for what you ask for. If we are going to reduce this to simply a
popularity contest.....

> I'll have to admit to confusion about this exchange.  If it's just to
take
> shots

I am content to leave it as "email authentication, including DKIM is a
useful and good thing. The more that DKIM signing is implemented, the
greater the opportunity for receivers/evaluators to do useful things".

If reputation floats your boat then knock your socks off. I seem to
remember a venerable member of this list floating a proposal that wasn't
supposed to compete with reputation..... AffiL or something or other. 

Just to lighten things up, a music commentary on reputation compliments
of Joan Jett - http://www.youtube.com/watch?v=5RAQXg0IdfI

> Although I certainly thought that the citation base I supplied was
more
> than
> what
> > someone did with the value returned in evaluating a message for DKIM
was
> out
> > of scope.
> 
> First, I believe in self-awareness.  For better or worse, at the
least,
> this

Aw, I stand corrected. Humble or not your opinions are always
interesting and valuable, my prodding today notwithstanding. 

> Second, you appear to be seeking to enforce a linguistic etiquette for
the
> list

Exceptional? I think not but I'm too busy at the moment to wade through
the archives to provide examples.

> statement.  Most especially, the diagrams and accompanying discussion
that
> I
> Fourth, there is a difference between saying that the /details/ are
out of
> scope
> and saying that the /construct/ is out of scope.  This is tied
directly to
> processing line, to another module.  While DKIM does not get to
specify
> the
> internal details of that module, it has to have some basic sense of
what
> the
> module is for.
> 
> Otherwise, there's no understanding of the purpose that DKIM is
intended
> to satisfy.

Of course there is. I refer you to the post from Wietse today. 

> Oh.  Wait.  That's exactly the confusion that is so often demonstrated
on
> this list.

I don't think I'm confused. I have roughly a billion signed messages
under my belt and the feedback I'm seeing from various receivers
regarding dispositions indicates that handling based on assertion from a
1st party signer can work very well sans reputation engine. I'm just not
in a position to provide details at this point because while I may have
access to various data streams I do not own those data streams. 

> Perhaps we should endeavor to fix that?

Perhaps we should.

> I thought we did...

Guess not.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 24 Aug 2010 11:24:18 -0700

> (email authentication) to do just that.

That sounds as if the primary concern was with my use of the word 'reputation'. 
  Whereas I normally use the word "assessment", because it is less loaded with 
semantic baggage, I chose the much more popular term reputation as the generic 
label.  I'm not happy that's the publicly preferred term, but it is.  And the 
way average folk use it, it covers everything, including policy.

So if the real issue is with being more precise and differential, I'm certainly 
fine with that.  Again, please suggest alternative language for the text used. 
Not just specific vocabulary comments, but replacement sentences.

> Reputation is one subset of the possible implementations of assessment.

So, indeed, it appears the disconnect was between popular usage and more precise 
technical usage.  At the level my note was working,I meant the former.

> the language
>> I used, what alternative language would you offer.  Having that would
>> allow some best-fit comparison.
>

In terms of specifying constraints on a receiver, his language is accurate: 
DKIM does not constrain usage.  However my comment was about intent and the 
intent of DKIM was to design a replacement for using IP Addresses in anti-spam 
efforts, which means filtering engines.

> Careful for what you ask for. If we are going to reduce this to simply a

That's what rough consensus is, in socio-politico terms.

> greater the opportunity for receivers/evaluators to do useful things".

Whereas I believe the term "authentication" has proven highly misleading.  It's 
a labeling technology, where the authentication of the label is actually 
secondary to the presence of the assertion of the label.

And the key aspect of that secondary point is that the only thing being 
authenticated is the label.

> supposed to compete with reputation..... AffiL or something or other.

Again, I used 'reputation' as a synonym for 'assessment' and Affil certainly 
conforms to that.  If you want to deride usage of reputation in that way, 
complain to the bulk of the anti-spam community, not me.

> interesting and valuable

wow.  I thought you knew me better than that...

>> the list

"Exceptional" is a statistical assertion.  To that end, "examples" do not 
suffice.  My point was about dominant mode, not occasional moments of light and 
precision.

d/

ps.  If we have correctly identified the core disparity as being between my use 
of the word "reputationa" which I meant extremely broadly as a synonym for 
"assessment" and your preference for using it only as a narrow and subordinate 
term under some more generic label, then I think we are not in disagreement 
about the concept and only debating vocabulary.  If that's true, this thread has 
probably run its course.

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Aug 2010 11:17:21 -0700

On 8/23/10 8:05 PM, Dave CROCKER wrote:
> > Taking an approach saying we don't care if DKIM survives MLMs is a
> > step in the opposite direction. This is not a proposal I support.
>
>  Not really, since it was known from the start that survival through
>  an MLM is highly problematic and the steps towards helping survival
>  were known to be quite limited.
>
>  Requiring survival is a change in DKIM's goals, as well as raising a
>  massive barrier to adoption, given the history of a) challenge in
>  adoption for any infrastructure sequence, and b) resistance by MLM
>  developers and operators.
>
>  In other words, this line of efforts is seeking to raise the
>  requirements for DKIM.  Absent compelling and demonstrated functional
>  need, that makes it at best a distraction and at worst
>  counter-productive for DKIM's main purpose.

Agreed.

>  The most important reputations to assess are the entities that are
>  'responsible' for message.

Strongly Disagree.  The SMTP client represents the most important entity 
responsible for issuing the message.  DKIM was never intended to provide 
a reputational basis for email acceptance.  DKIM does not indicate where 
a message had been initially sent.  It may indicate who initially 
handled a beginning portion of the message body, but this limitation 
fails to provide an adequate basis upon which reputations can be 
based.   A primary criteria for assessing unsolicited email is where the 
message had been sent, especially when content is of little benefit to 
its recipient.

As such, efforts to accept IPv6 email is unlikely to find DKIM a 
suitable basis.  Perhaps soon SMTP can develop an SMTP Auth that 
combines use of a DKIM key together with a work product of keyassure.  
Identification of the SMTP client truly represents the entity 
responsible for issuing undesired messages.  After all, the bulk of 
today's email would be extremely difficult to categorize based upon the 
possible presence of DKIM signatures.

In special cases, where the entirety of users within a domain is 
trusted, DKIM then provides a method in which a recipient can both 
accept these messages, and possibly identify suspicious messages that 
might be attempting to mislead the recipient.  Unfortunately, DKIM lacks 
a suitable policy construct that is better able to assist recipients, 
even with this small fraction of emails, due to issues related to 
third-party services.

DKIM ensures the authentication status of users on whose behalf a 
message was signed remains unknown.  For a small fraction of the 
domains, DKIM might offer recipients a basis for sorting messages into 
trusted and suspicious categories.  As such, for the majority of 
messages, the only reputation upon which acceptance can be based is that 
of the SMTP client.

>  An MLM creates the message.  That the message might look a lot like
>  one sent /to/ it is nice, but it's also confusing.  The original
>  author is not, ultimately, responsible for what the MLM chooses to
>  send.

Agreed.  This affirms the SMTP client represents the important entity 
for what is being sent.

>  All of this prompts a repeat of an underlying question:  What is the
>  purpose of this exercise and how is it justified within the charter?
>
>  With respect to MLMs, I thought the focus was on documenting
>  realities and passing through MLMs and to explore issues and
>  opportunities better integrate MLMs into DKIM.  That's quite
>  different from trying to alter the core DKIM capability to support
>  survival through MLMs.  I'm pretty sure that changing DKIM Core is
>  not within our charter.

Agreed.

-Doug

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 24 Aug 2010 14:59:14 -0400

> d/
> 
> ps.  If we have correctly identified the core disparity as being
between
> my use

Then it would appear that we are substantially in violent agreement.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 24 Aug 2010 12:07:24 -0700

> Then it would appear that we are substantially in violent agreement.

in spite of our best efforts.

d/
-- 

   Dave Crocker

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 24 Aug 2010 21:31:05 +0200

> in spite of our best efforts.

may I suggest we stop here for a moment and get back to the original 
question, which in essence was: should a 1st signer DKIM signature be 
preserved 'coûte que coûte' when a message is handled by a MLM, or not. 
To answer this question I'd like to quote the excellent summary of what 
DKIM is about, posted earlier today by Wietse:

> The DKIM signature
> provides a simple piece of trace information ("I handled this mail")
> that is cryptographically bound to some header and body content.
>
> The receiver can use this trace information for any purpose that 
> she deems suitable. 

I think most of us can agree with this summary of what DKIM really is, 
without all the bells and whistles we often like to attribute to it. 
Next we add a quote from Dave about what the MLM does:

> ultimately, responsible for what the MLM chooses to send

Again, most of us will agree with this, I assume. Now combining the two, 
and _without focussing on any hypothetical action of a verifier or 
recipient_, the conclusion must be that the MLM adds its own  
DKIM-signature, leaving the original DKIM-signature(s) untouched. After 
all, removing the original DKIM signature would mean removing a piece of 
trace information provided by the originating domain. And once it's 
gone, it's gone. Leaving the original DKIM signature untouched is in 
line with chapter 4 of RFC4871 including par. 4.2 that states:

>    Signers SHOULD NOT remove any DKIM-Signature header fields from
>    messages they are signing, even if they know that the signatures
>    cannot be verified.
>   

I haven't found any text in the erratum of 4871 / 5672 that obsoletes 
this text. This means we can treat (regarding this particular aspect) 
MLMs like any other re-signing agent, no exceptions are required.

And yes, this means my opinion changed, I no longer advocate the use of 
multipart/alternative to preserve the 1st signer DKIM signature, instead 
it is my opinion now that an MLM should leave it untouched (and not 
remove it). I have come to this conclusion by looking at what DKIM is, 
and carefully avoiding looking at what a verifier or recipient might 
possibly do with the information it provides. We should not change the 
essentials of DKIM for sake of MLM transparancy; the best we can do is 
document the status quo of the combination of DKIM and MLMs, its 
problems and (within the boundaries of the DKIM spec) any hints that can 
solve or mitigate those problems.

/rolf

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 24 Aug 2010 16:07:52 -0400

> From: Rolf E. Sonneveld [mailto:[email-masked]]
> Sent: Tuesday, August 24, 2010 3:31 PM
> To: [email-masked]
> Cc: MH Michael Hammer (5304); [email-masked]
> Subject: Re: [ietf-dkim] Mailing lists and s/mime & dkim signatures - mua
> considerations
> 
> Dave CROCKER wrote:

I am somewhat agnostic on the question of preserving DKIM signatures when a message is handled through MLM. Intuitively I would like them preserved and I believe that MLMs can preserve them if they are interested in doing so. 

If I were running an MLM (I have done so in the past but do not currently do so) I would certainly respect an ADSP=discardable assertion and ensure that I handled messages accordingly (more than one way to skin a cat).

As John has pointed out on numerous occasions, it should not be demanded of MLMs that they change their ways to accommodate anything new under the sun (paraphrasing here) because they have been around for as long as they have and done quite nicely thank you very much.

Darwin was right.

To the extent that ill-intentioned individuals find MLMs (and email accounts posting through MLMs) interesting targets in the future, those MLMs that are unfriendly to email authentication are likely to find themselves at greater risk than those MLMs which are friendly to email authentication. There are varying ways in which an MLM can deal with this issue. I for one wouldn't dream of attempting to dictate to them what they must or must not do.

Receivers are not stupid and will respond to such evolving circumstances as they may in the interests of their endusers as well as their own reputation. I for one wouldn't dream of attempting to dictate to them what they must or must not do.

In any event, I perceive MLMs as the tail that appears to be wagging the dog. In the context of email authentication, there are so many much more interesting mail streams from my perspective.

> MLMs like any other re-signing agent, no exceptions are required.

Rolf, you have sidestepped the issue of digests or do you feel this holds true for them as well?

> possibly do with the information it provides. 

Interesting. 

>We should not change the

I absolutely agree with your last statement.

Mike

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 24 Aug 2010 21:57:14 +0100

> highly problematic and the steps towards helping survival were known to  

Nevertheless, there IS a solution that MLMs can use which will ensure  
survival through an MLM. Yes, it has a few downsides, but then so do all  
the other "solutions" suggested. Someone (the MLM for this particular  
case) has to evaluate the tradeoffs. If it is likely to be suitable for  
.some. MLMs, then it ought to be included in Murray's arsenal of possible  
mitigations.
> massive

Indeed. We will not REQUIRE survival, but some MLMs might like to provide  
it. A resistant MLM may suddenly find his list is not working as intended,  
due to discarding of mis-signed messages. We can't force him to drink our  
water; we cannot even lead him to it; but at least we should point out  
where it is.

-- 
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: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 25 Aug 2010 00:20:33 +0200

MH Michael Hammer (5304) wrote:

[...]

> In any event, I perceive MLMs as the tail that appears to be wagging the dog. In the context of email authentication, there are so many much more interesting mail streams from my perspective.

+1

>>> one sent /to/ it is nice, but it's also confusing.  The original author
>>>       
>> is not,
>>     

Sidestepping the issue of digest was not intentional, I just forgot to 
include them in my previous message. Most MLMs these days create digests 
by concatenating a number of messages, where for each message a subset 
of header lines + the body are presented. In that situation any 
DKIM-signatures, which may have been present in the original message(s), 
are lost.

Murray writes in the DKIM and Mailing Lists I-D about the digest type:

>    digesting:  A special case of the re-posting MLM is one that sends a
>       single message comprising an aggregation of recent MLM submissons,
>       which might be a message of [MIME] type "multipart/digest" (see
>       [MIME-TYPES]).  This is obviously a new message but it may contain
>       a sequence of original messages that may themselves have been
>       DKIM-signed.

If (repeat: if) the logic of my previous message applies (the MLM should 
leave already present DKIM-signatures untouched) this could lead to the 
following suggestion/recommendation for MLMs:

"MLMs should not remove DKIM signatures when assembling digest messages.

This can be achieved by using the following rules:

a) when digesting the multipart/digest MIME type/subtype should be used, 
according to RFC2046 and
b) for each message that is part of the digest, copy the entire 
(header+message) into a message/rfc822 part and
c) re-sign the message with the MLM DKIM Signature on the outer-level 
header of the enclosing message

As a) will have impact on the recipients of those digest messages, the 
MLM should insert a 'Table of Contents' of all contained messages before 
the first message/rfc822 part (a number of MLMs already do this). And, 
in addition to this, the MLM optionally can add Content-ID's for each 
message/rfc822 part (if the Content-ID is not already present and not 
part of the DKIM signature) . The ToC then can link items to the 
corresponding Content-ID of the enclosed message. If the original DKIM 
signature refers includes a content-id field, then the MLM must not add 
a content-id to the header of the message/rfc822 bodypart."

Although DKIM does not specify (as far as I know) what to do with DKIM 
signatures in inner bodyparts, I think DKIM signatures should never be 
removed without a good reason.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Tue, 24 Aug 2010 19:47:20 -0400

> removed without a good reason.

If you believe this, then you have to advocate the removal of the RFC 
4871 mandate regarding invalid signatures changing to no-signature 
status as if it never existed and the message was never signed.

What this means is that if a MLM keeps broken tracings of signatures, 
the only existing trace signature is the valid one.  All others must 
be ignored.

---

From: Hector Santos <[email-masked]>
Date: Tue, 24 Aug 2010 20:57:13 -0400

Dave,

The term "Reputation Filtering Engines" (RFE) is understood in what it 
means.  Currently proprietary solutions.

Absolutely wrong with that.  But if you are saying this include policy 
or more specifically the IETF DKIM Working Group work item RFC 5617, 
this I don't see a problem in your statement other to remind you RFC 
5617 is not about reputation.  Certainly a RFE vendor may incorporate 
RFC 5717 and this should be made public.

Maybe it might help to change your usage of Reputation Filtering 
Engines to a more general concept such as Validation Assignment 
Engines (VAE).

    DKIM's main purpose is assessment by Validation Filtering Engines.

These VFE include the proposed IETF WG standard such as RFC 5717, 
which has to mentioned first over anything else, and those seen in 
practice with SSA (Special Signing Arrangements) and Reputation - both 
non-standard approaches.

---

From: Hector Santos <[email-masked]>
Date: Tue, 24 Aug 2010 20:58:51 -0400

Hector Santos wrote:
> Absolutely wrong with that.  

Sorry, missing word - "Absolutely NOTHING wrong with that"

---

From: "John R. Levine" <[email-masked]>
Date: 24 Aug 2010 21:35:53 -0400

> preserved 'coûte que coûte' when a message is handled by a MLM, or not.

The answer is yes, sure, but that's the same answer I'd offer if you asked 
if spammers should set the evil bit (RFC 3514) when sending their mail.

As others have noted, list software does what it does, list managers do 
what they do, and the chances that they will do anything we ask drop 
radically as we make more demands on them.

I think it's reasonable to encourage them to put a list signature on 
outgoing mail.  It'll probably help them get the list mail delivered, and 
in the common case that the MLM uses some other program as its MTA, some 
tweak to the MTA will likely be adequate, so they won't have to mess with 
the MLM's configuration.  (I speak from experience here.)  Beyond that, we 
can make suggestions, but we've dropped off the cliff.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Tue, 24 Aug 2010 20:17:18 -0700

>> preserved 'coûte que coûte' when a message is handled by a MLM, or not.

It shouldn't, at least not if it means the MLM has to modify it's behaviour significantly. Subject line tags, unsubscription footers, that sort of thing are all useful features that shouldn't be sacrificed at the altar of theoretical ADSP corner cases.

> 
> The answer is yes, sure, but that's the same answer I'd offer if you asked if spammers should set the evil bit (RFC 3514) when sending their mail.
> 
> As others have noted, list software does what it does, list managers do what they do, and the chances that they will do anything we ask drop radically as we make more demands on them.
> 
> I think it's reasonable to encourage them to put a list signature on outgoing mail.  It'll probably help them get the list mail delivered,

It won't hurt.

> and in the common case that the MLM uses some other program as its MTA, some tweak to the MTA will likely be adequate, so they won't have to mess with the MLM's configuration. (I speak from experience here.)  Beyond that, we can make suggestions, but we've dropped off the cliff.

Warning list managers that accepting mail from individuals at ADSP using domains may cause operational problems for the list operator and other subscribers is something that's been mentioned previously.

Cheers,
 Steve

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 25 Aug 2010 10:58:32 +0100

> status as if it never existed and the message was never signed.

Not so. A retained, but now invalidated, signature should have no effect  
on the behaviour of an assessment engine (well almost so - it might like  
some assurance that it HAD been signed previously before proceeding to  
consideration of the trustworthiness of the MLM's signature, but an A-R  
header would provide that).

No, the purpose of retaining that signature is primarily for forensics.  
Given that it is meaningless for protocol purposes for the reasons you  
gave, it cannot possibly do any harm. Destroying it would do some minor  
harm (hindering any forensic investigation). It would also frustrate geeks  
who might like to reconstruct the original signed message for verification  
purposes, but they are not the primary custimers of any retention. It is  
simnply a matter of not destroying potentially useful evidence.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Aug 2010 09:50:16 -0700

Agreed.
Agreed.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 25 Aug 2010 12:17:49 -0700

>> From: Rolf E. Sonneveld [mailto:[email-masked]]
 [ . . . ]

+1

So what we SHOULD be arguing about (those of us interested in forward progress) is whether draft-ietf-dkim-mailinglists-02 meets the documentation goal Rolf described above.

---

From: Hector Santos <[email-masked]>
Date: Sat, 28 Aug 2010 10:03:58 -0400

Steve Atkins wrote:
>>> preserved 'co�te que co�te' when a message is handled by a MLM, or not.
> 
> It shouldn't, at least not if it means the MLM has to modify 
> it's behaviour significantly. Subject line tags, unsubscription 
> footers, that sort of thing are all useful features that shouldn't 
> be sacrificed at the altar of theoretical ADSP corner cases.

I don't think anyone suggested or take seriously any suggestion to 
change the MLM long history and accepted practice of altering the 
original integrity of list message submissions.

We are saying that to for an MLM to implement DKIM (something new) it 
will need to also look at issues regarding the destruction of such new 
mail and one way to do this is to not do it by supporting a companion 
WG proposed standard and hint called policy (ADSP) which tells the MLM 
it is about to break a new type of secured and protected domain 
message by ignoring the policy hint. It is telling the MLM the message 
wasn't expected to be in the MLM environment in the first place. The 
MLM is allowed to throw it away.

But if there is no policy, the domain didn't care and the MLM can do 
what it normally does, including adding a new signature and removing 
broken ones so it can perhaps taste like a good clean dkim message again.

I don't see anything wrong with implementing this logic in software. 
I see no down side other than do a low cost DNS lookup for the message 
submission author domain ADSP record.

The only engineering argument one can have is that this will be 
redundant wasted overhead on the highly non-engineering subjective 
presumption that no one will ever support ADSP.   Well, if the WG 
truly believes, then why do we continue wasting time on a WG working 
documents called ADSP and MLM?  Get rid of it.

But while it is still on the WG table, I don't think it is logical to 
be telling engineers to ignore it (Look but don't touch) and expect 
things will work flawlessly based on unproven statistics and 
probability of non-support.

I personally believe strongly POLICY will well received for outside 
list usage once we can get the key people writing the docs to finally 
stop against it and accept it as a DKIM technology and allow 
developers to begin add it to there APIs once again, just like the two 
original open source DKIM API had built-in support for SSP and there 
were R&D domains exploring it before ADSP stripped down SSP and 
created a "wait and see" attitude.  The problem?  Its no fun adding 
software with a WG standard that won't be followed at the suggestion 
of its authors.

---

From: Hector Santos <[email-masked]>
Date: Sat, 28 Aug 2010 10:29:19 -0400

Hector Santos wrote:

> The problem?  Its no fun adding software with a WG standard that 
> won't be followed at the suggestion of its authors.

But that I mean any developers that wish to support the the WG 
Documents are put into a catch-22 position regarding DKIM and ADSP 
implementation.  It applies to operators as well.

Using myself as an example:

I wish to help further protect my brand and corporate domains with 
DKIM and ADSP so that only we can sign it and no one else. I have 
unsubscribed from various list and switched to a non-DKIM protected 
domain, like here.

I can't DKIM sign my mail because I believe raw DKIM-CORE signing will 
water down my domain reputation and brand by feeding ammunition to 
spoofers that its ok to sign it with unknown 3rd party signers.  I 
want no non-standard DKIM-STATS based verifier to learn that this 
association is valid.

But I can't add a ADSP record without adding DKIM signatures since 
that might cause false positive rejections/discard.

Its a catch-22 implementation issue and the "wait and see" attitude is 
only going to show want is already predictable - low support for ADSP. 
If one can no longer wait or wants to add DKIM they had to accept the 
idea that ANYONE can sign on their behalf without any controls.

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 30 Aug 2010 16:53:59 -0400

> So what we SHOULD be arguing about (those of us interested in forward progress) is whether draft-ietf-dkim-mailinglists-02 meets the documentation goal Rolf described above.

Nits:

existing misspelled below:

o  What are the tradeoffs regarding having an MLM remove exisitng
      DKIM signatures prior to re-posting the message?

Section 3.3 - last paragraph, "the" misspelled - "before hte message"

Below are my comments on draft-ietf-dkim-mailinglists-02. I have
caught up with the mailing list posts as of today (well, within the
last 3 hours or so), but I haven't retained in my head what others
have already said. If some of this has discussed already, I apologize.
I think we are very close to Rolf's stated goals.

Section 1.3 - I'd change "bulk mail sender" to just "sender". I have
trouble seeing how any bulk sender would end up sending to a MLM.

Section 3.1:

author - is it really defined that way in email-arch? That definition
would mean an ESP would be considered the author. As an ESP we
construct messages from content objects created by our clients. I'm
having trouble with the word "constructed" in that section. Perhaps
"The agent that actually created the content of the message....". I
really don't like that either. I'd like to say the agent that authored
the message. :) Think in terms of books.

signer - Last sentence: A signer may also be same agent as an
originator or author.

3.2 MLM Output: why is the MLM considered the author? Shouldn't it be
the originator?

"consuming the author's copy of the message and creating its own."
seems a little off to me. I get what it is trying to say, but I think
a gentler view would be to view it as a newspaper. Each article has
it's own author and the newspaper presents a group of articles along
with a other interesting content. So maybe "consuming the author's
copy of the message and producing a mailing list version of that
message."

3.3 Is the reference to John L needed? :)

"There reportedly still exist a few scattered mailing lists in
operation that are actually run manually by a human list manager,
whose workings in preparing a message for distribution could include
the above or even some other changes."

Section 5.7

"A signing MLM is advised to add a List-Post: header field (see
[LIST-URLS]) using a DNS domain matching what will be used in the
"d=" tag of the DKIM signature it will add to the new message...."

I'd remove this paragraph. I strongly believe that d= needs stands on
its own. Anything that promotes the notion of that a class of d= is
more or less than another because it matches some other header field
or not should be discouraged.

Section 5.9

I don't really understand why we need this section at all. Perhaps I
can buy someone a beer in DC to help me understand it. (ah, B.2 helps,
a little)

Section 5.10

Why 5.7.2 instead of 5.7.1? There is no expansion going on at the receiver.
I don't agree with the last paragraph. I don't see rejects causing
more harm than good. Section 5.10 is targeted for receivers. The
subscribers of the mailing lists. Since this document is targeted at
MLM, how are we expecting subscribers to pay attention to this
section?

-- 
Jeff Macdonald
Ayer, MA

---

From: Daniel Black <[email-masked]>
Date: Tue, 31 Aug 2010 14:45:13 +1000

On Tuesday 31 August 2010 06:53:59 Jeff Macdonald wrote:
> > So what we SHOULD be arguing about (those of us interested in forward
> > progress) is whether draft-ietf-dkim-mailinglists-02 meets the
> > documentation goal Rolf described above.
> 
> Nits:
> 

I'm in favour of keeping this paragraph. A small bit of advice, like the 
current -02, provides some hope of a small bit consistancy for those writing 
receiving agents (e.g. 5.9 / 5.10) that want to do some intelligient 
processing without adding with complexity. Less (options) is more (value).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html