Rolf E. Sonneveld wrote:
b) If an application is presented two different From: fields and handed them
to DKIM, and the signature passes, the bottom one is the one that was
signed. We verify from the bottom up specifically to deal with the case
where a message has m signed instances but n
On Thu, 28 Apr 2011 20:00:33 +0100, Rolf E. Sonneveld
r.e.sonnev...@sonnection.nl wrote:
On 4/28/11 7:38 PM, Murray S. Kucherawy wrote:
Thus it is with DKIM. DKIM sits on top of RFC5322 and related message
format specs, which in turn sit on top of SMTP, which sits on top of
TCP, which
On Thu, 28 Apr 2011 18:52:19 +0100, John R. Levine jo...@iecc.com wrote:
Last paragraph of sec 5.2: Verifiers SHOULD ignore failed signatures as
though they were not present in the message.
Actually, that does not seem quite right. It is assessors who should do
that. Verifiers are
I think the rev8 version of section 6.5 is much better, but I have a
change proposal with the background reasoning listed below it:
o proposed change:
--
The basic rule for choosing fields to include is to select those
fields that constitute the core of
Overall, I believe a MLM SHOULD always hash headers it adds or
changes. Some additional headers often common with MLM are:
Precedence:
Errors-to:
What is the reasoning not to include these in the MLM core headers listed?
I have read somewhere some ESP/ISP receivers (YAHOO?) use
On Friday, April 29, 2011 09:22:15 AM Hector Santos wrote:
I think the rev8 version of section 6.5 is much better, but I have a
change proposal with the background reasoning listed below it:
...
I've had no time recently, so I've been attempting to avoid looking at last
call messages since I
Charles Lindsey wrote:
On Thu, 28 Apr 2011 18:52:19 +0100, John R. Levine jo...@iecc.com wrote:
Last paragraph of sec 5.2: Verifiers SHOULD ignore failed signatures as
though they were not present in the message.
Actually, that does not seem quite right. It is assessors who should do
Scott Kitterman wrote:
Looking at 6.5, and then looking back at 6.4 (Determine the Header Fields to
Sign), it seems to me that the INFORMATIVE OPERATIONS NOTE in 6.4 attempts
to describe the considerations that are normatively described in 6.5. It's
redundant and ought to be deleted.
Here's a more comprehensive proposal for an output summary (excuse the diff
output):
+4.9. Output Requirements
+
+ For each signature that verifies successfully or produces a TEMPFAIL
+ result, the output of a DKIM verifier module MUST include the set of:
+
+ o The domain name, taken
Recommend adding the following paragraph (excuse the XML markup):
t There are tradeoffs in the decision of what constitutes
the core of the message, which for some fields is a
subjective concept. Including fields such as Message-ID
for example is useful if one considers a mechanism for
being
Two quick reactions about the first part of the ticket:
1. This is just a variant of the basic hole created by use of l=
2. The premise that having the l= go to a multipart boundary somehow
increases security is simply wrong. More generally, the idea that one or
another tidbit might
On 29/Apr/11 19:56, Dave CROCKER wrote:
As for the second part, with or without Content-Type, messing with the
message
in any interesting way will break the signature.
I'm not sure what you mean by second part and interesting way.
The change to that security consideration section was meant
On 29/Apr/11 19:39, Murray S. Kucherawy wrote:
Here’s a more comprehensive proposal for an output summary (excuse the
“diff” output):
+4.9. Output Requirements
+
+ For each signature that verifies successfully or produces a TEMPFAIL
+ result, the output of a DKIM verifier module MUST
1. This is just a variant of the basic hole created by use of l=
2. The premise that having the l= go to a multipart boundary somehow
increases security is simply wrong. More generally, the idea that one or
another tidbit might tighten things a bit, l= opens such a huge door, the
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Friday, April 29, 2011 12:03 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Output requirements
How about mentioning ignored signatures,
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy
Sent: Friday, April 29, 2011 3:18 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Output requirements
-Original Message-
From:
On Fri, 29 Apr 2011, Murray S. Kucherawy wrote:
On further consideration, I'm with Dave. Suggest removing the current
language about l= and MIME boundaries, and replace with a note that if you
use l=, added content can change the appearance of a message in hard to
anticipate ways.
Replace
On Apr 29, 2011, at 12:18 PM, Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Friday, April 29, 2011 12:03 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Output
On Apr 29, 2011, at 12:32 PM, John R. Levine wrote:
On Fri, 29 Apr 2011, Murray S. Kucherawy wrote:
On further consideration, I'm with Dave. Suggest removing the current
language about l= and MIME boundaries, and replace with a note that if you
use l=, added content can change the
On 4/29/11 12:48 AM, Murray S. Kucherawy wrote:
-Original Message-
From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl]
Sent: Thursday, April 28, 2011 2:12 PM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Output summary
b) If an application is
On 4/29/2011 10:56 AM, Murray S. Kucherawy wrote:
Recommend adding the following paragraph (excuse the XML markup):
+1
the text is modest and meaningful. it highlights things without belaboring
them.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Murray S. Kucherawy wrote:
Recommend adding the following paragraph (excuse the XML markup):
t There are tradeoffs in the decision of what constitutes
the core of the message, which for some fields is a
subjective concept. Including fields such as Message-ID
for example is useful if one
My preference would be Message-Id SHOULD be part of the top core
listing and if wish to add text to explain use cases when/why it
should|may not considered be hashing, that would be make more DKIM
engineering sense to me.
It should be the exception and not the rule to not consider a
Michael Thomas wrote:
Rolf E. Sonneveld wrote:
Don't get me wrong, I just wanted to demonstrate that, IF we follow the
logic of not crossing protocol boundaries strictly, THEN communicating
the d= payload /without additional information/, we
* either enforce upper layers to violate
Actually I interpret the message you cited as supporting the current effort to
declare that the required output is d= plus success/TEMPFAIL, while also very
clearly stating that a DKIM verification module is certainly within its rights
to provide more than that.
Indeed, OpenDKIM makes a ton of
-Original Message-
From: Michael Thomas [mailto:m...@mtcc.com]
Sent: Friday, April 29, 2011 4:37 PM
To: Rolf E. Sonneveld
Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Output summary
Indeed, the chickens have come to roost. This was ill-conceived at the
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Hector Santos
Sent: Friday, April 29, 2011 6:16 PM
To: Michael Thomas
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Output summary
What gets me is that I thought
Dave CROCKER wrote:
Two quick reactions about the first part of the ticket:
1. This is just a variant of the basic hole created by use of l=
2. The premise that having the l= go to a multipart boundary
somehow increases security is simply wrong. More generally,
the idea
It is indeed an effort based, at least in part, on clarifying stuff
we learned since the earlier version based on experience. I think
it's pretty clear that's what's being done. Dropping g= is a prime
example.
We've hardly changed the parts that describe how to create and verify
the signature
29 matches
Mail list logo
