On 10/6/2010 1:57 PM, MH Michael Hammer (5304) wrote:
>
> Apologies all for top posting. Having to use a different client due to
> technical difficulties.
>
> Murray, I'm violently agreeing with you that it is not strictly
> speaking a 4871 issue.
>
> Having said that, I believe that it is an iss
> "Dave CROCKER" wrote:
>> In particular, it makes the multiple From: issue entirely
>> irrelevant to DKIM.
Scott Kitterman wrote:
> In a normative sense, perhaps, but in real world terms, it doesn't.
> Since this does away with "It's not valid 5322, so it can't
> be valid DKIM", it puts the
On Oct 6, 2010, at 3:01 PM, Scott Kitterman wrote:
>
>
> "Dave CROCKER" wrote:
>
>>
>>
>> On 10/6/2010 8:00 AM, Steve Atkins wrote:
>>> It also changes what DKIM means,
>> ...
>>> Either the message has a valid DKIM signature, or it does not. If the
>>> signature is valid, then the signing
"Dave CROCKER" wrote:
>
>
>On 10/6/2010 8:00 AM, Steve Atkins wrote:
>> It also changes what DKIM means,
>...
>> Either the message has a valid DKIM signature, or it does not. If the
>> signature is valid, then the signing domain takes responsibility for the
>> message, subtly malformed or not.
Charles Lindsey wrote:
> On Mon, 04 Oct 2010 23:24:11 +0100, President Obama
> wrote:
>
>>THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE
>
> Interestingly, my MUA (Opera) displayed both of those From headers, But I
> can quite well understand that many other MUAs don't, and even wh
On Oct 6, 2010, at 1:22 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
>> On Behalf Of Mark Delany
>> Sent: Tuesday, October 05, 2010 8:06 PM
>> To: ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] THI
The diffs at http://dkim.org/specs/rfc4871-to-bis-diff.htm and the
differences between 4871 and the -00 version of the draft, not the Last
Call revision.
Dave Crocker, can you update the diffs please?
-Jim
On 10/4/10 5:53 AM, Barry Leiba wrote:
> Thus begins working group last call on the DK
On Oct 5, 2010, at 4:45 PM, Michael Thomas wrote:
> On 10/05/2010 01:36 PM, John Levine wrote:
>>> Still, though, it's a solution to deal with malformations to which
>>> MUAs are susceptible, and not strictly a DKIM problem.
>>
>> Would it be a good idea to recommend in 4871bis that DKIM
>> imple
Apologies all for top posting. Having to use a different client due to
technical difficulties.
Murray, I'm violently agreeing with you that it is not strictly speaking a 4871
issue.
Having said that, I believe that it is an issue that begs the question... where
should it land? You are correc
On Wed, Oct 6, 2010 at 9:15 AM, Dave CROCKER wrote:
>
>
> On 10/6/2010 8:00 AM, Steve Atkins wrote:
>> It also changes what DKIM means,
> ...
>> Either the message has a valid DKIM signature, or it does not. If the
>> signature is valid, then the signing domain takes responsibility for the
>> mess
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Dave CROCKER
> Sent: Wednesday, October 06, 2010 7:02 AM
> To: John R. Levine
> Cc: DKIM List
> Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
>
> I find the s
On 10/6/2010 9:17 AM, John R. Levine wrote:
> Is it DKIM's job to make the verification fail, or is it an MUA's job to do
> something reasonable with malformed messages?
At one level, that's merely an implementation choice. At another level, it is
a
question of whether conformance enforcement
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of John R. Levine
> Sent: Wednesday, October 06, 2010 6:17 AM
> To: Steve Atkins
> Cc: DKIM List
> Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
>
> Recall that
> I don't think that's a fair characterization. It is simply wrong to try to
> deal this problem in DKIM. For example, a bug in the TCP stack that causes
> malformed data to arrive in an application which in turn causes something
> visible and unexpected, possibly even something dangerous, to
> -Original Message-
> From: Dave CROCKER [mailto:d...@dcrocker.net]
> Sent: Wednesday, October 06, 2010 6:12 AM
> To: Murray S. Kucherawy
> Cc: DKIM
> Subject: Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-
> mailinglists-03
>
> I suggest saying "the holder of the message i
Either the message has a valid DKIM signature, or it does not.
If the signature is valid, then the signing domain takes responsibility
for the message, subtly malformed or not. Just because the message
lacks a Date: header or has bare linefeeds doesn't mean that the
signing domain isn't responsibl
On 10/6/2010 8:00 AM, Steve Atkins wrote:
> It also changes what DKIM means,
...
> Either the message has a valid DKIM signature, or it does not. If the
> signature is valid, then the signing domain takes responsibility for the
> message, subtly malformed or not. Just because the message lacks a
On 10/6/2010 8:23 AM, Murray S. Kucherawy wrote:
>> Of the points I raised, I see that 4.3 still contains "the verifier is
>> requested to discard the message". It is, of course, the receiver that
>> actually does any discarding.
>
> I don't agree, at least not in the architecture I have in mind.
On Oct 6, 2010, at 1:47 AM, Mark Delany wrote:
>>> That this is not in 4871 seems to be mostly a WG assumption that
>>> should be made explicit.
>>
>> I think several of us thought it was in there, but on review it apparently
>> was indeed lost somewhere along the way. We've certainly, as I un
Mark Delany:
> > > That this is not in 4871 seems to be mostly a WG assumption that
> > > should be made explicit.
> >
> > I think several of us thought it was in there, but on review it apparently
> > was indeed lost somewhere along the way. We've certainly, as I understand
> > it, been procee
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Charles Lindsey
> Sent: Wednesday, October 06, 2010 3:47 AM
> To: DKIM
> Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple
> 5322.From
>
> And note
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Charles Lindsey
> Sent: Wednesday, October 06, 2010 4:36 AM
> To: DKIM
> Subject: Re: [ietf-dkim] New Version Notification for
> draft-ietf-dkim-mailinglists-03
>
> Of the p
On 06/Oct/10 01:59, Julian Mehnle wrote:
> As I've written in my previous mail I think there's a better way to solve
> this (non-)issue. Just s/Comments/From/ in that INFORMATIVE NOTE on page
> 41 of 4871bis-01.
+1, I quote the resulting text
INFORMATIVE NOTE: A header field name need only
> -Original Message-
> From: MH Michael Hammer (5304) [mailto:mham...@ag.com]
> Sent: Wednesday, October 06, 2010 12:20 AM
> To: Murray S. Kucherawy; ietf-dkim@mipassoc.org
> Subject: RE: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
>
> So, my belief is that this is really more of a 53
On Mon, 04 Oct 2010 22:16:48 +0100, Murray S. Kucherawy
wrote:
> This version consolidates all of the minor corrections submitted to
> date, as well as the more substantive things that appeared to have
> consensus.
Of the points I raised, I see that 4.3 still contains "the verifier is
On Mon, 04 Oct 2010 23:24:11 +0100, Hector Santos wrote:
> I propose the following addition text by adding to 48721bis to address
> this serious issue;
>
>Special Consideration for Verifying and Signing From: Header
>
>As an exception, header hash verification MUST be done for all
>53
On Mon, 04 Oct 2010 23:24:11 +0100, President Obama
wrote:
>THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE
Interestingly, my MUA (Opera) displayed both of those From headers, But I
can quite well understand that many other MUAs don't, and even where they
do I would expect many ph
At 05:53 04-10-10, Barry Leiba wrote:
>Thus begins working group last call on the DKIM-base update,
>draft-ietf-dkim-rfc4871bis-01:
The document should obsolete both RFC 4871 and RFC 5672.
Please update the RFC 2821 and RFC 2822 references to RFC 5321 and
RFC 5322 respectively.
The reference fo
I've cogitated on this a bit and spoken with a few knowledgeable people.
I'm an operations guy and only marginally a standards wonk.
So, my belief is that this is really more of a 5322 issue than a 4871
issue. Having said that, I'm not comfortable kicking the can down the
road given that what we k
29 matches
Mail list logo
