On Thu, 07 Jul 2011 18:09:14 +0100, Pete Resnick presn...@qualcomm.com
wrote:
I am perfectly happy with Murray's original (and now, revised) text.
(Nits still being discussed are entirely up to the WG.) I am not happy
with Charles's text. Particularly:
On 7/7/11 5:08 AM, Charles Lindsey
On Thu, 07 Jul 2011 22:06:29 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
My favourite counterexample, which I've used many times already, is
Mailman. It doesn't even check DKIM signatures, but you can still fake
your way through its authorization process such that a different
On 07/Jul/11 16:13, Dave CROCKER wrote:
On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote:
I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise
Postel's statement, do we?)
You're either liberal in your application of the RFCs, or you're not. I
don't see how adding that word
-Original Message-
From: John Levine [mailto:jo...@iecc.com]
Sent: Thursday, July 07, 2011 6:22 PM
Will your assume one more From than listed in h= lead to failed
verifications on messages that actually follow the advice in the RFC to
list duplicate headers in their h= values?
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Friday, July 08, 2011 3:59 AM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
My favourite counterexample, which
On 7/8/2011 6:48 AM, Murray S. Kucherawy wrote:
If DKIM is not intended to give added credance to messages, then what on
earth is its purpose at all.
That question is answered numerous times in the draft, namely the Abstract
and Sections 1, 1.2, 1.5, 2.5, 2.7, 3.9, 3.11, 6.3, and 8.15 (and
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Friday, July 08, 2011 3:52 AM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
1. The fact that DKIM choose headers
I'm not seeing much agreement on any changes to Murray's final draft, so
may I suggest that it's good enough and we should ship it? The potential
benefit of the proposed changes doesn't impress me as worth the amount of
argument they're provoking.
Regards,
John Levine, jo...@iecc.com, Primary
On 7/8/2011 6:54 AM, Murray S. Kucherawy wrote:
That's not part of what DKIM tells an assessor, nor is the list of signed
header fields, so I don't see why that would be a useful thing to highlight.
For example, if a message contains two Subject: fields, the assessor doesn't
know which
On Jul 8, 2011, at 7:05 AM, John R. Levine wrote:
I'm not seeing much agreement on any changes to Murray's final draft, so
may I suggest that it's good enough and we should ship it? The potential
benefit of the proposed changes doesn't impress me as worth the amount of
argument they're
On Fri, 08 Jul 2011 13:05:49 +0100, McDowell, Brett
bmcdow...@paypal-inc.com wrote:
John, this particular part of the discussion is not about changing the
RFC or DKIM implementations, only changing deployment configuration
practices.
Exactly so. All I am trying to do is to ensure that
On Fri, 08 Jul 2011 14:54:43 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
-Original Message-
[mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
Sent: Friday, July 08, 2011 3:52 AM
1. The fact that DKIM choose headers to sign from the bottom up (for
good
Charles Lindsey wrote:
I think is is clear that these attacks will work if deployers fail to
watch out for them. The only question is how long it will take the Bad
Guys to spot the opportunities (and for sure they WILL spot them - sooner
probably than later).
+1
To me, the protocol
I want to try to be precise, which I don't think Charles is being with
his below two sets of facts. Let me try to clarify:
On 7/8/11 5:52 AM, Charles Lindsey wrote:
1. The fact that DKIM choose headers to sign from the bottom up (for good
reason) facilitates certain attacks (not against DKIM,
14 matches
Mail list logo
