On 26/Oct/10 19:08, Murray S. Kucherawy wrote:
On Behalf Of Alessandro Vesely
On 26/Oct/10 06:58, Murray S. Kucherawy wrote:
a verifying module might return a syntax error code or arrange not to
return a positive result even if the signature technically validates.
-1. How does might
I will not pretend to know (nor really care) what it will take to get
over this documentation dilemma but I will provide my comments here:
Murray S. Kucherawy wrote:
8.14 Malformed Inputs
DKIM allows additional header fields to be added to a
signed message without breaking the signature.
On 26/Oct/10 06:58, Murray S. Kucherawy wrote:
a verifying module might return a syntax error code or arrange not to
return a positive result even if the signature technically validates.
-1. How does might differ from MAY?
___
NOTE WELL: This list
Alessandro Vesely wrote:
On 26/Oct/10 06:58, Murray S. Kucherawy wrote:
a verifying module might return a syntax error code or arrange not to
return a positive result even if the signature technically validates.
-1. How does might differ from MAY?
I think it creates an IETF procedural bug
On Oct 26, 2010, at 1:49 AM, Hector Santos wrote:
I will not pretend to know (nor really care) what it will take to get
over this documentation dilemma but I will provide my comments here:
Murray S. Kucherawy wrote:
8.14 Malformed Inputs
DKIM allows additional header fields to be
Steve Atkins wrote:
On Oct 26, 2010, at 1:49 AM, Hector Santos wrote:
Murray S. Kucherawy wrote:
8.14 Malformed Inputs
DKIM allows additional header fields to be added to a
signed message without breaking the signature.
This tolerance can be abused..
DKIM does not allow additional
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Tuesday, October 26, 2010 2:59 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Take two (was Re: Proposal for new text about
multiple header
On Oct 25, 2010, at 9:58 PM, Murray S. Kucherawy wrote:
8.14 Malformed Inputs
DKIM allows additional header fields to be added to a signed message without
breaking the signature. This tolerance can be abused, e.g. in a replay
attack, by adding additional instances of header fields that
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Tuesday, October 26, 2010 3:38 PM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Take two (was Re: Proposal for new text about
multiple header issues)
+0.999
My only niggle
+0.999
My only niggle is where you say dissallowed by section 3.6 of [MAIL],
you might want to add a reference to the RFC 2045 which defines the MIME
headers.
OK.
You might also want to mention RFC 4021 which is a laundry list of every
known message header.
What about referring to the
8.14 Malformed Inputs
DKIM allows additional header fields to be added to a signed message without
breaking the signature. This tolerance can be abused, e.g. in a replay attack,
by adding additional instances of header fields that are displayed to the end
user or used as filtering input,
11 matches
Mail list logo
