On 01.05.2011 14:13, John R. Levine wrote:
I don't think we actually understand all the ways that l= allows you to
shoot yourself in the foot, so I would prefer not to give the impression
that if people avoid a few cases we describe, they're safe.
-1, I agree we don't know all the ways DKIM
I don't think we yet have consensus to take out l= but it is quite clear
that the problems it causes are far greater than whatever problems it
might solve.
As Hector notes, it is required by non-DKIM aware MLMs.
To aim one more kick at the greasy spot on the floor where the horse used
to
On May 1, 2011, at 10:15 AM, Dave CROCKER wrote:
On 4/30/2011 11:43 PM, Murray S. Kucherawy wrote:
I'd like to leave in MIME and HTML exploits as examples if people agree that
wouldn't be harmful, such as this updated text in 4.4.5:
tINFORMATIVE IMPLEMENTATION NOTE:
John R. Levine wrote:
What's your counter-proposal to Alessandro's proposal to modify 9.1.1?
Oh, that. Replace all of sec 9.1 with:
As noted in Section 4.4.5, use of the l= tag enables a variety of
attacks in which added content can partially or completely changes the
recipient's
On 01/May/11 06:18, John R. Levine wrote:
What's your counter-proposal to Alessandro's proposal to modify 9.1.1?
Oh, that. Replace all of sec 9.1 with:
As noted in Section 4.4.5, use of the l= tag enables a variety of
attacks in which added content can partially or completely changes
I don't think we actually understand all the ways that l= allows you to
shoot yourself in the foot, so I would prefer not to give the impression
that if people avoid a few cases we describe, they're safe.
-1, I agree we don't know all the ways DKIM can be fooled. Neither we
actually saw
On 4/30/2011 11:43 PM, Murray S. Kucherawy wrote:
I'd like to leave in MIME and HTML exploits as examples if people agree that
wouldn't be harmful, such as this updated text in 4.4.5:
tINFORMATIVE IMPLEMENTATION NOTE: Using body length
limits
Alessandro Vesely wrote:
On 01/May/11 06:18, John R. Levine wrote:
What's your counter-proposal to Alessandro's proposal to modify 9.1.1?
Oh, that. Replace all of sec 9.1 with:
As noted in Section 4.4.5, use of the l= tag enables a variety of
attacks in which added content can partially
Is this new text for section 9.1 Misuse of Body Length Limits (l= Tag)?
Murray S. Kucherawy wrote:
INFORMATIVE IMPLEMENTATION NOTE: Using body length
limits enables an attack in which an attacker modifies a
message to include content that solely benefits the
attacker. It is
What's your counter-proposal to Alessandro's proposal to modify 9.1.1?
Oh, that. Replace all of sec 9.1 with:
As noted in Section 4.4.5, use of the l= tag enables a variety of
attacks in which added content can partially or completely changes the
recipient's view of the message.
I don't
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
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
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: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
15 matches
Mail list logo
