Subject: [ietf-dkim] Weird i= in client mail

From: Laura Atkins <[email-masked]>
Date: Mon, 17 Jun 2013 14:36:38 -0700

I am in the process of reviewing the technical setup of a client installation. This client is using the VERP string (Return Path / Envelope From) in the i= of their DKIM signature.

The signature looks like this:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=ci; d=inbox.example.com;
	i=verpprefix-laura=2dinterdirect=[email-masked];
	h=content-type:mime-version:subject:list-unsubscribe:reply-to:to:from:date:message-id;
	bh=HbLebYQFYQmYej07DLVID9lCjc8=;

Based on my understanding of DKIM, this isn't necessarily violating the DKIM spec, but it does seem to be not the right thing to use for the i= value

I'm thinking my client should stop doing this, just because it really seems wrong but I have no justification for recommending that other than "that can't be right." 

I haven't been able to find anything that discusses the intention behind the i=. I expect they chose this i= because that's the envelope from, but the i= is suppose to be a person, not a mechanical address, correct?

I'd appreciate any guidance on where to go to research this. Or if anyone can give me some help in understanding this enough to tell my client to stop. 

laura 

-- 
Laura Atkins
Word to the Wise			"The Deliverability Experts!"
Direct: 650 678-3454		Fax: 650 249-1909
AIM: wttwlaura			YIM: wttw_laura
Delivery blog: <http://blog.wordtothewise.com/>

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Jun 2013 15:29:50 -0700

On 6/17/2013 2:36 PM, Laura Atkins wrote:
> I am in the process of reviewing the technical setup of a client
> installation. This client is using the VERP string (Return Path /
> Envelope From) in the i= of their DKIM signature.
>
> Based on my understanding of DKIM, this isn't necessarily violating
> the DKIM spec, but it does seem to be not the right thing to use for
> the i= value

My understanding of i= semantics is that it has no formal meaning except 
to its creator.[1]  As long as the syntactic form is followed, it is 
acceptable for it to contain anything.[2]

At which point I'd expect the constraints to be privacy and utility, 
according to whatever criteria the creator wishes to invoke.

> I'm thinking my client should stop doing this, just because it really
> seems wrong but I have no justification for recommending that other
> than "that can't be right."
>
> I haven't been able to find anything that discusses the intention
> behind the i=. I expect they chose this i= because that's the
> envelope from, but the i= is suppose to be a person, not a mechanical
> address, correct?

Different people had different intentions for i=, over the course of i= 
development.  Basically, the original spec promoted some confusion on 
its role and the role of d=.  We followed up with an effort to 
explicitly resolve this.  The above statement summarizes my 
understanding of the result, for i=.

d/

[1]  That is, pretty much the i= value is only useful for returning to 
the creator.  One can imagine utility when a receiver is interacting 
with the originator in problem handling, for example.

[2]  And, of course, there's the constraint: "The domain part of the 
address MUST be the same as, or a subdomain of, the value of the "d=" 
tag."  But I'd consider that a minor point, for the kind of question 
being asked here.

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

---

From: Laura Atkins <[email-masked]>
Date: Mon, 17 Jun 2013 15:48:37 -0700

On Jun 17, 2013, at 3:29 PM, Dave Crocker wrote:

> My understanding of i= semantics is that it has no formal meaning except to its creator.[1]  As long as the syntactic form is followed, it is acceptable for it to contain anything.[2]
> 
> At which point I'd expect the constraints to be privacy and utility, according to whatever criteria the creator wishes to invoke.

Thanks. That does help. 

> Different people had different intentions for i=, over the course of i= development.  Basically, the original spec promoted some confusion on its role and the role of d=.  We followed up with an effort to explicitly resolve this.  The above statement summarizes my understanding of the result, for i=.

Again, thank you.

I've asked the client why they chose that, we'll see what they day. 

laura

---

From: "John Levine" <[email-masked]>
Date: 17 Jun 2013 23:06:32 -0000

My understanding matches Dave's.  The i= value is an opaque token
which for purely historical reasons has to look like an address in a
subdomain of the d= domain.

>I've asked the client why they chose that, we'll see what they day. 

"Huh, that's what the code does.  Should it do something else?"

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 17 Jun 2013 23:09:51 -0000

>I haven't been able to find anything that discusses the intention behind the i=. I expect
>they chose this i= because that's the envelope from, but the i= is suppose to be a person,
>not a mechanical address, correct?

Historical bit: it is my impression that i= was invented by people who
were used to corporate mail systems where user identities are tightly
controlled and all the mail can be traced back to an individual user,
so the i= was that user's mail address.

Needless to say, in the wider world, there are a lot of mail systems
that don't work that way.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Tue, 18 Jun 2013 03:14:03 +0000

> so the i= was that user's mail address.
At one stage i= was thought to represent different mail streams with different reputation, however this did not get any traction...
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John Levine" <[email-masked]>
Date: 18 Jun 2013 03:58:23 -0000

>however this did not get any traction...

As far as I can recall, I don't think anyone but you had that theory.
If you want two streams, you use two d= domains.

On my system the i= tells how the mail was injected (submit, webmail,
whatever) and who the user was if it knows.  It's fairly obvious if
you look at it, but it's not really of any use to anyone but me for
tracking down the occasional odd user behavior.

---

From: Franck Martin <[email-masked]>
Date: Tue, 18 Jun 2013 04:20:54 +0000

> If you want two streams, you use two d= domains.

...the world according to John :P

The question was raised and dispelled on http://blog.wordtothewise.com/2007/10/dkim-i-equal-vs-d-equal/, proving the idea was in the air, and I read it in some deliverability documents in the early days (tho wrong too)...

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Jun 2013 21:43:10 -0700

>>> however this did not get any traction...
...
> The question was raised and dispelled on http://blog.wordtothewise.com/2007/10/dkim-i-equal-vs-d-equal/, proving the idea was in the air, and I read it in some deliverability documents in the early…

As I said, there were a variety of intentions, descriptions, desires and 
claims for i=.  Different people had different views.  None of the 
alternatives was in the spec and therefore none were standardized.

d/

---

From: Tony Hansen <[email-masked]>
Date: Tue, 18 Jun 2013 10:18:35 -0400

> alternatives was in the spec and therefore none were standardized.

Yes, it was an unfortunate turn of events that wasn't discovered until
it was rather late in the game, so we wound up punting on the issue of
what should be in the i= value and essentially said that it was an
opaque value that was site dependent.

I always thought it would be a nice follow-on to DKIM to provide a way
for a site to specify how that site was using i=; that is, to provide
some clarity and comprehension for that value. For example, our
implementation placed the authenticated userid into i=. I know of one
site that appears to use a hash of the authenticated userid. John L says
his site uses "how the mail was injected (submit, webmail, whatever) and
who the user was if it knows". When there is a deterministic mechanism
used to create i=, and the mechanism is known, then it is possible for
additional logic to be added to the receiving side as well.

    Tony Hansen

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jun 2013 07:59:35 -0700

> additional logic to be added to the receiving side as well.

I'm sure Tony already knows this, but just to make sure it's part of the 
thread:

      Anyone can define a value-added protocol layer on top of DKIM.  It 
can define all sorts of additional semantics.

      It needs a method of declaring its presence, such as an extra 
header field or a special external query, but after that, it's free to 
define anything it wants, including a public meaning for i=

One could, for example, imagine a layer that asserts that the domain in 
the rfc5322.From field MUST match the domain in the DKIM d= field, or at 
least have an "organizational domain" match (that is, match at the name 
portion that was delegated by a registry.

Oh, wait.  That's DMARC.

See?  It's possible.

d/

---

From: Franck Martin <[email-masked]>
Date: Tue, 18 Jun 2013 15:55:38 +0000

> portion that was delegated by a registry.
I found that too: http://tools.ietf.org/html/draft-fenton-dkim-reputation-hint-00

No traction either...

I think, the lesson here is to not mix function in protocols. The authentication piece should be separated from the policy piece and same for the reputation. This makes better building blocks.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 18 Jun 2013 08:42:42 -0700

On 06/18/2013 07:18 AM, Tony Hansen wrote:
>>> On Jun 17, 2013, at 8:58 PM, John Levine<[email-masked]>  wrote:
>>> The question was raised and dispelled onhttp://blog.wordtothewise.com/2007/10/dkim-i-equal-vs-d-equal/, proving the idea was in the air, and I read it in some deliverability documents in the early days (tho wrong too)...
> Yes, it was an unfortunate turn of events that wasn't discovered until it was rather late in the game, so we wound up punting on the issue of what should be in the i= value and essentially said that it was an opaque value that was site dependent.

It was known really early on, it's just that some people wanted to wait 8 years to
do the work.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 Jun 2013 15:32:56 -0700

> > additional logic to be added to the receiving side as well.

It would also have to be something trustable.  Otherwise, why should you
believe the party making such a statement?  A bad guy will put any value
there that increases the likelihood of making it to the inbox, whether it's
true or not.

> define anything it wants, including a public meaning for i=

ATPS did exactly this.  It may be a poor example in that it has seen
approximately zero uptake due to lack of demand, but it does demonstrate
the mechanism Dave's describing here.

-MSK

---

From: Tony Hansen <[email-masked]>
Date: Tue, 18 Jun 2013 22:33:42 -0400

On 6/18/2013 6:32 PM, Murray S. Kucherawy wrote:
> On Tue, Jun 18, 2013 at 7:59 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> It would also have to be something trustable.  Otherwise, why should
> you believe the party making such a statement?  A bad guy will put any
> value there that increases the likelihood of making it to the inbox,
> whether it's true or not.

Absolutely. This really has nothing to do with increasing or decreasing
the likelihood of a message making it to the mailbox. It has to do with
being able to make additional positive value judgements about messages
that *have* made it to your inbox. People keep incorrectly conflating
the making of positive statements about a message with trying to keep
messages from the inbox; such thinking is what leads to such erroneous
documents as "dkim-is-harmful".

DKIM shines with telling you positive verifiable statements about an
email message and its attributes. It's the messages that pass those
positive verifications that I'm interested in for such additional tests.

Consider combining the reputation of the domain with the verification of
the sending domain with the verification of the authenticated user who
sent the message. I feel that a message passing those tests can lead to
a *stronger* positive statement about the message than one not having
any information about the authenticated user. If the sending mailhost is
one that has a good reputation, and the sending mailhost chose to use i=
in a way that allowed me to make additional checks about the user, I
think I would be better off.

> approximately zero uptake due to lack of demand, but it does
> demonstrate the mechanism Dave's describing here.

Both ADSP (not ATPS) and DMARC define a value-added protocol layer on
top of DKIM, and are attacking complementary issues. I won't got into
reasons I think ADSP has gotten no traction.

    Tony Hansen

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Jun 2013 22:41:30 -0700

On Jun 18, 2013, at 7:33 PM, Tony Hansen <[email-masked]> wrote:
> 
> Absolutely. This really has nothing to do with increasing or decreasing the likelihood of a message making it to the mailbox. It has to do with being able to make additional positive value judgements about messages that *have* made it to your inbox. People keep incorrectly conflating the making of positive statements about a message with trying to keep messages from the inbox; such thinking is what leads to such erroneous documents as "dkim-is-harmful".
> 
> DKIM shines with telling you positive verifiable statements about an email message and its attributes. It's the messages that pass those positive verifications that I'm interested in for such additional tests.

Dear Tony,

What do you find to be in error in draft-otis-dkim-harmful?  The latest version attempts to more clearly explain this concern.

Trust in a DKIM signature is being used as a basis for acceptance as described in section 5.4 in [RFC5863].  Since neither SMTP nor DKIM check for invalid prefixed header fields, TBTB domains  offer a simple means for malefactors to have their deceptive messages delivered to their victim's inbox.  This problem is real.

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jun 2013 11:07:49 -0700

On Jun 18, 2013, at 3:32 PM, Murray S. Kucherawy <[email-masked]> wrote:
> ATPS did exactly this.  It may be a poor example in that it has seen approximately zero uptake due to lack of demand, but it does demonstrate the mechanism Dave's describing here.

Dear Murray,

As people contend with unintended issues caused by DMARC, such as dealing with mailing lists, then ATPS may get a second look.  ATPS will not have uptake with the requirement for a different kind of DKIM signature.  DMARC could override this with a policy assertion that ATPS is used with normal DKIM signatures by the domain. 

Regards,
Douglas Otis

---

From: Jon Callas <[email-masked]>
Date: Wed, 19 Jun 2013 11:40:22 -0700

I want to add in a bit here as well.

In doing the crypto/security parts of DKIM, we had two goals in tension with each other. One was to provide accountability for a message for all the obvious good reasons.

But in the other direction, we didn't want DKIM to accidentally turn email into an always-on-the-record tracking system with severe negative privacy consequences.

We wanted to maximize the effectiveness of authentication while minimizing the tracking and privacy-loss aspects of authentication.

(Side notes -- by "we," I mean me, but I know that I wasn't alone. Also, we know full well that unencrypted email has horrible privacy characteristics all on its own.)

That's why, for example, there's an emphasis on DKIM being about the intentionally vague term "administrative domain."

Now on the other hand, if an administrative domain wanted to go to the trouble to authenticate down to the user level, we didn't want to prevent that, either. The primary audience for DKIM includes regulated industries, after all.

I also add that some of the working group *wanted* to push i= into mandatory user-level accountability, as well. Some wanted user-level as a MUST, and the result was it being a MAY.

That means that we tried to:

* Maximize the domain-level accountability.
* Minimize the user-level metadata and privacy damage
* Permit user-level accountability for domains that want to add it on.

And this is a good deal of why i= is the weird beast that it is.

	Jon

---

From: "John R. Levine" <[email-masked]>
Date: 19 Jun 2013 21:05:43 -0400

> Now on the other hand, if an administrative domain wanted to go to the trouble to authenticate down to the user level, we didn't want to prevent that, either. The primary audience for DKIM includes…

Seems to me that works fine as is.  If a stock broker wants to set up its 
mail system to put an i= into DKIM that reliably identifies the person who 
sent the mail, they can do that.

But unless I have external knowledge that they do that, and trust them to 
do it right, I can't depend on it, so it's mostly an opaque token of use 
to the sender when someone sends back a message and says "what the heck is 
going on here?"

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 20 Jun 2013 10:03:48 +0200

On 06/20/2013 03:05 AM, John R. Levine wrote:
> do it right, I can't depend on it,

Why do you raise this concern for "i=" and not for "d="? Simply looking 
at "d=" we can't differentiate between a Good Guy and a Bad Guy, until 
we have built some history/reputation for that particular "d=" domain. 
Why wouldn't the same logic hold for "i="?

That is: if a Signer, despite the wording of RFC6376 par 3.5 on "i=", 
chooses to use a non-default "i=" then the Verifier may assume the 
Signer is intentionally signing with "i=" and the Verifier is allowed to 
use the information of "i=" for whatever purpose it is verifying the 
signature (e.g. building a reputation profile of that "d=,i=" combination.

If we wanted the Verifier to never ever use the "i=" information, we 
should have written this as a 'MUST NOT' in RFC6376 (and not only in an 
informational section).

/rolf

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 20 Jun 2013 13:16:00 +0200

On 06/20/2013 12:59 PM, Wietse Venema wrote:
> Rolf E. Sonneveld:
> Because d= specifies the name of the public key.

As there is only one private key associated with that public key, we may 
safely assume that the owner of that private key takes responsibility 
for any use of the "i=" within that "d=" domain.

/rolf

---

From: [email-masked] (Wietse Venema)
Date: Thu, 20 Jun 2013 06:59:25 -0400 (EDT)

Wietse

---

From: [email-masked] (Wietse Venema)
Date: Thu, 20 Jun 2013 11:36:51 -0400 (EDT)

On 06/20/2013 03:05 AM, John R. Levine wrote:
> Seems to me that works fine as is.  If a stock broker wants to set
> up its mail system to put an i= into DKIM that reliably identifies
> the person who sent the mail, they can do that.
>
> But unless I have external knowledge that they do that, and trust
> them to do it right, I can't depend on it,

Rolf E. Sonneveld:
> Why do you raise this concern for "i=" and not for "d="? Simply
> looking at "d=" we can't differentiate between a Good Guy and a
> Bad Guy, until we have built some history/reputation for that
> particular "d=" domain.  Why wouldn't the same logic hold for "i="?

Rolf E. Sonneveld:
> As there is only one private key associated with that public key,
> we may safely assume that the owner of that private key takes
> responsibility for any use of the "i=" within that "d=" domain.

Or any other bits in the message header or body, for that matter.
The point is that d= provides the authenticated channel between
signer and verifier, while all the other bits are just riding along
through that authenticated channel.

This thread is really about different degrees of trust: trust in
the authenticated channel, versus trust in the content that arrives
through that channel. I may be willing to believe that the channel
is authentic, while at the same time being sceptical about any
claims that are made by its payload.

	Wietse

---

From: Jon Callas <[email-masked]>
Date: Thu, 20 Jun 2013 10:00:19 -0700

On Jun 19, 2013, at 6:05 PM, John R. Levine <[email-masked]> wrote:

> Seems to me that works fine as is.  If a stock broker wants to set up its mail system to put an i= into DKIM that reliably identifies the person who sent the mail, they can do that.
> 
> But unless I have external knowledge that they do that, and trust them to do it right, I can't depend on it, so it's mostly an opaque token of use to the sender when someone sends back a message and says "what the heck is going on here?"

Exactly.

This is why it's "weird." I= is there so upper-layer systems like DMARC, a reputation system, or an administrative domain's internal software can work at a finer grain than the domain itself.

It has many potential uses, but within DKIM itself, it's an expansion socket.

	Jon

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 20 Jun 2013 19:03:45 +0200

> claims that are made by its payload.

Agreed.

/rolf

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Jun 2013 10:11:34 -0700

> It has many potential uses, but within DKIM itself, it's an expansion socket.

I tend to characterize it as an opaque cookie.

d/

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2013 18:28:01 -0000

>> It has many potential uses, but within DKIM itself, it's an expansion socket.

Keep in mind that there are IANA registries for the tag names in both
the signatures and the key records.  If you want to try something new,
just pick a tag name or two and have at it.  RFCs 6541 and 6651 have
recently added signature tags.

I would think that i= would be a poor tag to use since a lot of people
already have opinions about what it means or doesn't mean.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Jun 2013 16:03:43 -0700

> already have opinions about what it means or doesn't mean.

Dear John and Jon,

Jon and John are right, in that web providers often track users using synthetic subdomains or some type of cookie (which may offends users), and that the 'i=' tag has already been defined and constrained by things like ADSP.  There is extensive revenue generated aggregating and trading in the correlation of user information after all.  There is also a basic reality large providers are not likely to review logs based on timestamps to determine which of their users caused a particular complaint.  Overcoming that reluctance was the motivation in creating either a static or transitive opaque originator tag contained within the DKIM signature as expressed in an I-D created back in 2005 that listed various option concepts.
http://tools.ietf.org/html/draft-otis-dkim-options-00

There are currently ongoing problems caused by compromised email accounts.  Some of the other concepts may offer ideas for various remedies when needs arise. While the i= parameter has morphed to partially provide this role, it also conflicts with intended uses defined by RFC5617 (ADSP).  Too bad.  The idea of the signing domain offering an evolving opaque identifier designated specifically for this purpose has merit.  Perhaps it could use a newly defined 'o=' tag.  Unfortunately, this may offend those who want to feel their emails are anonymous and yet signed using DKIM. 

The best that can be hoped would be to officially deprecate ADSP as it is being supplanted by DMARC with a lower failure rate, and then offer a BCP for use of 'i='.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Fri, 21 Jun 2013 13:21:03 -0400

There are a number of domains supporting ADSP, ATPS and ASL records. 
There is a healthy set of world-wide usage at our ADSP Wizard [1].

The problem is I doubt anyone is "ACTING" on any strong policy rule. 
That was one of the chief complaint among the policy advocates (vendors) 
with the first separation, then deemphasis and WG work product 
abandonment of the singular policy (SSP/ADSP proposals) layer for DKIM.

Unfortunately, until DMARC can be trusted to work with a strong handler 
expectation, it will continue to have no payoff, high processing 
overhead and it will be slow to be adopted with the true source of what 
makes a standard - everyone from small to large using it, not just a 
relatively handful of *currently* larger businesses who for the most 
part are just now using something for marketing purposes.  We spent tons 
of man-years dollars on DKIM and POLICY.  I'm going to be a little more 
careful and slower, possible never, before getting into DMARC.

I personally do not care for the reporting aspects, that's not the 
business I believe we need to build.  The business is addressing the 
protection of mail, with automated deterministic "mail policy fault" 
filtering.   That is what I outlined in the 2006 DSAP proposal [2] which 
for the most part dealt with the idea of filtering the most obvious 
faults of the transport mail at the system level and then use at an 
additional operational secondary layer a reputation filter which 
currently is a "Battery Required" concept - it doesn't exist 
persistently nor consistently.  An Author Domain Policy layer is the 
only anchor we can use for a persistent and consistent mode of 
expectation, design and operation.

[1] http://www.winserver.com/public/wcadsp
[2] http://tools.ietf.org/html/draft-santos-dkim-dsap-00

---

From: Michael Deutschmann <[email-masked]>
Date: Sat, 22 Jun 2013 21:49:23 -0700 (PDT)

On Tue, 18 Jun 2013, Douglas Otis wrote:
> Trust in a DKIM signature is being used as a basis for acceptance as
> described in section 5.4 in [RFC5863].  Since neither SMTP nor DKIM check
> for invalid prefixed header fields, TBTB domains offer a simple means for
> malefactors to have their deceptive messages delivered to their victim's
> inbox.  This problem is real.

Ukh.  This again.

I think I see what the problem is with the DKIM design community.

Most of you assume that once DKIM and an accessory protocol of choice
(DMARC, etc.) reaches a sufficient amount of respect from the RFC
machinery, it will magically be deployed absolutely everywhere it is
relevant.

Otis is just a shade more humble.  He thinks the magical deployment will
occur, but will be accomplished by a jerk literal genie, who will try to
pass as much bad mail as possible while keeping to the letter of the
final DKIM spec.

In reality, the recipient end DKIM deployment will be driven by
sysadmins representing end-users who want less bad mail to reach them.
Unlike the participating senders, they are not afraid of a phish or
virus mail succeeding --- they merely do not want to be disturbed unless
the mail is actually relevant.

(So if Otis' attack actually gets used, it will be in the selfish
interest of those domains to filter it, there being no legitimate use for
double From:s.  SpamAssassin would likely pick it up, resulting in sites
that block the attack mails while not even using DKIM.)

The accessory protocols I've seen are unusable senderside even by my
vanity domain, let alone casual users, because of the mailing list
problem.

Those who believe in magic deny this is a concern, because despite the
fact that we represent the vast majority of senders, we aren't "phish
targets".  But if extra context is only provided for the tiny fraction of
mails purportedly from "phish targets", then DKIM isn't worth my while to
deploy receiverside.

(I have deployed DKIM alone senderside, but that's just to keep in
practice in case someone invents an accessory protocol that's actually
sane.  Allowing me to declare that all mail bearing my RFC821 MAIL FROM:
without a corresponding signature is bogus while saying nothing about
that which merely bears my RFC822 From: would be a good start.)

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 23 Jun 2013 01:06:07 -0700

> that which merely bears my RFC822 From: would be a good start.)
If that's the magic you seek, I propose writing it up as an I-D and doing
some practical interoperability experiments, and see if it takes off.

It's easy to lob "you should've done it this way" grenades without actually
putting any energy behind it other than a critical missive here and there.

-MSK

---

From: Franck Martin <[email-masked]>
Date: Sun, 23 Jun 2013 11:28:13 +0000

+1

Michael, if you don't want to deploy, that's your prerogative, but don't claim supposed problems are blockers when you don't have any experience of such deployment...

On Jun 23, 2013, at 1:06 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Jun 22, 2013 at 9:49 PM, Michael Deutschmann <[email-masked]<mailto:[email-masked]>> wrote:

If that's the magic you seek, I propose writing it up as an I-D and doing some practical interoperability experiments, and see if it takes off.

It's easy to lob "you should've done it this way" grenades without actually putting any energy behind it other than a critical missive here and there.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Sun, 23 Jun 2013 11:58:42 -0400

Oh, I didn't know there was a requirement for one to have IMPLEMENTED 
and DEPLOYED proposed protocols before one can have any sort of 
engineering insight into problems and their resolutions?  I'm sure that 
is not what you mean.

Sure, it helps, but keep in mind DKIM itself was engineered with little 
to no DEPLOYMENT experiences by the very authors themselves for a very 
long time.  Many folks here were in the same position, including us 
(Santronics Software) only finally implemented and deployed when there 
was a sign of a payoff with an Author Domain protocol work product in 
the WG.  Nonetheless, not having deployment experiences should not mean 
we don't know what we are talking about and I surely hope that doesn't 
become the next mantra to participate in the IETF WG process.

And consider also, that many of the current problems with DKIM and the 
lack of a payoff were 100% predictable and foretold by many here, 
including myself, including Mr. Otis.  Recall the "battery required" 
talk?  While there as direct experience for me with the early Visanet 
market, this was discussed even during MARID. It was well foreseen as 
the wrong path for DKIM to use without an AUTHOR DOMAIN layer to it.  It 
was a early rejected proposal to use a Reputation (GOOD) layer. Remember 
CSV/DNA?   Its no surprise that DMARC is now following author domain 
concepts offered by SSP, DSAP and ADSP.

Remember, DKIM had SSP built-in. It was removed. IMV, that was when all 
the second guessing began with DKIM and in my view, it was clearly the 
wrong thing to do when SPF was still coming on with strong definitive 
handling (rejection) semantics which DKIM failed to establish. 
Practically everyone was looking for a strong rejection based protocol 
for mail.

Remember that DKIM's original charter stated Mailing List was to be 
looked at as an after-thought to the main consideration with policy. 
Mailing list WAS NOT the prime consideration - it was written in the 
charter as a secondary consideration.   The problem is that we had to 
now cater to the 3rd party channels.  A valid concern but one well known 
to be fraught with major issues with middle-ware design concepts.  But 
we allowed this side of the design community and market to trump all 
others higher value private transaction concerns. It was "too small" to 
consider.   That was a mistake. And remember, there were proposals, 
ideas to allow the middle ware to work, but then we had to forget about 
author domain policies to allow for a futuristic "battery requires" 3rd 
party reputation/trust resigner market to work.
DKIM Deployment's guide conflicts on this very concept - support ADSP, 
yet allow for middle ware to ignore ADSP. Nuts! Guarantee Author Domain 
Protocol killer if you can't get the middle-ware folks to support 
honoring Author Domain policies - all known long ago without or little 
deployment. I was proposing in DSAP that both can co-exist.  But no, the 
reputation folks did not want Author Domain policies to dictate over 
middle-ware signatures.  That little last minute was stipulated in the 
SSP Functional Specs RFC and it KILLED IT!!  Why bother now.

So it is what it is today; a very little to zero DKIM payoff.  Systems 
signing with some marketing value, and perhaps processing/verifying but 
there is no expectation that it has any handling value.  DKIM is 
currently a big waste of processing time. Super high waste and the 
bigger you are, the more waste you have and more you absorb as well.

Will DMARC change that?  Only if you get the small folks - the MAJORITY 
of the network, involved.  That is why SPF took off - it was the entire 
industry that jumped on board to support a REJECTION based protocol that 
was so drastically needed at the time. For DKIM, it really came a day 
late and a dollar short and when SSP was removed, well, it only made SPF 
that more stronger.

The IRONY in the DKIM story is that the same folks that didn't like SPF, 
came to realize that it needed SPF to help DKIM.  Now you have the same 
group of authors doing all three.  That could be good but they really do 
need to begin listening (and reading the mail) of the Author Domain 
advocates. So much time wasted.

To me, it may be too late.  The only way to jump start all this again is 
to come up with real strong technical sales/advertising/discussions for 
the support of real Domain Handling policies - that is when the 
WORTH/PAYOFF factor and new processing ideas will come.  In the mean 
time, it (DMARC) is just more waste with yet another TXT-based record 
lookup!

SMTP
   SPF EHLO/HELO optional
   SPF MAIL FROM
SMTP DATA/PAYLOAD
   DKIM
   ADSP
   VBR

and now we add DMARC?

   DMARC

That is basically what? 5-8 TXT Lookups?  Ridiculous!

Perhaps the group of folks putting all these things together should have 
a IETF lunch meeting and start thinking about better consolidating all 
this TXT-based worthless lookup into some single cohesive author domain 
with 3rd party/mail list support solution.

Just look at the TXT vs unique/new RR type debates. Another TXT-based in 
DMARC will not well.  Too much.  We need a single author domain protocol 
consolidation that is extendible, flexible to support a wide range of 
ADMD declarations. It will support SPF, VBR and DKIM domain policy 
layered protection ideas.

I think Murry can write it and get wide support (wide to me is small to 
large, no exceptions) if done correctly.

--
HLS

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jun 2013 13:19:35 -0400

> the mail is actually relevant.

My, aren't we cynical.  You must know very different system managers than 
the ones I talk to at MAAWG and other places.  I wouldn't say they're 
afraid of viruses and phishes, but they certainly want to keep them out of 
recipient mailboxes.

I also second Murray's suggestion that if you think you can design 
something better, please do so and write it up.  But first you might want 
to look at some of the signed bounce address proposals like this one, and 
consider why nobody adopted them.

http://web.archive.org/web/20060909034948/ses.codeshare.ca/files/Working_SES_Format_Definition_16.html

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Jun 2013 13:21:40 -0700

> pass as much bad mail as possible while keeping to the letter of the

Dear Michael,

A serious security vulnerability occurs when system administrators logically follow DKIM deployment instructions.  They likely have a reasonable desire to avoid complains caused by reactive Bayesian filters.  This filtering is supplanted by more deterministic message acceptance based on trust established by a DKIM signing domain specifically as suggested by the deployment specifications.

Rather than DKIM admitting a process error where valid signatures are returned for messages having invalidly prefixed header fields, the fix was to suggest there is some undefined check left to some undefined subsequent agent.  So much for providing clean protocol layering.   Use of DKIM requires an undefined "degrading" process per section 8.15 to be implemented subsequent to signature validation.  

This is putting the cart before the horse since a DKIM validation process must walk up and down the entire header field stack.  It is also clear very few domains implement the non-intuitive double listing of singleton header fields.  Even so called "high value" domains don't bother with this ugly hack.  The OpenDKIM implementation can place the cart behind the horse, but as a seldom used option.  An option that should be a REQUIREMENT. 
    
RFC5863:
,---
5.4.  Inbound Mail Filtering
  DKIM is frequently employed in a mail filtering strategy to avoid
   performing content analysis on email originating from trusted
   sources.  Messages that carry a valid DKIM signature from a trusted
   source can be whitelisted, avoiding the need to perform computation
   and hence energy-intensive content analysis to determine the
   disposition of the message.

   Mail sources can be determined to be trusted by means of previously
   observed behavior and/or reference to external reputation or
   accreditation services.  The precise means by which this is
   accomplished is outside the scope of DKIM.
'---
,---
8.4.  Email Infrastructure Agents
...
Inbound:   When an organization deploys DKIM, it needs to make
         sure that its email infrastructure components that do not have
         primary roles in DKIM handling do not modify message in ways
         that prevent subsequent verification.

         An inbound MTA or an MDA can incorporate an indication of the
         verification results into the message, such as using an
         Authentication-Results header field [RFC5451].
...
'---
,---
8.5.  Mail User Agent
...
Inbound: An MUA can rely on a report of a DKIM signature
         verification that took place at some point in the inbound MTA/
         MDA path (e.g., an Authentication-Results header field), or an
         MUA can perform DKIM signature verification directly.  A
         verifying MUA needs to allow for the case where mail has been
         modified in the inbound MTA path; if a signature fails, the
         message is to be treated the same as a message that does not
         have a signature.
...
'---

[RFC6376]:
,---
3.8.  Input Requirements
...

   Accordingly, DKIM's design is predicated on valid input.  Therefore,
   Signers and Verifiers SHOULD take reasonable steps to ensure that the
   messages they are processing are valid according to [RFC5322],
   [RFC2045], and any other relevant message format standards.
  See Section 8.15 for additional discussion.
'---

Regards,
Douglas Otis

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 30 Jun 2013 06:21:29 -0700 (PDT)

On 23 Jun 2013, John R. Levine wrote:
> But first you might want to look at some of the signed bounce address
> proposals like this one, and consider why nobody adopted them.
> [Link to SES]

What I'm asking for is nothing like SES.  I want the signature to be
based on the envelope MAIL FROM:, but it is still the body that gets
signed.  No VERPing is called for.

My protocol would have almost the same mailserver behavior as ADSP,
except that where ADSP only pays attention to signatures where "d="
matches the right hand side of the RFC822 From:, my "EDSP" would only pay
attention to signatures where the "d=" matches the right hand side of the
RFC821 MAIL FROM:.

This means that someone can publish the strictest possible EDSP
without causing mailing list false positives.  Mailing lists take
ownership of the MAIL FROM:, hence only an EDSP set by the list itself
will apply, and the original poster's EDSP will be correctly ignored.
Just like in SPF.

Of course, since the MAIL FROM: is usually not visible without pressing a
"show all headers" button, this would be more about leaving a clearer
audit trail than actually foiling phishes.

---

From: "John R. Levine" <[email-masked]>
Date: 30 Jun 2013 12:21:02 -0400

> signed.  No VERPing is called for. ...

Where can we read the draft?

Regards,