--On 14 October 2010 09:27:35 -0700 Michael Thomas wrote:
> Unless there's *really* something they can't figure out without protocol
> help, I'm not sure what the point of this is. This double added From thing
> is trivial to detect with the current spec.
Well, it took us a few years to spot t
--On 14 October 2010 10:23:21 -0700 Michael Thomas wrote:
> On 10/14/2010 10:15 AM, John R. Levine wrote:
>>> If you really think this is such a great big problem, maybe you should
>>> be banging the drums at MAAWG or other venues where the correct set of
>>> ears is potentially listening.
>>
>
On 14/Oct/10 20:40, Barry Leiba wrote:
>>> 6.1.1 Validate the Message Syntax
>>>
>>> The verifier SHOULD meticulously validate the format of the message
>>> being verified against the requirements specified in [RFC5322],
>>> [RFC2045], and [RFC2047]. In particular, limitations on the number of
--On 14 October 2010 13:44:40 -0400 "John R. Levine" wrote:
>> That makes it invalid input to any module that requires input to comply
>> with RFC5322, pure and simple.
>
> Well, OK, with the stipulation that no existing MUA I have ever seen is
> such a module.
Nor MTA, either. Exim has a "ver
Ian Eiloart wrote:
>
> I think the emphasis in John's email was on "expect reasonable results with
> existing MUAs" If DKIM is any part of the evaluation process, then that's
> all thrown away if MUAs are showing the wrong email address as
> authenticated.
>
MUAs are like children. They eat w
Murray S. Kucherawy wrote:
>> Levine wrote:
>> Aw, come on. How many millions of people still use Outlook Express on
>> Windows XP? Switching MUAs is painful, people rarely do it.
> ...meaning MUA developers won't bother to do something about
> it once the attack is plainly visible and they're
On Wed, 13 Oct 2010 18:13:43 +0100, Jim Fenton wrote:
> My inclination is that the spec should say something like:
>
> - The verifier SHOULD consider the signature invalid if a signed header
> field occurs an inappropriate number of times in the message header
> according to section 3.6 of RFC 53
On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton wrote:
> Here's some text I propose for section 8.14, in place of the current
> text. Bear in mind that this is in the context of the Security
> Considerations section of the spec, so it is really a discussion of the
> threat and how it is dealt with
On Thu, 14 Oct 2010 15:17:15 +0100, John R. Levine wrote:
> We seem to be talking past each other here.
>
> I don't see anyone proposing a deep dive into 5322 validation. But 4871
> already says you MUST sign the From: header. Why is that OK, but saying
> you MUST NOT sign or validate something
On Thu, 14 Oct 2010 17:45:39 +0100, John R. Levine wrote:
> Well, yeah. That's why I don't understand why people are so opposed to a
> SHOULD saying they should.
Or even a MUST saying they must.
--
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 43
On Thu, 14 Oct 2010 18:01:25 +0100, Michael Thomas wrote:
> Because the audience who ought to be dealing with the larger problem has
> little to
> nothing to do with the audience that would have to deal with that
> MUST/SHOULD.
> It's a useless requirement to put on DKIM.
So which two audien
On Thu, 14 Oct 2010 18:23:21 +0100, Michael Thomas wrote:
> I would hope so because this would be a really stupid thing to do.
> Without the next line of defense -- virus, malware, spam, phishing --
> you'd be setting your users up for big problems. Just because it's
> DKIM signed from a good sou
On Thu, 14 Oct 2010 18:30:38 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine
>> Sent: Thursday, October 14, 2010 10:15 AM
>> To: DKIM List
>> Subject: Re: [ietf-dkim]
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Charles Lindsey
> Sent: Friday, October 15, 2010 9:06 AM
> To: DKIM
> Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
>
> On Wed, 13 Oct 2010 23:22:07 +0
On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote:
> why don't we just deprecate "l="?
Yes. Please.
Scott K
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Thu, 14 Oct 2010 19:01:17 +0100, Alessandro Vesely
wrote:
> On 13/Oct/10 20:45, Scott Kitterman wrote:
>> On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
>>> If we can extract DKIM from the equation entirely and the problem
>>> remains,
>>> how is it a DKIM problem?
On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER wrote:
>
> Although some folk have done a +1 for one (or another) removal, I'd like to
> get
> a round of explicit reactions to the specific idea of removing /both/.
+1
--
Jeff Macdonald
Ayer, MA
___
NOTE
On Thu, 14 Oct 2010 17:30:42 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Thursday, October 14, 2010 7:32 AM
>> To: DKIM
>> Subject: Re: [ietf-dkim] dete
In article <201010151013.26823.ietf-d...@kitterman.com> you write:
>On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote:
>> why don't we just deprecate "l="?
>
>Yes. Please.
Agreed. Has anyone ever found it useful for its nominal purpose of
messages transiting MLMs?
R's,
John
On 14/Oct/10 20:09, Mark Delany wrote:
> On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote:
>> On 13/Oct/10 20:45, Scott Kitterman wrote:
>> > On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
>> >> If we can extract DKIM from the equation entirel
On 10/15/2010 10:28 AM, Jeff Macdonald wrote:
> On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER wrote:
>>
>> Although some folk have done a +1 for one (or another) removal, I'd like to
>> get
>> a round of explicit reactions to the specific idea of removing /both/.
>
> +1
Folks,
The pattern is
--On 15 October 2010 14:06:16 +0100 Charles Lindsey
wrote:
>
>> 8.14. Attacks Involving Addition of Header Fields
>>
>> Many email implementations do not strictly enforce the message syntax
>> specified in [RFC5322]. One potentially exploitable consequence of this
>> is that an attacker who i
> > h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id?
>
> Yes, it does. The only question is to devise normative statements
> correctly, e.g. MUST duplicate "From", SHOULD duplicate the rest.
>
> This is _not_ a kludge. It is how DKIM signing works (Section 5.4
On 10/15/2010 11:40 AM, Mark Delany wrote:
> Well, if you want to introduce semantic changes why not just change
> the meaning of h=from:to: to be semantically identical to
> h=from:from:to:to:
This would mean that it is /never/ ok to add a listed header field after
signing. Adding would /alw
On 15/Oct/10 17:13, John Levine wrote:
> In article<201010151013.26823.ietf-d...@kitterman.com> you write:
>>On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote:
>>> why don't we just deprecate "l="?
>>
>>Yes. Please.
>
> Agreed. Has anyone ever found it useful for its nomina
On 10/15/2010 06:51 AM, Charles Lindsey wrote:
> On Thu, 14 Oct 2010 18:23:21 +0100, Michael Thomas wrote:
>
>> I would hope so because this would be a really stupid thing to do.
>> Without the next line of defense -- virus, malware, spam, phishing --
>> you'd be setting your users up for big prob
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Charles Lindsey
> Sent: Friday, October 15, 2010 6:58 AM
> To: DKIM
> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
> after signing
>
> Which mod
On 10/15/10 6:06 AM, Charles Lindsey wrote:
> On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton wrote:
>
>> 8.14. Attacks Involving Addition of Header Fields
>>
>> Many email implementations do not strictly enforce the message syntax
>> specified in [RFC5322]. One potentially exploitable consequen
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Charles Lindsey
> Sent: Friday, October 15, 2010 7:30 AM
> To: DKIM
> Subject: Re: [ietf-dkim] detecting header mutations after signing
>
> And if we are not going to fix ADS
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Alessandro Vesely
> Sent: Friday, October 15, 2010 2:13 AM
> To: Barry Leiba
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/15/10 2:12 AM, Alessandro Vesely wrote:
> On 14/Oct/10 20:40, Barry Leiba wrote:
6.1.1 Validate the Message Syntax
The verifier SHOULD meticulously validate the format of the message
being verified against the requirements specified in [RFC5322],
[RFC2045],
On 10/15/2010 08:28 AM, Dave CROCKER wrote:
>
>
> On 10/15/2010 10:28 AM, Jeff Macdonald wrote:
>> On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER wrote:
>>>
>>> Although some folk have done a +1 for one (or another) removal, I'd like to
>>> get
>>> a round of explicit reactions to the specific id
Folks, I really think we should use the opportunity to add a note
about DKIM adopters having potential DNS setup issues due to wildcard
SPF records.
When section 3.6.2.1, SPF was probably still growing and not wide
spread with Web-Based DNS managements from ISPs. Today, a special
"Add SPF re
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Charles Lindsey
> Sent: Friday, October 15, 2010 6:52 AM
> To: DKIM
> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
> after signing
>
> > That's
On Oct 15, 2010, at 9:50 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
>> On Behalf Of Charles Lindsey
>> Sent: Friday, October 15, 2010 7:30 AM
>> To: DKIM
>> Subject: Re: [ietf-dkim] detecting header
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Murray S. Kucherawy
> Sent: Friday, October 15, 2010 10:04 AM
> To: DKIM
> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
> after signing
>
> And
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Barry Leiba
> Sent: Thursday, October 14, 2010 11:49 AM
> To: IETF DKIM WG
> Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
>
> > There is an assump
Michael Thomas wrote:
>> Anyone objecting very strongly needs to speak up.
>
> I'd like to ask a procedural question of the chairs: Dave killfile's
> many participants, therefore any consensus he sees will merely reflect
> the echo chamber of his own making.
+1, this is what I have been calling
Steve,
I believe its about protocol consistency. While the main focus is
DKIM progress, its issues and resolutions are related to ADSP as well
as its a WG product as well.
For example, ADSP implementations now know that they need to make
there is only one 5322.From as well. Like most software
Murray S. Kucherawy wrote:
>> I appreciate the desire to put more information in there to help, but
>> we really can't be writing a tutorial on managing DNS records.
>
> +1. However, I'd be fine with adding some informative guidance to DKIM
> implementers reflecting current experience, somethin
> I'd like to ask a procedural question of the chairs: Dave killfile's
> many participants, therefore any consensus he sees will merely reflect
> the echo chamber of his own making.
>
> So I strongly object on procedural grounds for authors who kill file
> people in general, and for those asking fo
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Hector Santos
> Sent: Friday, October 15, 2010 10:17 AM
> To: IETF DKIM WG
> Cc: Barry Leiba
> Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
>
> > So
On Fri, Oct 15, 2010 at 1:17 PM, Hector Santos wrote:
> In fact, I have been looking at RFC 2026 Section 6.5.1 (a) as an
> reason to appeal based on the principal key editors are knowingly
> filtering input from WG participants. I know both Dave and Murray are
> doing this and both are key editor
On 10/15/2010 10:32 AM, Barry Leiba wrote:
>> I'd like to ask a procedural question of the chairs: Dave killfile's
>> many participants, therefore any consensus he sees will merely reflect
>> the echo chamber of his own making.
>>
>> So I strongly object on procedural grounds for authors who kill f
> I was threatened with legal action [...]
I understand why you posted this, but, please, let's not continue this
sort of discussion on the list.
Everyone, we're here to find consensus and develop specifications.
Let's no one attack anyone else; let's work on cooperating.
As a conference button
> This is a small 2 days collection break down of the signed mail coming in:
Thanks.
> -- 25.9% : dkim_body_hash_mismatch
I was going to ask...
> I should probably add a recording which of these has List-IDs, but I
> think the high body hash failures are most list systems.
...but you answ
On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos wrote:
> Murray S. Kucherawy wrote:
>
>>> I appreciate the desire to put more information in there to help, but
>>> we really can't be writing a tutorial on managing DNS records.
>>
>> +1. However, I'd be fine with adding some informative guidance to
On 10/15/10 7:28 AM, Jeff Macdonald wrote:
> On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER wrote:
>> Although some folk have done a +1 for one (or another) removal, I'd like to
>> get
>> a round of explicit reactions to the specific idea of removing /both/.
> +1
Given the lack of (useful) depl
For the record, what you were told was that if your childish action of
filtering me extended to telling others to filter me, that would be
grounds for tort.
Apparently, I am not the only one who feels the consensus process is
being skewed by key editors filtering of WG Participants that don't
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Barry Leiba
> Sent: Friday, October 15, 2010 10:48 AM
> To: Hector Santos
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] 2 Day Collection Stats
>
> > -- 25.9% :
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Jim Fenton
> Sent: Friday, October 15, 2010 10:25 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
>
> Given the lack
On 15/Oct/10 18:59, Jim Fenton wrote:
>On 10/15/10 2:12 AM, Alessandro Vesely wrote:
>> Fuzziness stems from the fact that a signature on a given message may
>> either verify or not depending on how meticulously the verifier
>> interprets that "SHOULD". The "MUST" immediately following it i
support
On Oct 15, 2010, at 1:58 PM, Barry Leiba wrote:
> On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos wrote:
>> Murray S. Kucherawy wrote:
>>
I appreciate the desire to put more information in there to help, but
we really can't be writing a tutorial on managing DNS records.
>>>
>>>
> Breaking that down further: Of the 8,219, 6,614 (80.4%) were author domain
> signatures, so the rest were presumably list signatures (or something else).
>
> 57 of them failed even in the presence of an "l=" tag.
More work for Murray. Distribution of the l= values? Particularly l=0
Mark.
__
On 10/15/2010 1:32 PM, Barry Leiba wrote:
>> Dave killfile's
>> many participants, therefore any consensus he sees will merely reflect
>> the echo chamber of his own making.
>>
>> So I strongly object on procedural grounds
...
>
> Mike, you needn't object unless the chairs put people in our
>
On 15/10/10 18:32, Barry Leiba wrote:
>> I'd like to ask a procedural question of the chairs: Dave killfile's
>> many participants, therefore any consensus he sees will merely reflect
>> the echo chamber of his own making.
>>
>> So I strongly object on procedural grounds for authors who kill file
> -Original Message-
> From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On
> Behalf Of internet-dra...@ietf.org
> Sent: Friday, October 15, 2010 11:15 AM
> To: i-d-annou...@ietf.org
> Cc: ietf-dkim@mipassoc.org
> Subject: I-D Action:draft-ietf-dkim-mailinglists-04
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Mark Delany
> Sent: Friday, October 15, 2010 11:15 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] 2 Day Collection Stats
>
> > 57 of them failed even in the prese
On 10/15/2010 11:19 AM, Dave CROCKER wrote:
>
>
> On 10/15/2010 1:32 PM, Barry Leiba wrote:
>>> Dave killfile's
>>> many participants, therefore any consensus he sees will merely reflect
>>> the echo chamber of his own making.
>>>
>>> So I strongly object on procedural grounds
> ...
>>
>> Mike
On Oct 15, 2010, at 10:58 AM, Barry Leiba wrote:
> On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos wrote:
>> Murray S. Kucherawy wrote:
>>
I appreciate the desire to put more information in there to help, but
we really can't be writing a tutorial on managing DNS records.
>>>
>>> +1.
On 10/15/2010 10:45 AM, Stephen Farrell wrote:
> In this case, I don't recollect an objection, so thus far, it seems
> to me that Dave's correct on this one. I think its perfectly fine
> for an editor to try to close off things that seem to have a clear
> consensus like this.
Stephen -- the issue
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Murray S. Kucherawy
> Sent: Friday, October 15, 2010 11:41 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] 2 Day Collection Stats
>
> > > 57 of them failed even in
On Friday, October 15, 2010 01:58:07 pm Barry Leiba wrote:
> On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos wrote:
> > Murray S. Kucherawy wrote:
> >>> I appreciate the desire to put more information in there to help, but
> >>> we really can't be writing a tutorial on managing DNS records.
> >>
>
On 10/15/2010 2:46 PM, Steve Atkins wrote:
> I'm not sure whether wildcard records is relevant to the spec - that's
> more of a "development, deployment and operations" issue, I think.
The degree to which a processing environment is expected to be "pure" versus
potentially "noisy" might well c
At 08:25 14-10-10, Hector Santos wrote:
>I don't think I am suggesting to get into the bad DNS managements
>tools. But the section is short on what are possible error issues.
>One of them is making sure other TXT records don't conflict. I think
>that can be a general, generic statement that does
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Keys Identified Mail Working Group of
the IETF.
Title : DKIM And Mailing Lists
Author(s) : M. Kucherawy
Filename: draft-ietf-dki
Murray S. Kucherawy wrote:
>
> And, anticipating the next question(s):
>
> Signatures with other "l=" values that were in turn larger than the message
> received: 10389
> Subset of those that still passed: 9870 (95%)
> Subset of those that still passed and looked like list traffic: 5504 (53%)
>
On 10/14/2010 12:22 PM, Murray S. Kucherawy wrote:
> Seems OK to me. But doesn't EMAIL-ARCH talk about domain names and ADMDs and
> all that? Perhaps it's a better reference for this?
As much as I like to tout email-arch, the citation here needs to be
specifically
about the DNS and, for exa
>> The DKIM public key TXT record MUST not be mixed or merged
>> with other TXT records, i.e. SPF. In addition, make sure other
>> TXT records with Wildcards do not conflict with DKIM public
>> key lookups.
>
> That text adds a requirement in an informative note.
THat is
On Fri, Oct 15, 2010 at 1:58 PM, Barry Leiba wrote:
> On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos wrote:
>> Murray S. Kucherawy wrote:
>>
I appreciate the desire to put more information in there to help, but
we really can't be writing a tutorial on managing DNS records.
>>>
>>> +1.
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Jeff Macdonald
> Sent: Friday, October 15, 2010 12:54 PM
> To: IETF DKIM WG
> Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT
> records
>
> Does ADSP need to
Well a broken signature is morally equivalent to unsigned so Im not sure of the
potential harm...
On Oct 15, 2010, at 11:53 AM, Dave CROCKER wrote:
>
>
> On 10/15/2010 11:40 AM, Mark Delany wrote:
>> Well, if you want to introduce semantic changes why not just change
>> the meaning of h=from:to
SM wrote:
>> This is just to jump start suggested text. Others can add/change
>> whether they think helps:
>>
>> The DKIM public key TXT record MUST not be mixed or merged
>> with other TXT records, i.e. SPF. In addition, make sure other
>> TXT records with Wildcards do not conflic
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com
> Sent: Friday, October 15, 2010 11:59 AM
> To: dcroc...@bbiw.net
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] detecting header mutations after
On Oct 15, 2010, at 1:51 PM, MH Michael Hammer (5304) wrote:
>
>
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
>> boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com
>> Sent: Friday, October 15, 2010 11:59 AM
>> To: dcroc...@bbiw.net
>> Cc: ietf-dkim
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of MH Michael Hammer (5304)
> Sent: Friday, October 15, 2010 1:52 PM
> To: Bill Oxley @ Cox; dcroc...@bbiw.net
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] detecting h
On 10/15/10 1:51 PM, MH Michael Hammer (5304) wrote:
> >
> > On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote: To:
> > dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re:
> > [ietf-dkim] detecting header mutations after signing
> >
> > Well a broken signature is morally equivalent to
On 10/14/10 6:54 AM, John R. Levine wrote:
>>> Another potential option is to remove g= entirely:
>>
>> I'd like to encourage our considering this strongly, for two reasons:
>
> I agree, g= seems to me to be a vestige of the confusion between i=
> and d= identity.
>
> If we do, it's probably a g
On 10/15/10 10:58 PM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
>> On Behalf Of MH Michael Hammer (5304)
>> Sent: Friday, October 15, 2010 1:52 PM
>> To: Bill Oxley @ Cox; dcroc...@bbiw.net
>> Cc: ietf
On 10/15/10 10:58 AM, Barry Leiba wrote:
> On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos
> wrote:
> > Murray S. Kucherawy wrote:
> >
> >>> I appreciate the desire to put more information in there to
> >>> help, but we really can't be writing a tutorial on managing DNS
> >>> records.
> >>
> >>
On 10/15/10 8:40 AM, Mark Delany wrote:
>>> h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id?
>> Yes, it does. The only question is to devise normative statements
>> correctly, e.g. MUST duplicate "From", SHOULD duplicate the rest.
>>
>> This is _not_ a kludge.
MH Michael Hammer (5304):
>
>
> > -Original Message-
> > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> > boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com
> > Sent: Friday, October 15, 2010 11:59 AM
> > To: dcroc...@bbiw.net
> > Cc: ietf-dkim@mipassoc.org
> > Subject: Re:
On 10/15/10 2:10 PM, Wietse Venema wrote:
> MH Michael Hammer (5304):
> >> On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote:
> >>
> >> Well a broken signature is morally equivalent to unsigned so Im
> >> not sure of the potential harm...
> >
> > And this is where I angst. In all the discus
On 15/10/10 19:48, Michael Thomas wrote:
> On 10/15/2010 10:45 AM, Stephen Farrell wrote:
>> In this case, I don't recollect an objection, so thus far, it seems
>> to me that Dave's correct on this one. I think its perfectly fine
>> for an editor to try to close off things that seem to have a cle
MH Michael Hammer (5304) wrote:
> And this is where I angst. In all the discussions of a broken signature
> being morally equivalent to unsigned, the thrust has been that it was
> likely broken in transit. We failed to have the discussion of it being
> intentionally broken in transit as an attempt
Okay, we could put policy back in and state a malformed signature cannot pass
and assign a weight higher than an unsigned message. Then the problem remains
the same, is it error or malice. A dkim verifier is the wrong tool to do that
particular job
On Oct 15, 2010, at 7:12 PM, Hector Santos wrot
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Douglas Otis
> Sent: Friday, October 15, 2010 2:30 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] detecting header mutations after signing
>
> Citing a layer viol
Bill,
First, lets kill this seed, I wasn't suggesting to put policy back into
the DKIM spec.
What I speak of is that before you can do any DKIM Fault Analysis you must
first establish the DKIM boundary conditions for 100% failure and 100%
success.
That has to do done first and if we can't do th
On Friday, October 15, 2010 07:50:36 pm Murray S. Kucherawy wrote:
> > -Original Message-
> > From: ietf-dkim-boun...@mipassoc.org
> > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent:
> > Friday, October 15, 2010 2:30 PM
> > To: ietf-dkim@mipassoc.org
> > Subject: Re:
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Scott Kitterman
> Sent: Friday, October 15, 2010 5:09 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Data integrity claims
>
> > I thought the "What DKIM does" th
> I thought the "What DKIM does" thing was a long-dead horse, as we'd
> long ago reached consensus that what DKIM does is provide a stable
> identifier on the message, and nothing more. That makes this
> assertion inapposite.
> I think perhaps now would be a good time to make that explicit,
> sin
Murray S. Kucherawy wrote:
> There might be a better way to characterize it, but I think the answer comes
> from the errata RFC upon which we reached consensus a while back: The primary
> payload delivered by a DKIM validation is the validated domain name.
> Reputation, for example, would be c
>In this case, we've gone to some lengths to make the environment
>pure, by using the underscore branch. And then along come these
>pesky wildcards.
Even without wildcards, there's been a variety of broken key records.
I would hope it would be obvious that you have to assume that any data
you ha
On Oct 15, 2010, at 7:13 PM, John Levine wrote:
>> In this case, we've gone to some lengths to make the environment
>> pure, by using the underscore branch. And then along come these
>> pesky wildcards.
>
> Even without wildcards, there's been a variety of broken key records.
>
> I would hope
John Levine wrote:
> By the way, has everyone tested their signing code to see what happens
> if there's no From: header at all? Do we even agree what the right
> thing is? I'd think it'd be approximately the same as if the private
> signing key (the only other mandatory input I can think of at
Steve Atkins wrote:
>> I'd think it'd be approximately the same as if the private
>> signing key (the only other mandatory input I can think of at the
>> moment) wasn't present.
>
> If it fails, it's broken, I think. There's nothing special about the
>>From field, other than it having to be one o
On Oct 15, 2010, at 7:56 PM, Hector Santos wrote:
> Steve Atkins wrote:
>
>>> I'd think it'd be approximately the same as if the private
>>> signing key (the only other mandatory input I can think of at the
>>> moment) wasn't present.
>>
>> If it fails, it's broken, I think. There's nothing spe
I found today this patent:
US PATENT 7487217
http://www.docstoc.com/docs/57449330/Network-Domain-Reputation-based-Spam-Filtering---Patent-7487217
but then it seems prior art existed in the form of DKIM (which was started
around 2004 http://news.domainmonster.com/dkim-email/)
Not being a patent
On 10/15/2010 8:32 PM, Mark Delany wrote:
> Therefore one could
> argue that DKIM is "protecting" that relationship between the message
> and identifier.
Clever phrasing. Might be too subtle for general use, but I think it offers a
perspective that could be useful.
I think the issue here is t
Steve Atkins wrote:
>> Hector wrote:
>> The spec says
>>
>> 5.4. Determine the Header Fields to Sign
>>
>>The From header field MUST be signed (that is, included in the "h="
>>tag of the resulting DKIM-Signature header field).
>>
>> That means to me it MUST exist to be signed.
>
> "h=Fro
1 - 100 of 103 matches
Mail list logo
