Folks,
The attached are the final minutes from Montreal for the
record. There're only trivial changes from the earlier
draft minutes.
Cheers,
S.
Title: IETF-66 FINAL DKIM Meeting Notes
IETF-66 FINAL DKIM Meeting Notes (-01)
Charter: http://www.ietf.org/html.charters/dkim-charter.html
8. The Protocol is not required to publish a Practice of any/all
unreleated third parties that MUST NOT sign on the domain
holder's behalf.
[INFORMATIVE NOTE: this is essentially saying that the
protocol doesn't have to concern itself with being a
As I read the document, if I indicate a DKIM signing complete
policy, but never actually send any (signed or unsigned) mail,
then I have achieved the goal set out in requirement #2 from
section 5.3 (doesn't send mail).
Now I don't object to the requirement itself, but would like
to suggest
On 8/9/06, Stephen Farrell [EMAIL PROTECTED] wrote:
Damon wrote:
8. The Protocol is not required to publish a Practice of any/all
unreleated third parties that MUST NOT sign on the domain
holder's behalf.
[INFORMATIVE NOTE: this is essentially saying that the
- Original Message -
From: Stephen Farrell [EMAIL PROTECTED]
To: Damon [EMAIL PROTECTED]
Cc: DKIM List ietf-dkim@mipassoc.org
Sent: Wednesday, August 09, 2006 11:38 AM
Subject: Re: [ietf-dkim] Clarification: Requirement #8
Damon wrote:
8. The Protocol is not required to publish a
I went through the draft and marked it up. I'll break these up into
individual messages for each comment. I'll start with a context diff of the
draft and proposed changes and then give a discussion of why...
*** 321,328
unsigned outweights the risk of illegitimate mail being
*** 350,356
previous scenario. A receiver, on the other hand, may be able to
take advantage of the knowledge the domain's practice of signing all
mail in order to use it to bias filters against the unexpected
!arrival of a piece of unsigned or damaged in transit mail.
6. Practices and Expectations MUST be presented as an information
service from the sender to be consumed as an added factor to the
receiver's local policy. In particular a Practice or
Expectation MUST NOT specify any particular disposition stance
that the receiver
***
*** 368,374
That said, DKIM uses DNS to store selectors. Thus there is always
the ability for a domain holder to delegate all or parts of the
_domainkey subdomain to a third party of the domain holder's
!choosing. That is, the domain holder can always set
***
*** 465,471
1. Discovery mechanism MUST be rooted in DNS.
!2. Discovery mechanism MUST converge in a deterministic number of
exchanges.
[Informative Note: this, for all intents and purposes is a
--- 470,476
1. Discovery mechanism
***
*** 474,480
expectation is few.]
3. Discovery mechanism MUST NOT overload semantics of existing DNS
!resource records where name space collisions are possible.
5.2. Transport requirements
--- 479,485
expectation is few.]
*** 508,514
5.3. Practice and Expectation Requirements
In this section, a Practice is defined as a true statement according
!to the domain holder of its intended externally viewable behavior.
An Expectation combines with a Practice to convey what the domain
holder
***
*** 537,549
for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to
! specify the domains that are
The message I just sent with this subject was in error. I'll send it again,
correctly, in a few minutes.
Sorry,
Scott K
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
*** 537,549
for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to
! specify the domains that are allowed to sign on
I've finished my first cut at comments and I'd like to add my thanks to Mike
for putting together such a good draft in such a short amount of time.
Scott K
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
*** 574,580
blacklist repository.]
9. The Protocol MUST NOT be required to be invoked if a valid first
! party signatures is found.
10. [PROVISIONAL] A domain holder MUST be able to publish a Practice
which enumerates the acceptable cryptographic
--- 542,556
for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to
! specify the domains that are allowed to sign on its
On Wednesday 09 August 2006 13:26, Damon wrote:
--- 542,556
for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to
!
On Aug 8, 2006, at 6:36 PM, Hector Santos wrote:
| 10. [PROVISIONAL] A domain holder MUST be able to publish a
Practice
| which enumerates the acceptable cryptographic algorithms for
| signatures purportedly from that domain.
|
| [INFORMATIVE NOTE: this is to counter a bid
--- 350,357
previous scenario. A receiver, on the other hand, may be able to
take advantage of the knowledge the domain's practice of signing all
mail in order to use it to bias filters against the unexpected
!arrival of a piece of unsigned, damaged in transit mail, or mail
Damon wrote:
6. Practices and Expectations MUST be presented as an information
service from the sender to be consumed as an added factor to the
receiver's local policy. In particular a Practice or
Expectation MUST NOT specify any particular disposition stance
Change 1: done.
Change 2: folded into the next paragraph which has other concerns about
the NS approach.
Mike
Scott Kitterman wrote:
***
*** 368,374
That said, DKIM uses DNS to store selectors. Thus there is always
the ability for a domain holder to delegate
At 1:02 PM -0400 8/9/06, Scott Kitterman wrote:
***
*** 474,480
expectation is few.]
3. Discovery mechanism MUST NOT overload semantics of existing DNS
!resource records where name space collisions are possible.
5.2. Transport requirements
---
Following myself up with a clarification:
Michael Thomas wrote:
In particular, a Practice or Expectation MUST NOT mandate any
disposition stance on the receiver.
The reason that I've written it in this way was purposeful on my part: the
sender's expectation is that there should be a
Scott Kitterman wrote:
I went through the draft and marked it up. I'll break these up into
individual messages for each comment. I'll start with a context diff of the
draft and proposed changes and then give a discussion of why...
*** 321,328
unsigned outweights the risk of
Damon wrote:
--- 350,357
previous scenario. A receiver, on the other hand, may be able to
take advantage of the knowledge the domain's practice of signing all
mail in order to use it to bias filters against the unexpected
!arrival of a piece of unsigned, damaged in
Scott Kitterman wrote:
*** 508,514
5.3. Practice and Expectation Requirements
In this section, a Practice is defined as a true statement according
!to the domain holder of its intended externally viewable behavior.
An Expectation combines with a Practice to convey what
- Original Message -
From: Douglas Otis [EMAIL PROTECTED]
To: Hector Santos [EMAIL PROTECTED]
SMTP is not an end-to-end protocol. The store-and-forward
feature of SMTP means _any_ email-address may not be the
final destination for a message.
As far as the initial author concern it
I was thinking about this and wasn't sure if it was worth bringing up. I
mean, in DSAP we have failure-handling statements, but I can go either way.
But let me throw out the idea of the domain wishing to express a disclaimer
that is something failures, it is HIGHLY desirable that you not retain
Tony Hansen wrote:
Damon wrote:
--- 350,357
previous scenario. A receiver, on the other hand, may be able to
take advantage of the knowledge the domain's practice of signing all
mail in order to use it to bias filters against the unexpected
!arrival of a piece of
On Wednesday 09 August 2006 14:34, Tony Hansen wrote:
-1
I want companies such as eCard senders or News Agencies to be able to 1)
send a message on my behalf while 2) marking themselves as the sender
and 3) being able to sign the message. This minimally requires support
for RFC2822.Sender
Paul Hoffman wrote:
At 1:02 PM -0400 8/9/06, Scott Kitterman wrote:
***
*** 474,480
expectation is few.]
3. Discovery mechanism MUST NOT overload semantics of existing DNS
!resource records where name space collisions are possible.
5.2.
Scott ---
Scott -- I think it's both explicit and specific in other requirements
that the protocol
must publish that data, and some of those are MUST strength. I really
don't see why
we need to restate that here.
That and I don't think there is any explicit or implicit proscription
here on
As always, a requirements document is a set of MINIMUM requirements. I'd
just assume we not get too far down in the details of things that we can
just
as easily discuss in the design phase. This seems like one that could
wait to me.
Mike
Hector Santos wrote:
I was thinking about this
On Wednesday 09 August 2006 16:53, Michael Thomas wrote:
Scott ---
Scott -- I think it's both explicit and specific in other requirements
that the protocol
must publish that data, and some of those are MUST strength. I really
don't see why
we need to restate that here.
That and I don't
Michael Thomas wrote:
Tony Hansen wrote:
add RFC2822.Sender
I'm not the chair, but I've seen considerably less consensus about
anything other
than rfc2822.from. I'm frankly not sure I understand it very well.
I know I don't understand it!
Maybe a more detailed use-case would help?
Scott Kitterman wrote:
I'd suggest that we MUST NOT require instead of MUST NOT
specify. That achieves the goal of not having receiver
policy cause protocol failures, but allows more freedom in
design to communicate sender expectations.
In other words it cannot say receiver SHOULD reject,
Hector Santos wrote:
Protocol MUST allow for a informational text note for the
policy.
I always hated the exp= explanations in SPF. A disclaimer
n=convoluted_legalese isn't better, IMO receivers won't care
about it. You'd also get I18N issues with such disclaimers.
Frank
On Aug 9, 2006, at 11:43 AM, Hector Santos wrote:
From: Douglas Otis [EMAIL PROTECTED]
SMTP is not an end-to-end protocol. The store-and-forward feature
of SMTP means _any_ email-address may not be the final destination
for a message.
As far as the initial author concern it is.
No.
Tony Hansen wrote:
This has nothing to do with PRA and its support for
Resent-From and/or Resent-Sender.
If there is an SSP for A, why apply it to Sender [EMAIL PROTECTED],
but not Resent-From [EMAIL PROTECTED] ?
Can you use an SSP for B and 2822-From [EMAIL PROTECTED], if the
mail was
Doug,
Too many words, and trending away from resolution of pretty
much anything. I suggest you try to come to agreement between
yourselves offlist, and then share your conclusions afterwards,
Thanks,
Stephen.
Douglas Otis wrote:
On Aug 9, 2006, at 11:43 AM, Hector Santos wrote:
From:
Frank,
Frank Ellermann wrote:
Tony Hansen wrote:
This has nothing to do with PRA and its support for
Resent-From and/or Resent-Sender.
If there is an SSP for A, why apply it to Sender [EMAIL PROTECTED],
but not Resent-From [EMAIL PROTECTED] ?
Can you use an SSP for B and 2822-From
- Original Message -
From: Michael Thomas [EMAIL PROTECTED]
To: Hector Santos [EMAIL PROTECTED]
So maybe just adding a new requirement?
Protocol MUST allow for a informational text note for the policy.
As always, a requirements document is a set of MINIMUM requirements. I'd
just
Stephen Farrell wrote:
Can I suggest making concrete proposals, aimed at moving
towards consensus
It won't help if I reject three proposals add 2822-Sender
only because I don't understand it. It also won't help if
I'd support it, but have no clue why Resent-* are excluded.
Frank
On Wednesday 09 August 2006 20:32, Frank Ellermann wrote:
Stephen Farrell wrote:
Can I suggest making concrete proposals, aimed at moving
towards consensus
It won't help if I reject three proposals add 2822-Sender
only because I don't understand it. It also won't help if
I'd support it,
- Original Message -
From: Stephen Farrell [EMAIL PROTECTED]
To: Frank Ellermann [EMAIL PROTECTED]
Cc: ietf-dkim@mipassoc.org
Sent: Wednesday, August 09, 2006 7:52 PM
Subject: Re: [ietf-dkim] Re: Requirements comment: Bigbank example
description
Frank,
Frank Ellermann wrote:
Tony
Stephen Farrell wrote:
Michael Thomas wrote:
Tony Hansen wrote:
add RFC2822.Sender
I'm not the chair, but I've seen considerably less consensus about
anything other than rfc2822.from. I'm frankly not sure I understand
it very well.
I know I don't understand it!
Maybe a more
- Original Message -
From: Scott Kitterman [EMAIL PROTECTED]
Here is a concrete proposal
In this round, we only specify sender policy for 2822.From.
To the extent we have consensus that SSP is a good thing, we
have consensus that it should cover 2822.From. Once you get
beyond
That this thread is being discussed brings up a requirement that policy
record syntax should be capable of supporting multiple identities.
A subquestion of that is if policy record identity should or should
not be part of the query selection process (i.e. _from._policy if DNS).
That BTW
On Wednesday 09 August 2006 22:30, Tony Hansen wrote:
Stephen Farrell wrote:
Michael Thomas wrote:
Tony Hansen wrote:
add RFC2822.Sender
I'm not the chair, but I've seen considerably less consensus about
anything other than rfc2822.from. I'm frankly not sure I understand
it very
Tony Hansen wrote:
!! arrival of a piece of unsigned, damaged in transit mail, or if
a RFC2822.From sender policy exists which specifies authoritative
domain(s), a mail signed by an entity other than described in the sender
policy.
add RFC2822.Sender
Let's try an exercise:
Why?
How
Tony,
Then your domain (att.com) will need to declare a relaxed 3rd party
signature concept.
For example:
Using SSP-01 this is defined as default policy or o=~.
Using a DSAP framework, you would declare:
OP=OPTIONAL;
3P=OPTIONAL;
In both cases, you are using a NEUTRAL policy.
You
On Wed, Aug 09, 2006 at 10:30:21PM -0400, Tony Hansen allegedly wrote:
Stephen Farrell wrote:
Michael Thomas wrote:
Tony Hansen wrote:
add RFC2822.Sender
I'm not the chair, but I've seen considerably less consensus about
anything other than rfc2822.from. I'm frankly not sure I
54 matches
Mail list logo
