On 4/27/11 3:56 AM, Hector Santos wrote:
> What is surreal about this brush back to make a SIMPLE change is that
> it touches base with the often stated concern about DKIM DNS
> management complexities as one of the barriers for adoption.
>
> In a perfect DKIM spec world, this section should cover
On 27/Apr/11 01:25, John Levine wrote:
> Whether the name in the DNS record should be brisbane or
> brisbane._domainkey or brisbane._domainkey.example.org depends
> entirely on the most recent $ORIGIN line in the master file. If the
> $ORIGIN is _domainkey.example.org, an entirely plausible scenar
On 26/Apr/11 23:50, MH Michael Hammer (5304) wrote:
>>> However I suggest adding the usual waffling qualifier:
>>>
>>> claiming (some) responsibility
>>
>> I think we should drop "signed" from it, since that's what the entire
>> specification is about in the first place.
>>
>
> I think it is
Hi, Murray,
On 4/26/11 8:25 PM, Murray S. Kucherawy wrote:
Folks,
With four days left in the WGLC for our remaining two documents, there
are several items still open in the trackers. Only items that are
either minor/editorial in nature or those that get working group
consensus will make i
Rolf E. Sonneveld wrote:
> -1. I suggest to add clarifications etc. to a future update of RFC5863
> (deployment and operations document).
So you agree clarification is required but not for RFC4871bis?
Interesting. Lets see:
1) A few words clarification for DKIM-BASE standard. A little
conf
On 26/Apr/11 23:13, Dave CROCKER wrote:
> I think I understand the intent, here, and I'm supportive of the goal.
> However
> the text is technically invalid. A DKIM signature has only one meaning,
> relative to existing, formal specification.
>
> "Inferring" meanings beyond what is defined is
Alessandro Vesely wrote:
> On 27/Apr/11 01:25, John Levine wrote:
>> Whether the name in the DNS record should be brisbane or
>> brisbane._domainkey or brisbane._domainkey.example.org depends
>> entirely on the most recent $ORIGIN line in the master file. If the
>> $ORIGIN is _domainkey.example.or
I'm puzzled by this message
http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00447.html
Its date is Tue, 26 Apr 2011 09:01:41 -0700 (PDT), and it talks about
a submission on 2011-04-10. However, the given datatracker URL
(1530) results in a 404 Not Found error, and the mentioned draf
Dave CROCKER wrote:
> The best I can suggest is something along the lines of noting that
> assessment-level heuristics can be aided by certain choices of signature d=
> names. And then specifying what they might be, so that both signers and
> verifiers know how to encourage success for the heur
On 4/27/11 12:47 PM, Hector Santos wrote:
> Rolf E. Sonneveld wrote:
>
>> -1. I suggest to add clarifications etc. to a future update of
>> RFC5863 (deployment and operations document).
>
> So you agree clarification is required but not for RFC4871bis?
No. Just: IF clarification is required, it h
> I'm puzzled by this message
>
> http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00447.html
>
> Its date is Tue, 26 Apr 2011 09:01:41 -0700 (PDT), and it talks about
> a submission on 2011-04-10. However, the given datatracker URL
> (1530) results in a 404 Not Found error, and the me
Rolf E. Sonneveld wrote:
>> Interesting. Lets see:
>>
>> 1) A few words clarification for DKIM-BASE standard. A little
>>[LESS] confusion for Windows people and domains using
>>ISP managed DNS zones.
>
> Well, maybe it's time Windows people leave their .local zones and
> discover a whole
On Tue, 26 Apr 2011 13:22:15 +0100, Alessandro Vesely
wrote:
> I guess Message-ID is among those "structural, not semantic" fields.
> I concur. However, we miss a field that says an MTA is _knowingly_
> breaking whatever signatures may be present.
The Message-ID gets copied into the Reference
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Alessandro Vesely
> Sent: Wednesday, April 27, 2011 2:36 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Ticket #11
>
> On 26/Apr/11 23:50, MH Michael Hammer (5304
On 4/27/2011 9:27 AM, Murray S. Kucherawy wrote:
>> Could be more explicit:
>>
>>A single domain name that is the mandatory payload output of DKIM
>>and that refers to the identity claiming some responsibility for
>>the message by signing it.
>>
>> (I've left off "introduced into the m
> -Original Message-
> From: Michael Thomas [mailto:m...@mtcc.com]
> Sent: Tuesday, April 26, 2011 4:31 PM
> To: Murray S. Kucherawy
> Cc: DKIM IETF WG
> Subject: Re: [ietf-dkim] despair
>
> When you commit a 20 page diff without the benefit of a debugging
> pass and dev test, how much con
On 4/27/2011 9:45 AM, Murray S. Kucherawy wrote:
> I've been keeping up with the specification changes both in terms of the
> documentation and the impact of the changes on live source code. That's
> really helped to keep us honest in terms of backward compatibility.
...
> It is a useful data poi
On 04/27/2011 09:53 AM, Dave CROCKER wrote:
> With that sort of documented history, the responsibility to claim otherwise
> falls on the critic. Otherwise the wg is essentially being asked to prove a
> negative and almost serves as a DOS attack...
>
Denial of service on what/whom? As far as I
On 04/27/2011 09:45 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: Michael Thomas [mailto:m...@mtcc.com]
>> Sent: Tuesday, April 26, 2011 4:31 PM
>> To: Murray S. Kucherawy
>> Cc: DKIM IETF WG
>> Subject: Re: [ietf-dkim] despair
>>
>> When you commit a 20 page diff without th
I wanted to address Hotmail's use of ADSP, clarify our position on the issue of
authentication policy, and share a few bits of information the list may find
interesting.
Hotmail's use of DKIM+ADSP should not be interpreted as a political statement;
we implemented DKIM to offset the impact of we
On 4/27/2011 10:20 AM, Paul Midgen wrote:\
> We check ADSP every time we run DKIM and see the following policy
> distribution:
>
> 97.98% "unknown" (including domains not explicitly publishing policy)
> 2% "discardable"
> 0.02% "all"
Paul,
Cool. Thanks for sending that detailed note.
Are th
On 4/27/11 2:21 AM, SM wrote:
> Hi Doug, At 18:43 26-04-2011, Douglas Otis wrote:
> > Not validating input creates a bigger mess when used in conjunction
> > with RFC5336bis. As such, it seems unfair for the DKIM WG
> > operating within the Security area to close and then hand a mess
> > over to t
On Tue, 26 Apr 2011 02:33:11 +0100, Douglas Otis
wrote:
> Although DKIM is reviewed within IETF's security area, input validation
> by DKIM remains dangerously neglected. DKIM's Introduction indicates it
> can be implemented independent of clients. As such, few assumptions are
> safe in how u
On Tue, 26 Apr 2011 05:29:35 +0100, Dave CROCKER wrote:
>> DKIM doesn't create any binding between the RFC5322.From domain and the
>> "d="
>> value as you're doing. What you're talking about here falls into the
>> realm
>> of ADSP or other policy-like assertions, not DKIM itself which is the
On 27/Apr/11 01:42, John R. Levine wrote:
> I agree with Dave's changes,
+1, and also for Murray's advice of signing A-R fields. However, in
such case, the last phrase in Sec 7.2 (INFORMATIVE ADVICE to MUA
filter writers) should be changed from
To circumvent this attack, verifiers may wish to
Paul,
Thank you for sharing what you have. Comments/questions inline.
Mike
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Paul Midgen
> Sent: Wednesday, April 27, 2011 1:21 PM
> To: Scott Kitterman; ietf-dkim@mipassoc.
+1
Dave CROCKER wrote:
> On 4/27/2011 9:27 AM, Murray S. Kucherawy wrote:
>>> Could be more explicit:
>>>
>>>A single domain name that is the mandatory payload output of DKIM
>>>and that refers to the identity claiming some responsibility for
>>>the message by signing it.
>>>
>>> (I've
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Alessandro Vesely
> Sent: Wednesday, April 27, 2011 11:41 AM
> To: ietf-dkim@mipassoc.org
> Subject: [ietf-dkim] Two issues derived from Ticket #20: signature practices
>
> O
> Complaining is easy.
Indeed so. And so let's cut the meta-discussion and not go back to
throwing darts around. To the points:
Mike's concern is valid.
Murray's and Dave's notes have addressed it.
I, as a participant, am satisfied with Murray's and Dave's responses
to the concern. An
Trust me, this is (supposed to be) minor!
Someone off-list pointed out to me that it might be helpful to summarize the
expected outputs of a DKIM verifier. Indeed, on review, we don't do that all
in one place; some of it is in Section 3 and some in Section 7.
With that in mind, I propose this
On 4/27/2011 12:17 PM, Murray S. Kucherawy wrote:
> Actually if we're talking about A-R fields, RFC5451 talks plenty about this.
> Rather than duplicating advice, we should just refer to it.
as long as it's informative rather than normative, that seems entirely
constructive.
d/
--
Dav
On 4/27/2011 12:28 PM, Murray S. Kucherawy wrote:
> With that in mind, I propose this as a new Section 4.9, moving the others
> down:
>
> 4.9. Output Requirements
>
> The output of the verifier MUST embody:
>
> -A result code that indicates whether or not the signature was validated
> (PERMFAIL
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Dave CROCKER
> Sent: Wednesday, April 27, 2011 12:42 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Output summary
>
> > 4.9. Output Requirements
> >
> > The outp
On 4/27/2011 12:46 PM, Murray S. Kucherawy wrote:
>>> 4.9. Output Requirements
>>>
>>> The output of the verifier MUST embody:
sorry for not noticing this earlier: what does it mean for a verifier to
'embody' something.
i can guess, given the history of discssion but offhand i think it entire
Good Show! Some inline comments:
Paul Midgen wrote:
> I wanted to address Hotmail's use of ADSP, clarify our position
> on the issue of authentication policy, and share a few bits
> of information the list may find interesting.
>
> Hotmail's use of DKIM+ADSP should not be interpreted as
> a p
> -Original Message-
> From: Dave CROCKER [mailto:d...@dcrocker.net]
> Sent: Wednesday, April 27, 2011 12:58 PM
> To: Murray S. Kucherawy
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Output summary
>
>
> On 4/27/2011 12:46 PM, Murray S. Kucherawy wrote:
> >>> 4.9. Output Requir
> 4.9. Output Requirements
>
> The output of the verifier MUST embody:
>>
>>
>> sorry for not noticing this earlier: what does it mean for a verifier to
>> 'embody' something.
>
> As in "must be this, or something equivalent to it".
MUST include:
or
MUST contain at least:
>> We check ADSP every time we run DKIM and see the following policy
>> distribution:
>>
>> 97.98% "unknown" (including domains not explicitly publishing policy)
>> 2% "discardable"
>> 0.02% "all"
That's not surprising. Keep in mind that the design of ADSP means that
you're supposed to check mai
>> +1, and also for Murray's advice of signing A-R fields.
I still don't understand why, if you trust a signer enough to believe the
mailing list A-R headers he signs, you don't trust him enough to deliver
the mail, and, of course, why we now need to remotely verify contributor
addresses when w
On 04/27/2011 12:19 PM, Barry Leiba wrote:
>
>
>
>> Complaining is easy.
>>
> Indeed so. And so let's cut the meta-discussion and not go back to
> throwing darts around. To the points:
>
> Mike's concern is valid.
>
> Murray's and Dave's notes have addressed it.
>
I don't see how
>4.9. Output Requirements
>
>The output of the verifier MUST embody:
embody --> include (if it embodied them, that arguably implies that it doesn't
include anything else)
>- A result code that indicates whether or not the signature was
>validated (PERMFAIL or TEMPFAIL as
>described i
> -Original Message-
> From: John Levine [mailto:jo...@iecc.com]
> Sent: Wednesday, April 27, 2011 2:10 PM
> To: ietf-dkim@mipassoc.org
> Cc: Murray S. Kucherawy
> Subject: Re: [ietf-dkim] Output summary
>
> Do we need to say anything about the possibility that there are multiple
> signatu
On 4/27/2011 2:11 PM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: John Levine [mailto:jo...@iecc.com]
>> Sent: Wednesday, April 27, 2011 2:10 PM
>> To: ietf-dkim@mipassoc.org
>> Cc: Murray S. Kucherawy
>> Subject: Re: [ietf-dkim] Output summary
>>
>> Do we need to say anythi
Murray S. Kucherawy wrote:
> With that in mind, I propose this as a new Section 4.9, moving
> the others down:
>
> 4.9. Output Requirements
>
> The output of the verifier MUST embody:
>
>
> - A result code that indicates whether or not the signature was
> validated (PERMFAIL or TEM
>> Do we need to say anything about the possibility that there are multiple
>> signatures?
>
> How about "For each signature not ignored by the verifier" or such.
Section 5.3 says:
Verifiers SHOULD ignore failed signatures as though they were not
present in the message.
and Section 7 say
> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Wednesday, April 27, 2011 2:27 PM
> To: Murray S. Kucherawy
> Cc: ietf-dkim@mipassoc.org
> Subject: RE: [ietf-dkim] Output summary
>
> If you believe that, the output should only include signatures that
> verified,
> Exception: I am aware that Charles and Doug want the issue re-opened.
> Anyone else who wants to see it re-opened and discussed again may post
> a message to this thread that says "Consensus needs to be
> re-evaluated." I will reconsider this if there's a demonstration of
> real support for me t
Hi Dave,
Yes - percentages of the total "Failed SPF" traffic, which is good and bad. A
larger number like 50% of total traffic would be more comforting, but in that
1.5% we don't see the same magnitude of high-volume sender dominance as we
otherwise would. Distinct domain breakdown is among the
> As for TEMPFAIL, you'd have to know which signature(s) were temp-failed in
> order to decide about a later retry, which then leans us back toward giving
> the whole list of signatures that were present and a status for each.
I wouldn't be opposed to doing so, except that 4871 says in two separ
> -Original Message-
> From: MH Michael Hammer (5304) [mailto:mham...@ag.com]
> Sent: Wednesday, April 27, 2011 11:57 AM
> To: Paul Midgen; Scott Kitterman; ietf-dkim@mipassoc.org
> Subject: RE: [ietf-dkim] ADSP stats
>
> The 2% "discardable" is interesting. Is that percentage of volume
On 4/27/11 11:39 PM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: John R. Levine [mailto:jo...@iecc.com]
>> Sent: Wednesday, April 27, 2011 2:27 PM
>> To: Murray S. Kucherawy
>> Cc: ietf-dkim@mipassoc.org
>> Subject: RE: [ietf-dkim] Output summary
>>
>> If you believe that, the
> -Original Message-
> From: Hector Santos [mailto:hsan...@isdg.net]
> Sent: Wednesday, April 27, 2011 1:02 PM
> To: Paul Midgen
> Cc: Scott Kitterman; ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] ADSP stats
>
> And it should not need to be. Is Live.com included?
>
For the purpo
Barry,
Ticket #17 was listed as a duplicate of Ticket #4
http://trac.tools.ietf.org/wg/dkim/trac/ticket/17
This is not correct!
The result of Ticket #4 was a change that simply said:
,---
Internationalized domain names MUST be converted as described in Section
2.3 of [RFC5890] to "A-Labels"
'--
Sorry for the repeated message, but the wrong subject line was used.
Barry,
Ticket #17 was listed as a duplicate of Ticket #4
http://trac.tools.ietf.org/wg/dkim/trac/ticket/17
This is not correct!
The result of Ticket #4 was a change that simply said:
,---
Internationalized domain names MUST be
> Internationalized domain names MUST be converted as described in Section
> 2.3 of [RFC5890] to "A-Labels"
> '---
>
> This failed to specify Fake A-Labels should not be permitted. The point
> made by Ticket #17. RFC5980 introduces restrictions against 3,329
> confusable unicode points not exclud
Murray S. Kucherawy wrote:
>> -Original Message-
>> From: John R. Levine [mailto:jo...@iecc.com]
>>
>> If you believe that, the output should only include signatures that
>> verified, right? So you aren't suppsed to report TEMPFAIL or PERMFAIL.
>> Except that if it TEMPFAILed, the output
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of John R. Levine
> Sent: Wednesday, April 27, 2011 6:33 PM
> To: Murray S. Kucherawy
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Output summary
>
> > As for TEMPF
On 4/27/2011 8:56 PM, MH Michael Hammer (5304) wrote:
>> a) If at least one signature verifies, report success with the d= value(s)
>> of the valid signature(s) and optionally other stuff.
>
> I'm not comfortable with this statement. If I have two signatures, one from
> the domain in the From and
>> a) If at least one signature verifies, report success with the d=
>> value(s) of the valid signature(s) and optionally other stuff.
>
> I'm not comfortable with this statement. If I have two signatures, one
> from the domain in the From and one from a random 3rd party and the From
> domain signa
> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Wednesday, April 27, 2011 3:33 PM
> To: Murray S. Kucherawy
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Output summary
>
> I wouldn't be opposed to doing so, except that 4871 says in two separate
> plac
I've posted revisions of the two drafts again to close out those items that
were minor or non-controversial, or had achieved consensus. You can use the
"History" tabs at their respective datatracker links to see the diffs:
http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/
http://datat
61 matches
Mail list logo
