Hi JD,
At 12:24 14-10-10, J.D. Falk wrote:
>We've done a surprisingly good job of getting the word out that DK
>is over and DKIM is the future.
We're doing a heck of a job. :-)
There is still some confusion between DomainKeys and DKIM. I still
see people signing with DomainKeys. You can pick
On 10/14/2010 6:30 PM, John R. Levine wrote:
> I wouldn't be opposed to moving it to an appendix of deprecated features,
> if for nothing else to ensure that some future DKIM++ doesn't
> inadvertently reuse g= to mean something else.
>
> Since this particular feature is apparently used in about .00
This is a small 2 days collection break down of the signed mail coming in:
- total msgs :67028
- dkim_sign : 1779 (2.7% signed)
- dkim_pass : 89.9%
- dkim_fail : 10.1%
--25.9% : dkim_body_hash_mismatch
--14.0% : dkim_signature_bad
--37.6% : dkim_signat
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Steve Atkins
> Sent: Thursday, October 14, 2010 5:00 PM
> To: DKIM List
> Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
>
> http://www.iana.org/assig
On Oct 14, 2010, at 4:44 PM, John R. Levine wrote:
>>> if for nothing else to ensure that some future DKIM++ doesn't
>>> inadvertently reuse g= to mean something else.
>>
>> Isn't that what the IANA registry is there to prevent?
>
> I dunno. What does IANA do in cases like these?
http://www.i
>> if for nothing else to ensure that some future DKIM++ doesn't
>> inadvertently reuse g= to mean something else.
>
> Isn't that what the IANA registry is there to prevent?
I dunno. What does IANA do in cases like these?
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet
On 10/14/10 3:30 PM, John R. Levine wrote:
>> No, that doesn't solve the problem for all of the implementations
>> that are out there now that implement 4871. Removing g= is only going
>> to make the situation even worse because you've now taken away the
>> documentation.
> I wouldn't be opposed
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of John R. Levine
> Sent: Thursday, October 14, 2010 3:31 PM
> To: Barry Leiba
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
>
> >
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Dave CROCKER
> Sent: Thursday, October 14, 2010 3:33 PM
> To: Tony Hansen
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
>
> Alth
On 10/14/2010 6:01 PM, Tony Hansen wrote:
> If we remove g= altogether, then we can remove 3.6.1.1*along* with all
> the other references to g= within the document.
This double removal appears to produce the simplest acceptable result.
I believe we have not seen significant objection to eithe
> No, that doesn't solve the problem for all of the implementations
> that are out there now that implement 4871. Removing g= is only going
> to make the situation even worse because you've now taken away the
> documentation.
I wouldn't be opposed to moving it to an appendix of deprecated features
>> Well, now we're back to my question to Dave, what's the advantage of
>> leaving that as folklore rather than putting it in the spec other than the
>> warm theological feeling of somewhat preserving layer distinctions, except
>> for all the places we already didn't?
>
> Why does it have to be nor
Barry, there are crossing questions.
This question came up in response to removing 3.6.1.1 totally separate
from the question of removing g= altogether.
If we remove 3.6.1.1 without removing g= altogether, the question below
becomes pertinent.
If we remove g= altogether, then we can remove 3.6
On Oct 13, 2010, at 1:59 PM, Mark Delany wrote:
> On Wed, Oct 13, 2010 at 04:09:34PM -0400, MH Michael Hammer (5304) allegedly
> wrote:
>
>> Having said that, if an MUA is going to present an indication of
>> "DKIM PASS" to the enduser, then a reasonable person would expect
>> some relationship
On Oct 14, 2010, at 5:09 AM, Dave CROCKER wrote:
> On 10/13/2010 1:52 PM, Jim Fenton wrote:
>> I propose removing section 3.6.1.1 in its entirety.
>
> Not only do I support this, but I think we can remove all references to
> DomainKeys, except for the obvious historical reference to its role as
Barry Leiba wrote:
> On Thu, Oct 14, 2010 at 12:45 AM, SM wrote:
>> At 17:31 13-10-10, Hector Santos wrote:
>>> My proposal to add more informative notes to help minimize this for
>>> the systems with the lack of DNS admin expertise on board. In
>>> particular for those with currently one existing
Scott Kitterman wrote:
> +1.
>
> Just as a note of clarification, SPF doesn't prefix TXT records, but I don't
> think that affects the analysis.
The Network Solutions DNS Records manager does not allow you to add a
TXT record without a sub-domain, so to add one, you have to add *
which when sa
Barry Leiba wrote:
> On Thu, Oct 14, 2010 at 12:45 AM, SM wrote:
>> At 17:31 13-10-10, Hector Santos wrote:
>>> My proposal to add more informative notes to help minimize this for
>>> the systems with the lack of DNS admin expertise on board. In
>>> particular for those with currently one existing
"Barry Leiba" wrote:
>On Thu, Oct 14, 2010 at 12:45 AM, SM wrote:
>> At 17:31 13-10-10, Hector Santos wrote:
>>>My proposal to add more informative notes to help minimize this for
>>>the systems with the lack of DNS admin expertise on board. In
>>>particular for those with currently one existin
On 10/14/2010 11:54 AM, Barry Leiba wrote:
> On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen wrote:
>> Even though I supported the addition of wording on how to improve the
>> compatibility with DomainKeys records, I would support removing the new
>> proposed section 3.6.1.1 for the reasons Dave brin
On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen wrote:
> Even though I supported the addition of wording on how to improve the
> compatibility with DomainKeys records, I would support removing the new
> proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to
> ask the question: Is it
On Thu, Oct 14, 2010 at 12:45 AM, SM wrote:
> At 17:31 13-10-10, Hector Santos wrote:
>>My proposal to add more informative notes to help minimize this for
>>the systems with the lack of DNS admin expertise on board. In
>>particular for those with currently one existing need for a TXT record
>>and
+1 on removing "g=".
Barry, as participant
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
>> 6.1.1 Validate the Message Syntax
>>
>> The verifier SHOULD meticulously validate the format of the message
>> being verified against the requirements specified in [RFC5322],
>> [RFC2045], and [RFC2047]. In particular, limitations on the number of
>> occurrences of particular header fields spec
>>> 3) Philosophical conflictive parenthetical sentence:
>>> >
>>> > (This can also be taken as a demonstration that DKIM is not designed
>>> > to support author validation.)
>> Yeh, that's the only part I agree on (though not with the reasoning
>> that follows). I'm ambivalent about hav
Alessandro Vesely wrote:
>
> Correct. And the way that it fails to verify is h=from:from.
>
> The only way that DKIM can consistently account for this exploit is by
> amending section 5.5 "Recommended Signature Content", and spell what
> fields MUST/SHOULD be duplicated in the h= tag.
-0.5.
On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote:
> On 13/Oct/10 20:45, Scott Kitterman wrote:
> > On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
> >> If we can extract DKIM from the equation entirely and the problem remains,
> >> how is it a DKIM
On 10/14/2010 10:47 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: John R. Levine [mailto:jo...@iecc.com]
>> Sent: Thursday, October 14, 2010 10:45 AM
>> To: Murray S. Kucherawy
>> Cc: DKIM List
>> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
>>
> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Thursday, October 14, 2010 10:50 AM
> To: Murray S. Kucherawy
> Cc: DKIM List
> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
> after signing
>
> Well, now we're back to my question to
On 13/Oct/10 20:45, Scott Kitterman wrote:
> On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
>> If we can extract DKIM from the equation entirely and the problem remains,
>> how is it a DKIM problem?
>
> If the DKIM signature doesn't verify after signed headers have been alt
> Not only do I want that, I did that. But the DKIM/ADSP module of that
> system is purely DKIM/ADSP. The module that sits between the MTA and
> the DKIM/ADSP module does the header count enforcement we're talking about,
> knowing there's the potential for invalid mush in there.
Well, now we'
> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Thursday, October 14, 2010 10:45 AM
> To: Murray S. Kucherawy
> Cc: DKIM List
> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
> after signing
>
> > I think if it becomes well-known that
On 10/14/10 6:30 AM, Dave CROCKER wrote:
>
> On 10/14/2010 9:05 AM, Tony Hansen wrote:
>> Is it still worth changing that section into a WARNING
>> for people upgrading from DomainKeys, saying to make darn sure that they
>> REMOVE g=; in their old DNS records because of interoperability issue
> That makes it invalid input to any module that requires input to comply with
> RFC5322, pure and simple.
Well, OK, with the stipulation that no existing MUA I have ever seen is
such a module.
> I think if it becomes well-known that users of MUA 1 are easier to phish
than users of MUA 2, a lo
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of John R. Levine
> Sent: Thursday, October 14, 2010 10:15 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
> after signing
>
> Am
On 12/Oct/10 17:47, Barry Leiba wrote:
>> 3) Philosophical conflictive parenthetical sentence:
>> >
>> > (This can also be taken as a demonstration that DKIM is not designed
>> > to support author validation.)
> Yeh, that's the only part I agree on (though not with the reasoning
> that fo
On 10/14/2010 10:15 AM, John R. Levine wrote:
>> If you really think this is such a great big problem, maybe you should be
>> banging the drums at MAAWG or other venues where the correct set of ears
>> is potentially listening.
>
> I would rather not have to run a session at MAAWG entitled "How to
On 14/Oct/10 00:22, Jim Fenton wrote:
> Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.):
>
> 6.1.1 Validate the Message Syntax
>
> The verifier SHOULD meticulously validate the format of the message
> being verified against the requirements specified in [RFC5322],
> [RFC2045], and
> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Thursday, October 14, 2010 10:07 AM
> To: Murray S. Kucherawy
> Cc: DKIM List
> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
> after signing
>
> > Adding a second From: makes the messa
> If you really think this is such a great big problem, maybe you should be
> banging the drums at MAAWG or other venues where the correct set of ears
> is potentially listening.
I would rather not have to run a session at MAAWG entitled "How to fix the
security holes in DKIM", but I certainly co
> The difference is that the Subject:, To: and l= advice don't dabble in the
> area of having to tell a DKIM implementer to enforce parts of other protocols.
>
> Adding a second From: makes the message format illegal. The other ones don't.
We're still talking past each other. You're right, it m
On 10/14/2010 09:45 AM, John R. Levine wrote:
>> Unless there's *really* something they can't figure out without protocol
>> help, I'm not sure what the point of this is. This double added From thing
>> is trivial to detect with the current spec.
>
> Well, yeah. That's why I don't understand why p
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of John R. Levine
> Sent: Thursday, October 14, 2010 7:59 AM
> To: dcroc...@bbiw.net
> Cc: DKIM List
> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
> Unless there's *really* something they can't figure out without protocol
> help, I'm not sure what the point of this is. This double added From thing
> is trivial to detect with the current spec.
Well, yeah. That's why I don't understand why people are so opposed to a
SHOULD saying they should
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Mark Delany
> Sent: Thursday, October 14, 2010 7:38 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
> after signin
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Charles Lindsey
> Sent: Thursday, October 14, 2010 7:32 AM
> To: DKIM
> Subject: Re: [ietf-dkim] detecting header mutations after signing
>
> > This is true if the message is
On 10/14/2010 07:56 AM, Mark Delany wrote:
> On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote:
>>> What is essential is that it perform the task of validating and delivering a
>>> signing domain that is associated with a collection of bits. Anything that
>>> defines how to do
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Dave CROCKER
> Sent: Thursday, October 14, 2010 5:23 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
>
> On 10/14/2
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Dave CROCKER
> Sent: Thursday, October 14, 2010 5:10 AM
> To: IETF DKIM WG
> Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
>
> On 10/13/2010 1:52 PM,
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Dave CROCKER
> Sent: Thursday, October 14, 2010 5:08 AM
> To: IETF DKIM WG
> Subject: Re: [ietf-dkim] removing the g= definition?
>
> On 10/14/2010 12:46 AM, Tony Hansen wrot
agreed
On Oct 14, 2010, at 8:09 AM, Dave CROCKER wrote:
>
>
> On 10/13/2010 1:52 PM, Jim Fenton wrote:
>> I propose removing section 3.6.1.1 in its entirety.
>
> Not only do I support this, but I think we can remove all references to
> DomainKeys, except for the obvious historical reference to
SM wrote:
> That text adds a requirement in an informative note.
>
>> My proposal to add more informative notes to help minimize this for
>> the systems with the lack of DNS admin expertise on board. In
>> particular for those with currently one existing need for a TXT record
>> and that is SPF a
On 10/14/2010 07:58 AM, John R. Levine wrote:
>> Perhaps surprisingly, having redundant header fields does not make
>> DKIM break.
>
> We must have some vastly different definition of "break".
>
> If allowing through modified messages that render very differently isn't
> broken, shouldn't we remove
Perhaps surprisingly, having redundant header fields does not make DKIM
break.
We must have some vastly different definition of "break".
If allowing through modified messages that render very differently isn't
broken, shouldn't we remove the advice against signing with l=0? The
advice in fav
On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote:
> > What is essential is that it perform the task of validating and delivering
> > a
> > signing domain that is associated with a collection of bits. Anything that
> > defines how to do this is essential. Anything that can
On Wed, 13 Oct 2010 19:27:29 +0100, Jeff Macdonald
wrote:
>> If we can extract DKIM from the equation entirely and the problem
>> remains, how is it a DKIM problem?
>
>
> I agree with this.
>
> And even if there was a DKIM signature, it is the BAD GUY'S signature,
> which should cause it to g
> What is essential is that it perform the task of validating and delivering a
> signing domain that is associated with a collection of bits. Anything that
> defines how to do this is essential. Anything that can make this break needs
> to
> be covered, especially if there are ways to protect
On Wed, 13 Oct 2010 17:54:23 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Wednesday, October 13, 2010 9:12 AM
>> To: DKIM
>> Subject: Re: [ietf-dkim] det
On 10/14/2010 10:17 AM, John R. Levine wrote:
> I don't see anyone proposing a deep dive into 5322 validation. But 4871
> already says you MUST sign the From: header. Why is that OK, but saying
> you MUST NOT sign or validate something with two From: headers is not?
> We're not suggesting anyth
On Wed, 13 Oct 2010 17:34:32 +0100, Charles Lindsey
wrote:
> But full 100% RFC5322 checking is extremely tedious, and is more that we
> actually need.
>
> What we want is more like
> CHECK DKIM && CHECK RFC5322 headers included in h= tag -->
> ACCEPT
> where at least the CHECK RFC53
> It should be perfectly fine to say DKIM expects valid input, for
> whatever definition of that we want to invent, and also state that
> handing it anything else has either undefined results or specific bad
> results.
We seem to be talking past each other here.
I don't see anyone proposing a
On 10/14/2010 9:49 AM, Mark Delany wrote:
> Well, just to create a bit more of a rat-hole, is there any chance
> you'd like to add a definitional link for the word "message" as well?
The easy and possibly sufficient answer is: RFC 5322.
If more precision is required, then Section 3.5 of RFC 5
On Thu, Oct 14, 2010 at 8:09 AM, Dave CROCKER wrote:
>
>
> On 10/13/2010 1:52 PM, Jim Fenton wrote:
>> I propose removing section 3.6.1.1 in its entirety.
>
> Not only do I support this, but I think we can remove all references to
> DomainKeys, except for the obvious historical reference to its ro
Another potential option is to remove g= entirely:
I'd like to encourage our considering this strongly, for two reasons:
I agree, g= seems to me to be a vestige of the confusion between i= and d=
identity.
If we do, it's probably a good idea to put in Tony's WARNING for people
upgrading fr
> to:
>
> title="Introduction">
>
> DomainKeys Identified Mail (DKIM) permits a person, role, or
> organization to claim some responsibility for a message by
> associating a domain name target="RFC1034" /> with the message. Th
On 10/14/2010 9:05 AM, Tony Hansen wrote:
>Is it still worth changing that section into a WARNING
> for people upgrading from DomainKeys, saying to make darn sure that they
> REMOVE g=; in their old DNS records because of interoperability issues?
>
> So the question becomes: if we remove the
I'm all for simplification of the specs (and software logic) to one
protocol and not mix in old stuff. I know that DKEYS are still in the
minds of implementations that do both, but I don't think that will be
case as we move forward with new implementations and APIs (which will
most likely be D
Even though I supported the addition of wording on how to improve the
compatibility with DomainKeys records, I would support removing the new
proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to
ask the question: Is it still worth changing that section into a WARNING
for peo
Graham Murray wrote:
> An MUA does not have to do filtering in order to support DKIM. It could
> display the Authentication Results header, or take some action
> depending
> on whether there is a valid DKIM signature - in a similar way that some
> web browsers will turn the URL bar green when the s
On 10/14/2010 12:45 AM, SM wrote:
> RFC 4871 discusses about DNS in various sections. Unfortunately,
> there is no reference to the DNS specifications.
OMG. As in, wow.
I propose changing from:
DomainKeys Identified Mail (DKIM) permits a person, role, or
organi
On 10/13/2010 1:52 PM, Jim Fenton wrote:
> I propose removing section 3.6.1.1 in its entirety.
Not only do I support this, but I think we can remove all references to
DomainKeys, except for the obvious historical reference to its role as input to
DKIM.
At the time DKIM was developed, worrying
On 10/14/2010 12:46 AM, Tony Hansen wrote:
> Another potential option is to remove g= entirely:
I'd like to encourage our considering this strongly, for two reasons:
1. Pragmatic -- It's causing confusion and errors, while providing no
significant value-add.
2. Theoretical -- The feature recr
"John R. Levine" writes:
>
> DKIM support in an MUA? Yuck.
>
> It's likely to be a long time before any MUA I use does anything with
> DKIM, since I am not a fan of filtering mail while reading it.
An MUA does not have to do filtering in order to support DKIM. It could
display the Authenticati
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of John R. Levine
> Sent: Wednesday, October 13, 2010 10:49 PM
> To: dcroc...@bbiw.net
> Cc: DKIM List
> Subject: Re: [ietf-dkim] detecting header mutations after signing
>
> >
74 matches
Mail list logo
