Based on the discussions, and the recent entry to produce a "counter
proposal" I would like to ask if we can trying to avoid putting this
document through another cycle of review vs doing the job right with
the correct technical information.
For example, IDEALLY per your itemize list:
I owe you some data here. I don't know either way other than I have
not seen (or focused on) any particular importance in the API we are
2) TXT Records
This requires a "code adjustment" for DKIM DNS clients to parse for
the v=DKIM1. This is required for SPF so any implementation that
supports SPF and wishes to add DKIM will not be at a terrible lost
with this adjustment.
3) Section 5.4
I think Jim's text makes the technical adjustments. But personally, I
still believe there needs to be an "5322.From exception" paragraph
following the section 5.4 "last header" rule stipulated in the section.
I think the choice has to been made on giving this to "Team A" to get
the job done tomorrow, or giving this to "Team B" to get the job done
right even though it may take longer. I personally do not see why the
"rush" is trumping the need to do this right.
All this began with a post I made providing Field Experience input
regarding how a major MTA had already change how it implemented 4871
with an additional requirement for a single 5322.From and later
finding out why they did this, leading to the security loophole
This MTA's C/C++ open source API is not locked down to a particular
vendor SMTP software and probably represents many other MTAs DKIM
implementations, including ours.
I just feel we are wasting time with semantics, as important as that
may be IETF wise, but I'm afraid it seems to attempt to minimize the
importance of having a straight forward technical correction
description which may include code change requirements.
Thanks for listening.
Hector Santos, CTO
Barry Leiba wrote:
We seem to be bush-whacking again, rather than staying on the trail.
I don't mind (actually I like) some level of general discussion, but
the chairs would like to focus on our immediate goal for now, so I'm
asking folks to refrain, for the moment, from discussion that isn't
directly addressing the text of 4871bis.
That includes discussion of MUA issues. We can go back to talking
about that later, but 4871bis is not the place for that, either from a
protocol point of view or from a procedural one.
We have reviews from Jim, SM, and John that the editors are working on
responding to (John's is new enough that I haven't digested it all
yet, and I'm sure the editors haven't either). We also have three
significant issues that we need to make sure we have resolved
1. How to handle a key record with empty "g=" and absent "v=" (section
6.1.2, list item 6).
Proposed change: Remove "g=" altogether, along with all references to
it. Surveys of what's out there show vanishingly few cases that use
"g=" with any value other than "*" or empty, so this can be removed as
an unused feature.
2. Advice about wildcards in TXT records.
Proposed change: Add a note in section 6.1.2 warning about the effect
of wildcard TXT records on finding DKIM key records.
3. The issue of multiple occurrences of header fields that may only occur
Proposed change: Add text to section 5.3 recommending that verifiers
check that the message complies with specs, and that they not validate
a non-compliant message. Add a new section 8.14 to the Security
Considerations, explaining the attacks that can be done using this
We ask the editors to consider the latest batches of comments, respond
to them as necessary, produce an -03 version, and post it when they
have it ready.
We ask all participants to speak up specifically about the three
issues above, and let us know whether or not the proposed change is
acceptable. The editors can post the specific text they're using, if
we have anything to discuss about them. I believe we have agreement
on the text for number 2, so we should be set on that one. I haven't
seen a definitive poll about removing "g=" (number 1), but I *think*
we have consensus on that. Text for number 3 is still being worked
Please start new threads for these discussions, rather than responding
directly to this one, and let's keep the threads for the three items
And, again, we particularly ask all participants to refrain from other
discussions that are not specifically about text for 4871bis, so we
can get that document done.
Barry, as chair
NOTE WELL: This list operates according to
NOTE WELL: This list operates according to