[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
