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

[Hector Santos]

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  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

[Douglas Otis]

On Jun 20, 2013, at 11:28 AM, John Levine  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

[John Levine]

>> 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

[Dave Crocker]

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

[Rolf E. Sonneveld]

> 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

[Jon Callas]

On Jun 19, 2013, at 6:05 PM, 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, 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

[Wietse Venema]

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

[Wietse Venema]

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

[Rolf E. Sonneveld]

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="?

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

[John R. Levine]

> 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

[Jon Callas]

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

[Michael Thomas]

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 Levine  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

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

[Tony Hansen]

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 Levine  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.

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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Dave Crocker]

On 6/17/2013 9:20 PM, Franck Martin wrote:
> On Jun 17, 2013, at 8:58 PM, John Levine  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

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

[Franck Martin]

On Jun 17, 2013, at 8:58 PM, John Levine  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

[John Levine]

>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

[Franck Martin]

On Jun 17, 2013, at 4:09 PM, John Levine  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

[John Levine]

>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

[John Levine]

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

[Laura Atkins]

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 Wise"The Deliverability Experts!"
Direct: 650 678-3454Fax: 650 249-1909
AIM: wttwlaura  YIM: wttw_laura
Delivery blog: 


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

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

[Dave Crocker]

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

[ietf-dkim] Weird i= in client mail

[Laura Atkins]

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 Wise"The Deliverability Experts!"
Direct: 650 678-3454Fax: 650 249-1909
AIM: wttwlaura  YIM: wttw_laura
Delivery blog: 


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