Subject: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations

From: Daniel Black <[email-masked]>
Date: Sun, 15 Aug 2010 13:50:13 +1000

I intially saw a need for a MUA considerations because:
* I still hope DKIM will help protect email identity
* end users rely, or should rely, on their MUA to present verified identity 
information in an easily digestable way.
* MLMs break signatures and MUA will still need to present verified identity
* List identity is important to users as having no differenciation at the MUA 
between broken list signatures and phishing email
* List identity can be acheived with list DKIM signatures (as recommended) 
potentially coupled with a LDSP proposal that Hector mentioned. 
* MTAs at gateways are incapable of reliabily determining an individual end 
users' mail subscriptions.

If users are to place value in From headers as MUAs display and ADSP tries to 
enforce then manguling From headers is adds complexity to the interpretion of 
the header field by to the end user.

The advent of this draft as a informational standard, combined with ietf-marf-
dkim-reporting and RFC5451(Authenticated Results) and the desire to make dkim-
friendly lists will drive the dominate scenarios in the future.

Looking at a fingerpring mail client survey[1] survery it seems that the 
occurance of a few major web based email clients accounts for 35% of email 
traffic. Assuming a consistant correlation with email list subsribers there 
are a potentially a number of DKIM/list incompatible behaviours that can be 
rapidly adapted at the MUA. Even excluding the webmail suppliers the number of 
MUA vendors is quite small and therefore adaptable to the current need. The 
webmail MUAs can rapidly change to give the user the identity information that 
they need to identify orginal domains and a number of these are driven by MLM 
and DKIM considerations.

As such here is a proposed annex to draft-ietf-dkim-mailinglists that 
corresponds to Murray's request in the response to the first review request  
in the hope that MUAs will provide the valuable identity information that DKIM 
provides even in the presence of MLM.

[1] http://fingerprintapp.com/email-client-stats

ANNEX A - MUA Considerations

The main body of this document describes a number of MLM behaviours that break 
DKIM signatures. These behaviours are, in some cases, features required by MLM 
operators to forfill technical, policy or legal requirements. Some of these 
behaviours operate in such a way that breaks DKIM signatures and have 
alternate implementations that will also meet the needs of MLM operators.

Header Footer additions

Header/Footer additions on MLM can include unsubscribe information describing 
to the user how to unsubscriber from a MLM

MLM are recommended by LIST-ID to include a List-Unsubscribe header field. In 
the presence of MUA support this would depreciate the necessity of  
Header/Footer additions for unsubscribe information.

MUAs are recommended to present to the user the List-Unsubscribe header field 
URL in such a way that they can utilize this URL easily to unsubcribe from the 
email list.

Subject Header Modifications

A reasonable number of MLM list subscribers potentially still recognise and 
filter messages based on the subject line. The subject line modification is as 
effective as a List-ID filtering and MLMs are recommended to include this 
header field.

A MUA could implement the following features to reduce the need for signature 
modifications: 
* Display of the List-ID header field is used to be displayed beside where a 
subject header field is displayed.
* functionality to create a filter based on based on the List-ID header field.

Authenticated Results

[AUTH-RESULTS] describes how a MUA could use the Authenticated-Results heaader 
field to present DKIM validation information to the user. This is particularly 
important where the presence of broken author domain signatures are present 
and the presence of MLM dkim signatures may be used for alternative 
authenticity or filtering determinations.

A MUA could use the Authenticated-Results header field to:
* Display what authentication was performed by the verifier
* Create a display and filtering options based where on common domains occur 
in list-post header fields and DKIM signatures (recommended in section 5.7) 

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

---

From: John Levine <[email-masked]>
Date: 15 Aug 2010 18:41:43 -0000

>information in an easily digestable way.

Hmmn.  Not to be unduly snarky, but I have the impression that this is
some other DKIM than the one defined in RFC 4871.

DKIM associates a signing identity, which is a domain name, with a
message.  That's all it does.  It has nothing to do with "verified
identity information" by which I'm guessing you mean something about
the contents of the From: line.

There are other IETF standards that may be useful for your purposes.
Please look at RFCs 5750 through 5755, the latest version of S/MIME,
which associates an X.509 signature with the MIME body of a message.
The signature includes various identity attributes of the signer,
generally including a name and e-mail address, and is itself signed by
a mutually trusted signing agent.

Nearly all MUAs in use today have S/MIME support built in, or at worst
an easily installed plug-in.  Since you say you're interested in
having MUAs present verified identity information, which they do right
now, automatically, with S/MIME signatures, I'm kind of surprised
you're not using it now.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 15 Aug 2010 16:25:06 -0700

> * I still hope DKIM will help protect email identity

"email identity" is an ambiguous term.

All sorts of value-added enhancements might be possible, on top of DKIM, but 
"protecting email identity" isn't really what DKIM is defined to do.

> information in an easily digestable way.

Human usability issues with respect to security is, at best, extremely poorly 
understood.  The state of the design art appears to have no idea what is effective.

> * MLMs break signatures and MUA will still need to present verified identity

As noted, you are seeking to have DKIM perform functions it was not designed to 
perform.  There should be no surprise that it falls shy of your desired mark.

d/
-- 

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

---

From: Daniel Black <[email-masked]>
Date: Mon, 16 Aug 2010 11:25:31 +1000

On Monday 16 August 2010 09:25:06 Dave CROCKER wrote:
> All sorts of value-added enhancements might be possible, on top of DKIM,
> but "protecting email identity" isn't really what DKIM is defined to do.

rfc4781 Abstract - last sentence. Still abstract however this was a general 
lead-in discussion.

> > * end users rely, or should rely, on their MUA to present verified
> > identity information in an easily digestable way.
> 
> Human usability issues with respect to security is, at best, extremely
> poorly understood.  The state of the design art appears to have no idea
> what is effective.

There are a number of significant papers on the topic available. Either way 
DKIM provides a domain responsibility signature and providing some information 
to the end user is useful. I agree that informational rfcs should stay away 
from design art however I do see a description of useful information as 
constructive to MUA implementors.

> As noted, you are seeking to have DKIM perform functions it was not
> designed to perform.  There should be no surprise that it falls shy of
> your desired mark.

While it seems to be the intent of many within this working group to define 
dkim in such a way that its only plausable use is dkim reputation, a little 
constructive thought to other benefits for verifiers, filters and recipients 
would be appreciated. If it could be done without snarky comments that would 
be even better.

Recipients are an important aspect of the message flow and an attempting to 
define a benefit to them from DKIM is an element of what I'm attempting to 
define.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 16 Aug 2010 11:25:16 +0100

> the header field by to the end user.

If the original was
    From: Joe Doe <[email-masked]>
and a recipient sees it as
    From: Joe Doe <[email-masked]>
then he will still have a pretty clear idea that it originated from Joe  
Doe, and may even be able to correctly guess Joe's original email address  
even if he is unfamiliar with the percent-hack.

> * functionality to create a filter based on based on the List-ID header  

I agree it would be a Good Thing if MUAs routinely displayed some of the  
List-* headers as a default feature.

But you seem to be suggesting that an MUA should be setup to accept  
mesages with a List-Id plus a valid signature from the MLM, even from a  
discardable origin.

Ignoring the fact that such emails may be already discarded by some  
boundary agent, that is still an open invitation to every Phisher to add a  
List-ID from some bogus list to every message he sends, and to add a valid  
signature from that bogus list (and perhaps even a deliberately invalid  
signature from the phished domain).

Somehow, MUAs need to be aware of which lists the user is subscribed to if  
they are going to do that sort of thing.

-- 
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: John Levine <[email-masked]>
Date: 16 Aug 2010 14:52:29 -0000

>Doe, ...

Actually, in both cases, most MUAs will show:

>From John Doe

It's the same thing it'll show if this is the From: line

   From: John Doe <[email-masked]>

As Dave often points out, this group has negligible expertise in user
interface design.

But these are certainly things you should put in an I-D about this
proposal.  Needless to say, none of this is appropriate for a document
describing what MLMs do now or are likely to do in the near future.

R's,
John

---

From: <[email-masked]>
Date: Mon, 16 Aug 2010 07:49:47 -0400

DKIM only asserts that a signer signed a message. Nothing more or less.

---

From: Hector Santos <[email-masked]>
Date: Mon, 16 Aug 2010 11:18:52 -0400

> they are going to do that sort of thing.

I think which keeps getting in the way here in molding ideas is that
much of it is based on online MUA access which does not always match
Offline MUA access, and there is a HUGE leap in faith that the backend
is going to be transparent and have no or lesser role in the filtering
(good or bad) process.

In short, we need more protocol consistency here.

With Online MUA access, the backend complete control what is going to
be displayed to the user. It can change the display at a single source
location and have it applied to all Online MUA access.

With Offline MUA access, it has no control on how the backend moves
its mail. It can a gating and/or conversion process. But in the end,
the Offline MUA when talking internet mail, has to conform to RFC
822/2822/5322.  The assumption that it will be a simple RFC to RFC
passthru would be a bad engineering assumption.

We have 5-6 different ways to access and display mail.  There are all
sorts of ideas to consider that could apply to what you want.

Again, the Online MUA has no say in whats shown. The backend has
complete control here.

The offline MUA, talking about the common RFC-based offline MUA, can
only "programmed" to see what you want it to see by altering what is
commonly displayed today, the three fields are:

    From:
    Subject:
    Body:

Today, the MLM adds a [LIST-NAME] for the Subject field.  At this
point, mail system designers will have an ethical problem with
altering the FROM:.   The MLM also alters the both with footers (some
do headers as well).

To depend on a LIST-ID offline MUA display would be a bad dependency
to count on.

However, to illustrate how a backend can do something things to help
support the OFFLINE MAU, as we did in a recent project for a Microsoft
Web Mail to NNTP Bridge for NNTP Reader support,

    http://opensite.winserver.com/wclex/default.wct

there were alterations done by the NNTP bridge to better emulation of
the online view of mail via an offline view of mail.  This was
required to help restore the TRUST or VALUE of the online message view
via an offline view.

For example:

Via Online MUA, the from might be:

   From: Joe Smoe [MVP]
   From: Tom Sawyer [MSFT]

The ROLE bit is part of the user database and is displayed that way.
When downloading the mail via the NNTP Bridge, that From: field info
is lost.

So the NNTP Bridge when it does the backend to RFC 2822/NNTP
conversion, it checks the user status and alters the From so it can
show these tags.

There are other poster "Trust and Value" factors that is shown via the
Microsft Web-based Forums view of the mail, such as:

    # of post made
    # of Stars Earned

The NTTP-bridge optionally provides information by including it the
2822.BODY at the top of the message view.

So the point is the backend can do a few things to help support the
offline view of mail as far as DKIM TRUST is concern.  This is not
protocol material, but more to the point that we need to not lose
focus we need to work out how the backend deals with DKIM first and
not depend on the OFFLINE MUA to do this for us.

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

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 16 Aug 2010 10:09:27 -0700

> rfc4781 Abstract - last sentence. Still abstract however this was a general

That's why the bis draft uses different language.  It's also why wg docs written 
aftr 4871 have been searching for better language.

> There are a number of significant papers on the topic available.

I've no idea what you mean by this.  If you mean that there's been research on 
security and usability, yeah that's true.  So what?

My point is that the track record for developing mass-market user interfaces 
that produce good security-related interactions with end-uses is essentially non 
existent.  My other point is that the level of the research on this topic, to 
date, is extremely limited and poor.

>  Either way
> to the end user is useful.

The assertion that it is useful is different from saying that the information is 
objectively meaningful.  To say it is useful, there must be some basis for 
knowing that users will actually be able to employ the information to a 
productive end.

The reality is that the minimal research that has been done so far suggests that 
such information more often confuses uses.  Their cognitive model of the system 
and especially of security issues is far, far more limited that folks tend to 
realize.  In addition, the presentation of the information is usually problematic.

> would be appreciated.

There is a difference between defining new semantics, versus applying existing 
semantics in new ways.  You appear to be doing the former.  That, therefore, 
goes beyond the DKIM Signing specification.

> define a benefit to them from DKIM is an element of what I'm attempting to

That's clear.  It's also beyond the skillset of this group.  It's also not 
required for DKIM to be useful.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Mon, 16 Aug 2010 15:38:34 -0400

Dave CROCKER wrote:

>> Daniel Black stated:
>>
>> Recipients are an important aspect of the message flow and an 
>> attempting to define a benefit to them from DKIM is an element of 
>> what I'm attempting to define.

> That's clear.  It's also beyond the skillset of this group.  It's also 
> not required for DKIM to be useful.

Can you provide information or evidence that exhibits DKIM usefulness
and how is the usefulness accomplished?

What augmented technology, method or skillset is required in order to
get the usefulness you see?

If this a future usefulness scope or is it something we can use today?

I ask because I am still looking for a payoff and justification to
support and add it to our mail software and what components within the
framework. I am having a hard time seeing DKIM usefulness.

---

From: Hector Santos <[email-masked]>
Date: Mon, 16 Aug 2010 15:55:56 -0400

Please note, these are honest questions because every quarter I have 
to decide what new finished work and features are going to be part of 
our quarterly software updates and revisions.  DKIM continues to be 
something to consider, "to add, not add or push aside again" because I 
can not find a concrete reason to add it - a payoff, some usefulness 
that can get extracted from it, something we can document for the 
layman customer base can grasp and begin to use.

So if Dave Crocker refuses to respond to my question, can anyone else 
show this "usefulness" value, how it is measured in their own 
implementation?  What extra technology are you using, if any, to get 
this usefulness?

---

From: Hector Santos <[email-masked]>
Date: Mon, 16 Aug 2010 16:35:54 -0400

>> rfc4781 Abstract - last sentence. Still abstract however this 
>> was a general lead-in discussion.
> 
> That's why the bis draft uses different language.  It's also why 
> wg docs written aftr 4871 have been searching for better language.

In the current bif draft, it has:

Abstract

    DomainKeys Identified Mail (DKIM) permits a person, role, or
    organization that owns the signing domain to claim some
    responsibility for a message by associating the domain with the
    message.  This can be an author's organization, an operational relay
    or one of their agents.  DKIM separates the question of the identity
    of the signer of the message from the purported author of the
    message.  Assertion of responsibility is validated through a
    cryptographic signature and querying the signer's domain directly to
    retrieve the appropriate public key.  Message transit from author to
    recipient is through relays that typically make no substantive change
    to the message content and thus preserve the DKIM signature.

I have trouble with the 3rd separation sentence and the potential 
ignorance it presents by breaking the original responsible party.

What is the actual question does it separate?

     An association between the purported author and the signer?
     Is an authorization question?
     Does it absolve the responsibility of the original domain signer?

I don't think the raw DKIM-base document should be making any 
conclusion about that it intends to separate or absolve by moving the 
responsibility to that of the signer.

I propose that a better wording be used or even removal of the 3rd 
(separation) sentence in entirety. I think the first two sentences are 
good enough. Its pretty straight forward - the signer is responsible.

By having it, it implies that those using the DKIM-BASE implementation 
can effectively 100% ignore the original responsible domain own 
signature without technical and even possibly legal repercussions.

If ASDP is going to happen or have any hope of happening, DKIM-BASE 
needs to have some semantics that this separation is not CUT and DRY.

I don't think a reference to POLICY needs to be made, but only focus 
on the idea that the LAST SIGNER is the responsible party.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Aug 2010 13:50:36 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Hector Santos
> Sent: Monday, August 16, 2010 1:36 PM
> To: [email-masked]
> Subject: [ietf-dkim] Issue 4871bis - DKIM Definition Separation of
> domains conflict
> 

The sentence is meant to make explicit the fact that the author of a message and the signer of a message are not necessarily the same thing.  So I guess then the first of your three examples is the right one.

> responsibility to that of the signer.

But the signer (d=) is the only provable entity on a signed message.  This was what was said in the update draft as well (RFC5671).

> signature without technical and even possibly legal repercussions.

I think the problem is that terms like "original responsible domain" are undefined given that there are no assurances of the validity of any other part of the message.  If you mean the From: field domain, that domain may or may not match "d=" even if there's a plurality of signatures.

> on the idea that the LAST SIGNER is the responsible party.

I don't think that's necessarily a correct assertion.  If a message has four valid signatures on it, then four parties have accepted some responsibility for the message.  The From: domain doesn't need to match the "d=" on any of them.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Aug 2010 17:07:50 -0700

> responsibility to that of the signer.

Per the Abstract:

"DKIM separates the question of the identity of the signer of the message from the purported author of the message."

The AUID and the purported Author indeed are different identities within 
DKIM.  However, any alleged separation is not absolute.  The optional 
Agent or User Identifier (AUID) shares a parent domain with that of the 
signer. When the AUID matches with the purported author, it indicates 
the signature is on behalf of the author identifier.  It still requires 
some Out-Of-Band signaling before any assumption of authentication or 
authorization is possible.  In the case of authorization by the Author 
Domain through OOB signaling, DKIM allows name-based Author Domain 
assertions about authentication and/or source identifiers.
> good enough. Its pretty straight forward - the signer is responsible.
Agreed.  The sentence is a bit overly broad.
> needs to have some semantics that this separation is not CUT and DRY.
Agreed.  But any conclusion drawn, especially from third-party 
signatures, needs to depend upon OOB signaling.
> on the idea that the LAST SIGNER is the responsible party.
What conclusions would you draw from the last signer, when there is also 
a valid Author Domain authorized third-party signature?  It seems wrong 
to suggest there would be great significance in the last signature added.

-Doug

---

From: Daniel Black <[email-masked]>
Date: Tue, 17 Aug 2010 09:39:50 +1000

On Tuesday 17 August 2010 01:18:52 Hector Santos wrote:
> Offline MUA access,

I was going on a desireable assumption that a verifier would add a 
Authenticated-Results header field and online/offline MUAs could depend on 
this if it falls within the right domain or its domain is accepted by a user.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 17 Aug 2010 03:06:17 -0000

>Authenticated-Results header field and online/offline MUAs could
>depend on this if it falls within the right domain or its domain is
>accepted by a user.

You are aware, I hope, that nothing in an Authenticated-Results header
has any relevance to the authenticity or lack thereof of anything in a
message's From: line?

Really, S/MIME does what you want.

R's,
John

---

From: Daniel Black <[email-masked]>
Date: Tue, 17 Aug 2010 09:38:52 +1000

> even if he is unfamiliar with the percent-hack.

I'm trying to get the same goal by recommending adding some non-artisicly 
specified form of a "list: mlm.example" display so its more evident to the 
user without percentage hacks. Current users are left out but a clearer 
interpration in the future is the tradeoff in values I'm making.

> mesages with a List-Id plus a valid signature from the MLM, even from a

good point. Should verifiers and MUAs do this check? I was hoping MUAs would 
only need to parse Authenticated-Results rather than full DKIM/ADSP so a MUA 
doing ADSP lookups would enter into an offline/online MUA discussions as 
Hector mentioned and talks about the validity period of a DNS records.

> they are going to do that sort of thing.

Good idea. I'll try to word that in for the next rewrite. Alternately a MUA 
maintains good/bad/indifferent third party signature lists and varies the 
display for this.

Thanks for the review Charles.

Daniel

---

From: John Levine <[email-masked]>
Date: 17 Aug 2010 19:14:30 -0000

>user without percentage hacks.

I must be missing something.  What does this have to do with DKIM?

If this were important, why don't MUAs look for the already standard
List-ID header, regardless of whether it's signed?  In my experience,
nearly all of the mail that makes it through existing spam filters and
has a List-ID header is really from a list.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Aug 2010 00:00:33 -0400

Patrick,

I appreciate your input and advice here.  I have not deviated from
most, if not all, of your key notes.  What I would trying to extract
from this, is how can DKIM-CORE be coupled with some other, preferably
standard or BCP to get some level of usefulness - something I can use
to explain to customer how it can serve them.

IOW, the implication is such that pure unrestricted DKIM-BASE signing
(by any MTA) has (or can provide) a useful (and non-damaging) purpose
and I wanted to know how that is accomplished without any other
integrated or interfacing design considerations, including MUA and
MLM, both of which we have expert level "skillset."

Anyway, you convinced me that we need to finally get DKIM implemented
abeit as you noted for associated risk reasons, very carefully and
conservatively. Murray's work to consolidate and address the long time
MLM concerns is a major help in my renewed DKIM interest.  He is
probably sore for an additional pat on his back. :)

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Aug 2010 00:31:45 -0400

Douglas Otis wrote:

>> I don't think a reference to POLICY needs to be made, but 
>> only focus on the idea that the LAST SIGNER is the 
>> responsible party.

> What conclusions would you draw from the last signer, when 
> there is also a valid Author Domain authorized third-party 
> signature?  It seems wrong to suggest there would be 
> great significance in the last signature added.

The last DKIM (re)signer message handler is the final arbiter of the 
next handler DKIM message verification result.  With 4871bis, it (last 
handler) has complete and as the 3rd sentence implies, unrestricted, 
control over the absolution of any previous single or collective 
domains responsibility.

Lets restate the 3rd sentence:

     DKIM separates the question of the identity of the signer
     of the message from the purported author of the
     message.

First of it, it DOES NOT separate any "question" because the 5322.From 
header is a required DKIM hash binding and hence it is always bound to 
any and all signatures.  As long as the 5322.From binding is a 
requirement, there is always an association with the signer and the 
original AUTHOR.

Second, I think we can all understand the historical perspective why 
the 3rd sentence exist, to break away from POLICY driven resigning 
restrictions.

This is an inherent subjective POLICY and I believe it needs to be 
noted the long required multi-protocol synergism necessary to engineer 
DKIM properly, not only for POLICY for Reputation based models, needs 
to be considered in 4871bis.

So if we don't want 4871bis to be specific, it needs to at least 
remove any semantics that suggest 4871bis has no signing restrictions.

The only way to truly "separate the question" of the signer and author 
domain, is to remove the DKIM requirement to include the 5322.From 
header in the bind.

---

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

> The sentence is meant to make explicit the fact that the author 
> of a message and the signer of a message are not necessarily the 
> same thing.  So I guess then the first of your three examples is 
> the right one.

Which implies the 2nd and 3rd?

But consider, if the 5322.From is a required DKIM signature binding 
requirement, including for all collective signatures, there will 
always an association that can not be removed.

So I can only see that this is an attempt to remove a possible 
recognized association, remove any signing restrictions by ignoring 
any possible unauthorized signing restriction and by absolving any 
previous single and/or collective signer responsibility.

> But the signer (d=) is the only provable entity on a signed 
> message.  This was what was said in the update draft as 
> well (RFC5671).

I don't follow. 5322.FROM is a required binding. While d= is the 
domain required for verify, the 5322.From is bound to it as a provable 
entity as well, i.e - you can't change it.

>> By having it, it implies that those using the DKIM-BASE
>> implementation can effectively 100% ignore the original 
>> responsible domain own signature without technical and even 
>> possibly legal repercussions.
> 
> I think the problem is that terms like "original responsible 
> domain" are undefined given that there are no assurances 
> of the validity of any other part of the message.  If you mean 
> the From: field domain, that domain may or may not match "d=" 
> even if there's a plurality of signatures.

Does "Previous Single or Collective Responsible signing domains" help 
better express the concern?

> I don't think that's necessarily a correct assertion.  If a 
> message has four valid signatures on it, then four parties 
> have accepted some responsibility for the message.  The From: 
> domain doesn't need to match the "d=" on any of them.

I can understand the historical perspective why the 3rd sentence is 
there as a statement to remove any non-authorized 3rd party signing by 
DKIM-CORE.

But please note this is not a ADSP policy concern, but also 
REPUTATION, including MLM issues since we are trying to give it a 
"DKIM Permission Slip" to not only absolve all previous single or 
collective responsible signing domains, but also break any bound 
"entity" used to couple policy and trust concepts from previous 
responsible resigner(s), and it can do so as a whole or selectively. 
It is the final arbiter.

So even with future unknown reputation ideas, or with MLM with its 
List-ID proposals, or anything else down the pike, the concern is that 
it equally applies and in even more possibly undesirable ways - 
because 4871bis says not about these "entities."

The 3rd sentence is an old idea that still based on the idea that 
POLICY would never emerge as a standard. It was a mentality that 
perpetuated the long time conflicts we had here.  I believe we need to 
be honest about these conflicts if we wish to get any workable widely 
endorsed usage of this stuff.  One doc that implies "ignore it" while 
we are still talking about DKIM Protective Wrapper technology, since 
to be counterproductive for a long time.

So I all am just suggestion that we take the opportunity now with 
4871bis to add compromising semantics that inform readers that SIGNING 
is not always desirable or the right thing to do and they should be 
aware of any current or future augmented DKIM related technology or 
functional specifications.

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Aug 2010 01:28:50 -0400

> depend on this if it falls within the right domain or its domain 
> is accepted by a user.

Right. it would be for offline devices. Online rendering can handle this.

I can see one offline MUA feature that could be part of the mail 
account settings:

     [_] Trust the A-R header for mail picked up from this domain.

Or it do it as a domain while list file listing managing by the user. 
It would be the opposite of the Fire Icon Thunderbird has to mark 
message as JUNK.    This "A-R" button would add the validated domain 
to the whitelist.

The main point Dave and Levin were making is that it wouldn't be 
possible to equally apply to all offline MUA, unless using the method 
I suggested of writing this trust information in the top of the body.

The 2nd main point is that the trust conclusion should not be 
automated without some form of user action, like with the per mail 
account checkbox setting to trust the A-R header for this mail pickup 
site.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 18 Aug 2010 10:55:59 +0100

>    From: John Doe <[email-masked]>

And likewise with
      From: Ebay Customer Services <[email-masked]>

With "helpful" MUAs that do such stupid things, we hardly need DKIM at all  
:-( .

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 18 Aug 2010 16:21:08 +0100

--On 17 August 2010 19:14:30 +0000 John Levine <[email-masked]> wrote:

>> I'm trying to get the same goal by recommending adding some
>> non-artisicly  specified form of a "list: mlm.example" display so its
>> more evident to the  user without percentage hacks.
>

Yes, I think that's my experience too: nearly all. Unfortunately, I had to 
disable a filter which would file an email in lists/listname and 
automatically create the mailbox if necessary. I ended up with more 
mailboxes created by spam than by genuine list emails.

So, while most messages with a list-id header were genuine, most distinct 
list-ids that I saw were not.

I guess it would be nice if list servers could use OAuth to authenticate my 
subscription requests against my mail infrastructure, and then my servers 
would recognise and record the request. Then it could treat messages from 
the list with a higher trust level, and -for example- file them accordingly.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Aug 2010 16:29:11 -0400

> the list with a higher trust level, and -for example- file them accordingly.

Interesting.

Would this be similar or nearly have the same functionally by using an 
alias email address? for example:

     [email-masked]

Once you have that targeted address, you can apply all sorts of rules 
at your receiver.

But I can see your derivative of your idea work as a way to automate 
the process.

Use a redirection method by wrapping all the subscription parameters 
(for any list system) and send it to a (web) service on your system 
which activates a backend process to add the "list" info or new alias 
into your system records and finishes with the actual subscription 
email request.