it will be semantically wrong
and
mnemonically confusing. Wrong because it's not the domain doing the signing,
per the definition of SDID, and confusing because the term is almost identical
to SDID.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
, here, needs far more active management than the group has
been getting.
3. Then we should follow your Option 2.
d/
[1] The best way to indicate that draft-ietf-dkim-rfc4871-errata is from a
group effort is to refer to it by its draft name.
--
Dave Crocker
Brandenburg
.
- /Richard Nixon/
We could use i=, but it would be wrong.
d/
ps. Yes, this means changing the definition of author signature
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org
also remove the confusion about granularity.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
and it makes too many changes. Neither
of these is included (or excluded) from the RFC Editor or IESG Errata rules.
Pasi should explain his basis for adding these constraints.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL
pasi.ero...@nokia.com wrote:
Dave Crocker wrote:
2. The RFC Editor publishes rules for Errata. So does the IESG.
You indicate that Pasi is refusing to process
draft-ietf-dkim-rfc4871-errata-02 for two reasons: It introduces new
terminology and it makes too many changes. Neither
Pasi,
Did I miss your response about this substantive point?
d/
Dave CROCKER wrote:
pasi.ero...@nokia.com wrote:
- I think introducing clear terminology for the identity/identities (or
identifier/identifiers) output by DKIM would make DKIM significantly
easier to understand, and would
get easier to understand with this
terminology include at leastSections 1.1, 2, 2.1, 2.2, 3.1.1, 3.1.4,
4.1, 4.3, 4.5, and 5.
That sounds like a normative change to DKIM, but the Overview isn't intended to
be normative. Wouldn't that change better apply to RFC4871bis?
d/
--
Dave Crocker
in
the document is evidence of WG consensus.
You can't have it both ways.
Care to cite the specific postings that you are suggesting provide some sort of
contradictory statements?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE
that has not been properly vetted. [SPF] results SHOULD BE
handled as specified by section 3.4.3.
This is the same confusion of venues as cited above.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates
that ensuring specification discipline and clarity somehow
prevents later protocol enhancement, although it demonstrably does not.
d/
Jim Fenton wrote:
Dave CROCKER wrote:
The fact that upper layers sometimes reach down into lower layer
information, and the fact that this is sometimes useful
.
The DKIM spec has no equivalently clear and precise definition of its payload.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
in the Signing spec will somehow
prevent value-add functions that go beyond the spec.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
[1] is ready to go. Process it.
a), please.
For example, Eliot's draft does not attend to the basic requirement for
specifying what is primary output. (Or, for that matter, distinguishing output
from protocol internals.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
, that it should
be
changed to use d=, rather than i=. With a clarification of the roles of d= and
i=, as DKIM signature output, relying on i= by ADSP can reasonably be subject
to
re-evaluation. Was your omission intentional?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
DKIM Chair wrote:
Dave's draft clarifies the meaning and use of i=. It's time for a last
call on it.
Stephen was planning to do that on Monday.
thanks for clarifying that.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
requests for progressing the current draft.
Concerning the alternative proposal, I've seen only one posting in its favor.
Consequently, I'd like to ask that we go through a working group Last Call for
rfc4871-errata-02.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
, direct support.
2. My request was for +1/-1 postings on draft-ietf-dkim-rfc4871-errata-02, not
a
request for a multi-stage sequence starting with meta-questions about process.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE
Eliot Lear wrote:
On 2/12/09 7:31 PM, Dave CROCKER wrote:
1. Jim sent the only posting that I read as simple, direct support.
And Murray also indicated support, at least in part,
In part is different from complete.
I happen to support your proposal... in part. Unfortunately
FYI, apologies, folks.
The latest version of the draft is errata-02, not errata-03.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
in
understanding the impact of the requested change.
Thanks.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
, as output of DKIM validation, the string remains opaque.
DKIM imparts and communicates no details about the meaning of the string, nor
its relationship to other identifiers.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE
that are currently
are in the draft. But I don't think that the semantics of the language
in the current draft are well enough understood by many to see that
distinction.
-Jim
Dave CROCKER wrote:
Jim,
We've had quite a bit of confusion about a number of different things.
Focusing on a particular term
the latter.
The latter invites one reader to apply the rule differently than another
reader.
The former does not.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org
-level systems (such as explicit allow/whitelists and reputation
systems) and/or to the end user.
The goal of the Errata has been only to fix the d=/i= issue and not attack
other
issues with the RFC.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
, 5 Feb 2009 18:53:39 -0800 (PST)
From: IETF I-D Submission Tool idsubmiss...@ietf.org
To: dcroc...@bbiw.net
A new version of I-D, draft-ietf-dkim-rfc4871-errata-02.txt has been
successfuly
submitted by Dave Crocker and posted to the IETF repository.
Filename:draft-ietf-dkim-rfc4871
that
helpful, except for making the document bigger.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
name strings, it doesn't mean
that the recipient side can't know it's a domain name. It means that they
cannot know the scheme the signer used for choosing sub-domain names.
At 11:47 03-02-2009, Dave CROCKER wrote:
ps. FWIW, my intent in included SDID was that the particular naming scheme
it is?
it's not definitive, by any means, but take a look at:
http://dkim.org/#deployment
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Dave CROCKER wrote:
Generally, the changes dealt with:
Sorry, forgot an important item:
3. Changed section 6.3 and Appendix D references to be to SDID (d=)
Since the new consensus appears to be that i= has semantics that are entirely
undefined, it does not seem possible that the wg
is considered reasonable for satisfying it. And I mean that as a
specification-clarity issue, not an user interface philosophy issue.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http
of it.
Enjoy!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
indicative of the decision to encode, rather than the
abilithy
to decode.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
decided
about
it in the past -- or, rather, what you wish would have been decided about it --
is pretty astonishing.
What matters is consensus about fixing the problem... now.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE
the dealine by almost 2 weeks. We might ask for an exception, I
suppose. I have no idea whether they are ever granted.
But one way or the other, yes, it does look like we should find a way to meet.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Iverson wrote:
On Fri, Jan 30, 2009 at 10:55 AM, Dave CROCKER d...@dcrocker.net wrote:
Al Iverson wrote:
Also, I wish somebody smarter than me would take a
shot at a PPT for dummies like me, showing a few examples of how a
receiver would like to use DKIM.
Can you describe particular usage
one) then I can justify the expense.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to be controlled.
You are confusing authentication with reputation.
Folks,
Speaking of dogs, this horse has been beaten to death, turned into dogfood,
consumed, and processed by the community waste disposal center.
We *really* don't need to pursue it again.
d/
--
Dave Crocker
Brandenburg
.
If the Errata could be posted with the RFC Editor as approved by the working
group that might suffice, for the quick effort.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
a note that express it.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
useless for signing by any agent in
the sequence other than the author's. This goes entirely against the usage
flexibility that has (always) been a goal of DKIM.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL
Steve Atkins wrote:
On Jan 28, 2009, at 8:49 PM, Dave CROCKER wrote:
So I'd be interested in seeing your basis for believing that it is
an order of magnitude more complex that it needs to be...
Look at the current thread. Removing just i= and it's friends would
reduce the confusion
.
Good. Can the errata document that seeks to clarify SDID v/s UAID
please, please drive this point home? With enough MUST NOT BE ASSUMED
type wording?
Sure...
Please suggest specific text to add/change in the draft Errata.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
use.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Suresh Ramasubramanian wrote:
On Wed, Jan 28, 2009 at 7:42 PM, Dave CROCKER d...@dcrocker.net wrote:
It provides data integrity, for the portions covered by the hash, and it
authenticates the asserted signing identity. It does *not* assert
authorization of the From: field.
Unless
Suresh Ramasubramanian wrote:
On Wed, Jan 28, 2009 at 8:05 PM, Dave CROCKER dcroc...@bbiw.net wrote:
Including the From: field in the DKIM hash does *not* carry the semantic
that it has valid content!
As I said .. in certain cases.
...
Send email through our webmail after having
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
it has.
So I'd be interested in seeing your basis for believing that it is an order of
magnitude more complex that it needs to be...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http
SM wrote:
At 17:06 26-01-2009, Dave CROCKER wrote:
Common interpretation of the document is that it *already* provides
two identities. The Errata merely makes clear their nature and priority.
The draft Errata does not update Section 1.1 of RFC 4871 which discusses
about Signing
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Suresh Ramasubramanian wrote:
The few large cases are
1. Exceptions to the general rule
2. Useful only when backed with some out of band discussion about
these ..
How does (or should) this affect the proposed Errata specification?
d/
--
Dave Crocker
Brandenburg
. For 10 and 11, change UAID to be SDID.
2. Add text about the use of i= stating that it's use for assessment goes
beyond using d= and is MUST be based on additional knowledge of its creation
that is outside the specification.
Does this reflect what you two are implying?
d/
--
Dave Crocker
it inappropriate to use for identifying a mail
stream, that is, aggregate traffic.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
that the current specification does
not provide.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
of scope here.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
/errata.php.
The changes are narrow and few. We really don't need to generate a brand new
RFC just for this. Or at least, not yet, IMO.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http
that the document says is its primary goal.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
in the absence of empirical
data.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
be implemented given the
defined syntax/semantics.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
, simpler, more
stable, and sufficient value.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
them as
new. Although the proposed input (d= and i=) for the Assessor module
may not affect existing implementations, the draft changes the
definition of these tags.
Errata aren't allowed to fix something by changing it?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Jim Fenton wrote:
Dave CROCKER wrote:
For a base spec to say the value is opaque and another spec to come along
and
say I'm announcing the particular, and possibly interesting, scheme that I
follow for creating that value, and I promise to conform to that scheme for
all
such values
of
protocol design, that is a nicely collaborative enhancement, with no penalty to
anyone choosing not to participate. The base specification still works.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates
on ISPs aware of this i= classification. It means that
the
mechanism won't scale, since we cannot assume that an arbitrary receiver will
be
aware of an arbitrary signer's scheme.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
is (again) surfacing this basic
confusion.
Approving ADSP, in the absence of resolving this basic confusion about what
value to use, merely entrenches the confusion further.
It doesn't actually resolve it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
.
Perhaps some text that notes that i= MAY match the From: address but that it is
not required to, even when i= is in the syntax of an email address?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates
development, no I would not suggest it
as a venue for reviewing VBR. Given the relatively quiescent state of the
list,
I don't think we need to worry that much about scope or focus confusion.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
understand that.
ASRG lists, perhaps?
-Jim
Dave CROCKER wrote:
The draft doesn't specify a discussion venue. I believe the plan is to
request
Informational RFC status.
With respect to the IETF, is there a better place for discussion than the
DKIM list?
d/
Original Message
be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12283rfc_flag=0
___
IETF-Announce mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/ietf-announce
--
Dave Crocker
Brandenburg InternetWorking
for
Dummies,
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
More Wiener schnitzel, please, said Tom, revealingly.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Dave
concern, I'll
post it in the DKIM FAQ. (I suggest running it past the list, to get some
agreement on the details.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
and clarification.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
?
Thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Murray S. Kucherawy wrote:
On Tue, 30 Sep 2008, Dave CROCKER wrote:
I'd say this is the general list for questions about deployment and
operations. This is where I believe questions about reputation and
multiple signatures should be discussed, except where those coversations
relate
under the
http://dkim.org#introduction
section
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Murray S. Kucherawy wrote:
On Tue, 30 Sep 2008, Dave CROCKER wrote:
I'd like to clarify the role of a new 'users' list from the DKIM lists
that already exist. The existing ones are:
Standardization
I'm guessing that's ietf-dkim.
yes. (sorry I didn't provide the pointers
Folks,
A consultants' page is now available at:
http://dkim.org/deploy/consult.htm
with a pointer from the dkim.org home page.
Please circulate this notice and especially suggest anyone offering services
send me a completed template form.
d/
--
Dave Crocker
Brandenburg
or might not result in a snippet
of text that has community consensus.
Do others see this differently?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
mailing list to the dkim.org mix shortly. At this point,
the real question is how to help someone coming to the web page to figure out
what mailing lists to use and how...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL
of rationale is that the page has already crossed the line, with:
Software and Services Deployment
http://dkim.org/deploy
So really -- to use one of my favorite cliche's -- we are just haggling about
price...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
listing of consultants? (hmmm. Unless there is an associated
discussion
list they would sign up for, beforehand?)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
, let it get populated, let it get
used, and see how useful folks feel it is. At some point, I fully expect a
sense of rough consensus, one way or the other.
Talk about eating our own dog food!
Well, it's true that this might be a dog of an idea...
d/
--
Dave Crocker
Brandenburg
credited/blamed for the suggestion. Again, this isn't about
recommendations.)
The proposed format of an entry is:
Consultant or Company name:
Type of services:
Email:
Phone:
Geographic coverage:
Should I have other information on the form?
Thanks?
d/
--
Dave Crocker
Stephen Farrell wrote:
It might be no harm if folks who do think ADSP should
go ahead would respond to this saying so.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http
SM wrote:
In all cases, new values are assigned only for values that have been
documented in a published RFC
RFCs are generally published. That word could be dropped from the sentence.
You are technically correct. However, the term draft RFC is relatively
common.
d/
--
Dave
for
discussions about using existing specifications.
Please take a look at:
http://dkim.org/#deployment
I think, perhaps, the best list for your concerns is:
http://mipassoc.org/mailman/listinfo/dkim-ops
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
FOlks,
I just discovered that while the html and pdf versions of ssp-04 had been
posted
to the DKIM site, the ietf-dkim page did not cite them and the diffs from -03
hadn't been generated and posted.
These are now available at:
http://dkim.org/ietf-dkim.htm#adsp
d/
--
Dave Crocker
.)
Every issue was reviewed and considered carefully. If you see a change that
was
not made or not made to your satisfaction, and you wish to pursue the matter
further, please do raise it with the working group.
/d
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
concentrate
on the overview and process the deployment draft issue subsequently.
S.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
areas to specify -- invites confusion rather than clarity.
And... my current reading of the draft under revision is that it has no
normative text. My personal expectation is that it will stay that way...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
. missed the different venue.
and I think there has been almost no discussion about the deployment doc?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
to the signer with any local encoding that will
be modified before transmission, that modification to canonical [RFC2822]
form MUST be done before signing. In
Carries the rather strong implication that DKIM only works on compliant
messages.
d/
--
Dave Crocker
Brandenburg
John Levine wrote:
My theory is that DKIM only applies to valid 2822 messages, and it's not a
substitute for a sanity check for all the screwy things one can send in a
non-conformant message.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
.
No need to thank me.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
(just to make sure the importance level of this thread is entirely clear: I
said nits.)
Murray S. Kucherawy wrote:
Dave Crocker wrote:
One should not say published for a draft, but if one were to say it,
in fact an ADSP draft is indeed published.
But it has not been declared a working
are likely to
be free. In fact, one bit of feedback I got was explicit about these
additional tests as costing too much. They had tried and found they added too
much delay.
FWIW.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Dave Crocker wrote:
SSP-03 has a number of xml2rfc errors.
These should be fixed, per draft-levine-dkim-adsp-00.
Entirely predictably, I now cannot find the serious errors in the ssp-03
draft, although they were hounding me when trying to produce txt and/or pdf
versions in order to make
501 - 600 of 1246 matches
Mail list logo
