Re: [ietf-dkim] Weird i= in client mail
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 On 6/20/2013 7:03 PM, Douglas Otis wrote: On Jun 20, 2013, at 11:28 AM, John Levine jo...@taugh.com wrote: 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
On 06/20/2013 03:05 AM, John R. Levine wrote: 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. 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, 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
On 06/20/2013 12:59 PM, Wietse Venema wrote: Rolf E. Sonneveld: On 06/20/2013 03:05 AM, John R. Levine wrote: 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. 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, 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=? 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
Rolf E. Sonneveld: On 06/20/2013 03:05 AM, John R. Levine wrote: 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. 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, 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=? Because d= specifies the name of the public key. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
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=? Wietse: Because d= specifies the name of the public key. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
On Jun 19, 2013, at 6:05 PM, John R. Levine jo...@iecc.com wrote: 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
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=? Wietse: Because d= specifies the name of the public key. 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. Wietse: 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. Agreed. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
On 6/20/2013 10:00 AM, Jon Callas wrote: It has many potential uses, but within DKIM itself, it's an expansion socket. I tend to characterize it as an opaque cookie. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
On Jun 20, 2013, at 11:28 AM, John Levine jo...@taugh.com wrote: 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
On 06/18/2013 07:18 AM, Tony Hansen wrote: On 6/18/2013 12:43 AM, Dave Crocker wrote: On 6/17/2013 9:20 PM, Franck Martin wrote: On Jun 17, 2013, at 8:58 PM, John Levinejo...@taugh.com wrote: At one stage i= was thought to represent different mail streams with different reputation, however this did not get any traction... ... 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)... 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Weird i= in client mail
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=40wordtothewise.com-2979-83348823-24644-bou...@inbox.example.com; 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 WiseThe Deliverability Experts! Direct: 650 678-3454Fax: 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
Re: [ietf-dkim] Weird i= in client mail
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. 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=40wordtothewise.com-2979-83348823-24644-bou...@inbox.example.com; 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 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
Re: [ietf-dkim] Weird i= in client mail
On Jun 17, 2013, at 3:29 PM, Dave Crocker wrote: 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. Thanks. That does help. 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=. Again, thank you. I've asked the client why they chose that, we'll see what they day. laura -- Laura Atkins Word to the WiseThe Deliverability Experts! Direct: 650 678-3454Fax: 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
Re: [ietf-dkim] Weird i= in client mail
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
On Jun 17, 2013, at 4:09 PM, John Levine jo...@taugh.com wrote: 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. 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
Re: [ietf-dkim] Weird i= in client mail
At one stage i= was thought to represent different mail streams with different reputation, 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
On Jun 17, 2013, at 8:58 PM, John Levine jo...@taugh.com wrote: At one stage i= was thought to represent different mail streams with different reputation, 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. ...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)... ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
On 6/17/2013 9:20 PM, Franck Martin wrote: On Jun 17, 2013, at 8:58 PM, John Levine jo...@taugh.com wrote: At one stage i= was thought to represent different mail streams with different reputation, 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 days (tho wrong too)... 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/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
