Subject: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records

From: Hector Santos <[email-masked]>
Date: Wed, 13 Oct 2010 20:31:31 -0400

Folks,

I know section 3.6.2.1 has this informative note:

      INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g.,
      *.bar._domainkey.example.com) do not make sense in this context
      and should not be used.  Note also that wildcards within domains
      (e.g., s._domainkey.*.example.com) are not supported by the DNS.

But I think the section may need information about working with 
multiple or existing TXT records, i.e. SPF and the possibility that 
there could be a wildcard for other TXT records and this can provide a 
lookup error for DKIM public key records.

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 conflict with DKIM public
     key lookups.

Background reason:

Today we got our 3rd field testers who ran into mixed up TXT records. 
All of them manage their DNS setup with ISP web based DNS managers for 
their small business but they are not DNS administrators.

They did not understand how the DKIM public key TXT record is separate 
from other TXT records, like SPF.

Two of them merged it with their existing SPF record and one of them 
had a wildcard SPF setup and this was always the result of DKIM public 
key lookups. When informed of this, he removed the wildcard setup for 
SPF but he merged his DKIM public key with his SPF record.

My proposal to add more informative notes to help minimize this for 
the systems with the lack of DNS admin expertise on board. In 
particular for those with currently one existing need for a TXT record 
and that is SPF and incorrectly believe since its a TXT record, adding 
the DKIM public key data to it will work.

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: SM <[email-masked]>
Date: Wed, 13 Oct 2010 21:45:05 -0700

>I know section 3.6.2.1 has this informative note:

[snip]

>      TXT records with Wildcards do not conflict with DKIM public

That text adds a requirement in an informative note.

>the DKIM public key data to it will work.

There is an assumption that people managing DNS zones will have a 
basic understanding of DNS.  I don't think that the DKIM 
specification should get into badly designed GUIs.

RFC 4871 discusses about DNS in various sections.  Unfortunately, 
there is no reference to the DNS specifications.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 14 Oct 2010 08:22:31 -0400

> there is no reference to the DNS specifications.

OMG.  As in, wow.

I propose changing from:

      <section
          title="Introduction">

          <t>DomainKeys Identified Mail (DKIM) permits a person, role, or
             organization that owns the signing domain to claim some
             responsibility for a message by associating the domain with the
             message. This can be an author's organization, an operational relay
             or one of their agents.

to:

       <section
          title="Introduction">

          <t>DomainKeys Identified Mail (DKIM) permits a person, role, or
             organization to claim some responsibility for a message by
             associating a domain name <xref
                target="RFC1034" /> with the message. This can be an author's
             organization, an operational relay or one of their agents.
             ...

Note that the sentence is slightly modified, which is the reason I'm running 
this past the wg.  It defers reference to "signing" domain until later.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Mark Delany" <[email-masked]>
Date: 14 Oct 2010 06:49:46 -0700

>              organization, an operational relay or one of their agents.

Well, just to create a bit more of a rat-hole, is there any chance
you'd like to add a definitional link for the word "message" as well?

It seems to me that much of our other discussion swims around that
meaning. Is it what is sent, is it what's signed, is it what shows
up in the MUA...

Mark.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 14 Oct 2010 10:03:21 -0400

> you'd like to add a definitional link for the word "message" as well?

The easy and possibly sufficient answer is:  RFC 5322.

If more precision is required, then Section 3.5 of RFC 5322.

Does anyone feel some other citation is necessary?

Does anyone feel that the section number citation in 5322 is essential.  (I only 
ask because adding a pure RFC citation to the opening sentence of the 
Introduction will be somewhat cleaner without it.

       <section
          title="Introduction">

          <t>DomainKeys Identified Mail (DKIM) permits a person, role, or
             organization to claim some responsibility for a message by
             associating a domain name <xref
                target="RFC1034" /> with the message <xref
                target="RFC5322" />. This can be an author's organization, an
             operational relay or one of their agents.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Thu, 14 Oct 2010 11:25:16 -0400

SM wrote:

> There is an assumption that people managing DNS zones will have a basic 
> understanding of DNS.  I don't think that the DKIM specification should 
> get into badly designed GUIs.
> 
> RFC 4871 discusses about DNS in various sections.  Unfortunately, there 
> is no reference to the DNS specifications.

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 not get into poor 
DNS management tools implementation.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 09:22:49 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Thursday, October 14, 2010 5:23 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
> 
> [...]

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?

---

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Oct 2010 14:48:41 -0400

> specification should get into badly designed GUIs.

I agree, more generally, that the DKIM spec can't tell people the
right way to manage their DNS records.  DKIM already separates its TXT
records with the "_domainkey" identifier, as SPF does with _spf.  If,
given that separation, people still merge the TXT records and whatnot,
that problem's well beyond the scope of our work to fix.

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.

Barry, as participant

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 14 Oct 2010 15:02:36 -0400

>we really can't be writing a tutorial on managing DNS records.

+1.

Just as a note of clarification, SPF doesn't prefix TXT records, but I don't think that affects the analysis.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 14 Oct 2010 15:14:01 -0400

Barry Leiba wrote:
>> basic understanding of DNS. �I don't think that the DKIM

I know you realize I was not advocating information on managing DNS 
records.

But what happen today, is further evidence that even DNS 
administrators or software developers who are asked to write a 
WEB-BASED manager for their service to support SPF and now DKIM, are 
not aware of how mixing it is can be in conflict.

All I ask is that possible a simple statement or sentence in that 
short section provide some insight regarding not mixing it up with 
other TXT records and that wildcards should not be used for other TXT 
records because this can fail the DKIM public key lookup.

In this case, a customer is using Network Solutions and in their add 
TXT record, it doesn't allow a blank sub domain.   The only way to do 
it is to have a

     subdomain:   "* (ALL OTHERS)"
     domain:  .xyz.com
     value:   v=spf1 .............

Clearly, this a software bug and the customer called NS about how to 
get a non-wildcard SPF record because it was interfering with their 
new DKIM public and ADSP records setup.  NS's (first level support) 
answer was (erroneous) - "not possible. It doesn't work that way."

So sure, this has to be fixed by NS, but what I am saying is that ISP 
people will also be reading the specs too perhaps to see what is 
required to implement Web-based DNS Records Management tools with DKIM 
and SPF support and what I am proposing is helpful insight on the 
design guidelines that would avoid conflicts.

BTW, the customer (a government newsletter bulk spammer) had to delete 
his SPF record to get our DKIM implementation running with verifiable 
signatures.  With the conflict, they were getting dkim invalid 
signatures with selector DNS errors.

I'm sure they will be many customers who may not want to delete their 
SPF record in order to get DKIM working.  So my suggestion is to help 
avoid these potential conflicts.

It is not about going deep into DNS management issues.  Just the basic 
DKIM public key integration issues with existing TXT records.

If you don't think that is possible, ok.  I think it is, but... :)

---

From: Hector Santos <[email-masked]>
Date: Thu, 14 Oct 2010 15:22:47 -0400

> Just as a note of clarification, SPF doesn't prefix TXT records, but I don't think that affects the analysis.

The Network Solutions DNS Records manager does not allow you to add a 
TXT record without a sub-domain, so to add one, you have to add * 
which when saved, it shows up as

        * (All Others)

for the sub-domain column.

For the new DKIM customer, we were assisting in adding the DKIM public 
key and ADSP records and this conflicted with the lookups return SPF 
records for all DKIM/ADSP record queries.

Clearly, this is a problem with Network Solutions web tool.

What I proposing is provide insight into potential conflicts with 
existing SPF (or other records) that might have a wild card associated 
with it.

The audience will include ISPs that need guidelines as well and 
already have a SPF wizard or something or only allow * sub-domains to 
get a non-prefix domain query.   These notes will help provide them 
and future implementations of DKIM DNS records support the insight to 
do it correctly.

I hope DKIM is about catering to all sites small to large, not just 
large systems with DBA and DNS administrators.  The insights should 
help adoptions without pains.

---

From: Hector Santos <[email-masked]>
Date: Thu, 14 Oct 2010 15:49:30 -0400

> we really can't be writing a tutorial on managing DNS records.

I missed your statement above:

        ....... as SPF does with _spf.

SPF is a no prefix lookup.

This is why it became a conflict because its possible domains are 
using wildcards and in at least in one case discovered today, Network 
Solutions does not allow you to add a TXT record without a sub-domain. 
  You have to get around it with an asterisk (*) and it shows it as 
"All Others".

Maybe related, but I have not checked, does 4871 talk about parsing 
multiple records looking for the "v=DKIM1" string?

If not, then this is needs to be written about because if we don't 
want to see anything about wildcard SPF records, then we have 
implementations that will need to change their wares to only parse the 
v=DKIM1 string.

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 13:01:42 -0400

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 record" option is available.

At least at one ISP/Domain Registrar (one of the original biggest), it 
only allows a wildcard TXT record to cover the non-prefix SPF query. 
This conflicts with added DKIM and ADSP dns records.

The section already has an INFORMATIVE OPERATIONAL NOTE advising not 
to use wildcards for DKIM public keys records.

What I am suggesting is another short INFORMATIVE OPERATIONAL NOTE, 
not about a tutorial on DNS management, but maybe just saying:

       INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records for SPF
       records may conflict with DKIM TXT sub-domain TXT records.
       DNS management software should not require only Wildcard SPF
       entries and should allow for non-prefix SPF TXT enries.

The readers of this document will include web developers for DNS zone 
file management when considering DKIM record support and having this 
new informative note will guide them in not being conflictive with 
DKIM TXT record lookups.

The only reason I like for people to consider this is because I got an 
email today that Network Solutions isn't going to address this issue 
for the customer.

So like Murray likes to admonish those for lack of compliancy and to 
encourage to fix problems, having the helpful information operational 
node will help "admonish" DNS management software developers to maybe 
correct their current implementations.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 10:16:12 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Thursday, October 14, 2010 11:49 AM
> To: IETF DKIM WG

+1.  However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: "The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing).  Verifiers should expect this to occur and plan accordingly."

Advice for DNS management packages is possibly useful, but it belongs elsewhere.

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 13:27:51 -0400

> +1.  However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: "The use of wildcard TXT records in the DNS often result in somet…

Thank you Murray.  Something small and sweet will be useful, and your 
text is good enough.

> Advice for DNS management packages is possibly useful, but it belongs elsewhere.

+1

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Oct 2010 13:58:07 -0400

On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos <[email-masked]> wrote:
>> +1.  However, I'd be fine with adding some informative guidance to DKIM
>> implementers reflecting current experience, something like: "The use of
>> wildcard TXT records in the DNS often result in something coming back
>> from a query that isn't a valid DKIM key record (and ADSP will encounter
>> the same thing).  Verifiers should expect this to occur and plan accordingly."
>

Good; we have a start.  Will others please indicate support (or not)
for adding this or similar text ?

Barry, as chair

---

From: <[email-masked]>
Date: Fri, 15 Oct 2010 14:14:12 -0400

support

---

From: Steve Atkins <[email-masked]>
Date: Fri, 15 Oct 2010 11:46:15 -0700

> for adding this or similar text ?

I'm not sure whether wildcard records is relevant to the spec - that's
more of a "development, deployment and operations" issue, I think.

As a verifier implementor I'm not that interested in why someone is
publishing bogus key records as I am in what I should do about them
(fail if any are invalid, fail if there are multiple, check all of them and
pass if any are valid...) - what's an appropriate response from the
verifier in the case that the TXT records returned are unexpected.

So the existing wording is harmless, and I'd support adding it,
but something a little bit more prescriptive might be better.

Cheers,
  Steve

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 15 Oct 2010 15:00:21 -0400

> for adding this or similar text ?

I'm neutral on the subject of covering this topic, but if we are going to 
cover it, this or similar text is good.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 Oct 2010 15:00:22 -0400

> 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 come into play during the specification phase. 
For example, it might be why a distinguishing label gets added.

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.

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Fri, 15 Oct 2010 11:33:28 -0700

>DNS management tools implementation.

There are possible error issues which you won't find in the RFCs for 
DKIM.  The "wildcard in DNS" is a known issue.  You can catch it by 
looking for the "DKIM1" tag in the DNS reply.  If you are going to 
get into "fixing" the DNS side in the specification, you are opening 
the way to a new set of problems that are better addressed by a 
working group which is tasked to tackle DNS issues.  You may, for 
example, encounter DNS failures because the primary is not in sync 
with the secondaries; or the backslash in the _domainkey DNS record; 
or assumptions that DNS queries should always be over UDP.

At 09:22 14-10-10, 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?

That document is not a better reference as it is not about how DNS works.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 Oct 2010 15:22:56 -0400

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 example, not about the DNS for mail.

The fact that we hadn't even thought to include such basic citations in the 
original work on the draft provides good insight about the reader we are adding 
these for...

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 Oct 2010 15:27:03 -0400

> That text adds a requirement in an informative note.

THat is the least of its problems.  DKIM records go into a protected subbrance, 
given the underscore name.

> there is no reference to the DNS specifications.

we've just fixed that during the current edits.

d/

-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 15 Oct 2010 15:54:19 -0400

> for adding this or similar text ?

Does ADSP need to be mentioned? Otherwise +1.

-- 
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 12:58:31 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff Macdonald
> Sent: Friday, October 15, 2010 12:54 PM
> To: IETF DKIM WG

I don't think so.  ADSP's built on top of DKIM, not the other way around.

We could say the same thing in ADSP though if there's ever an ADSPbis (<deity-of-your-choice> help us...).

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 16:04:47 -0400

> That text adds a requirement in an informative note.

SM,

You can tell me if I am wrong here cause I am trying to make sure I 
understand the IETF angle to this but I also a product developer and 
have to look at the customer support angles as well.

1) Verifier TXT record parsing

I checked for this, but did not find it, but was a quick scan.

If the DKIM specs says that verifiers MUST be ready for different TXT 
records merged in the DNS Query response, it MUST parse for the string

      v=DKIM1

If this is the case, then I don't think we need to add anything. Its 
all good.

This would be an implementation bug in our software if indeed that is 
what happening with invalid selector DKIM fails.

2) If #1 isn't part of the specs..........

then I think there should be some note regarding working with other 
TXT records and to provide guidelines to DNS management software 
people to not enforce a wildcat only TXT record management solution 
for their customers.

The note should not add a requirement for verifiers though (if this is 
going to an IETF RFC issue).

However, in my personal engineering opinion, it probably should add a 
note for verifiers to be ready for multiple string responses.

      Note: For SPF, verifiers are already expecting and looking
            for the v=spfxxx strings in merged TXT records responses.
            This is required to support SPF and SENDERID.

I see this as one of those things of an aged document drafted 4-5 
years ago at the time where SPF was viewed as a competitive solution 
to DKIM and mentioning SPF or giving it credit for existing was 
probably not on editors mind.

But today, SPF is real. Domain Hosting sites have tools to support it 
for the small to mid size market that are using their domain hosting 
name servers. DKIM should realize its wide presence from a DNS public 
key standpoint, not in a "How to" but to provide insight about the 
possible conflictive issues and I think its really just about those 
"pesky" wildcard DNS feature as Crocker put it.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Oct 2010 14:34:37 -0700

On 10/15/10 10:58 AM, Barry Leiba 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, something
> >> like: "The use of wildcard TXT records in the DNS often result in
> >> something coming back from a query that isn't a valid DKIM key
> >> record (and ADSP will encounter the same thing). Verifiers
> >> should expect this to occur and plan accordingly."
> >
> > Thank you Murray. Something small and sweet will be useful, and
> > your text is good enough.
>

+1

-Doug

---

From: John Levine <[email-masked]>
Date: 16 Oct 2010 02:13:55 -0000

>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 haven't previously verified is potentially hostile, either
deliberately or by mistake.  This refers to DNS keys, DKIM signatures,
and the message you're trying to sign or verify.

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 the
moment) wasn't present.

R's from PHL gate F18,
John

---

From: Steve Atkins <[email-masked]>
Date: Fri, 15 Oct 2010 19:27:28 -0700

On Oct 15, 2010, at 7:13 PM, John Levine wrote:

> thing is?  

h=From with no From header is fairly well defined, I think. The message
will be signed, and that signature will validate just fine, unless
something in the message is modified - such as adding a From:
field.

> I'd think it'd be approximately the same as if the private

If it fails, it's broken, I think. There's nothing special about the
>From field, other than it having to be one of the signed headers.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 22:53:07 -0400

> signing key (the only other mandatory input I can think of at the

For our DKIM implementation, it will fail to sign and fail to verify.

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 22:56:48 -0400

>>From field, other than it having to be one of the signed headers.

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.

---

From: Steve Atkins <[email-masked]>
Date: Fri, 15 Oct 2010 20:27:11 -0700

> That means to me it MUST exist to be signed.

"h=From" for a message that has no From: header when signed
means that the message must have no From: header when the
signature is validated, I think? And 5.4 just says you must include
>From in the h= tag, not that it must exist.

A missing From: field makes the message not a 5322 message,
but I'm not sure what that implies for DKIM.

Cheers,
  Steve

---

From: Franck Martin <[email-masked]>
Date: Sat, 16 Oct 2010 14:54:13 +1200 (FJT)

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 lawyer or anything like this, and knowing the US patent office gives anyone anything, I just wanted to point to this patent.

May be also this has already been discussed a lot here...

---

From: Hector Santos <[email-masked]>
Date: Sat, 16 Oct 2010 00:09:53 -0400

Steve Atkins wrote:

>> Hector wrote:

I see your point.

Since a 5322.From is a required header for a valid RFC5322 message 
(From and Date are the two that required by RFC2822 and RFC5322, for 
RFC822, it requires the To (or BC) as well), I believe the expectation 
that it exist in the message for DKIM to imply it must exist in h=From.

For our MDA/MSA, it will definitely invalidate an incoming message 
header but I don't recall the details.  From old discussions in 
IETF-SMTP, I am pretty sure most MDA/MSA will enforce a 5322.From as 
well.  I think the exception if when the client is local (internal) or 
maybe authenticated.

The Alt-N DKIM API we are using will definitely fail to sign the 
message if a From is missing and it will fail to verify as well 
because there has to be a h=from and matching 5322.From.

This probably means that it should clarified what that 5.4 sentence 
means and also the next section 5.5

5.5.  Recommended Signature Content

    ..

    The following header fields SHOULD be included in the signature, if
    they are present in the message being signed:

    o  From (REQUIRED in all signatures)

It reads to me that From is the SHOULD exception to a MUST.

But I can definitely see what you mean, because if it means that you 
have to add  h=from without a real 5322.From, then a signature might 
be signed and be technical DKIM valid but only against those systems 
that are not enforcing a 5322.from header.

---

From: SM <[email-masked]>
Date: Fri, 15 Oct 2010 23:11:09 -0700

Hi Hector,
>You can tell me if I am wrong here cause I am trying to make sure I

It is not up to me to determine whether you are wrong. :-)

>If this is the case, then I don't think we need to add anything. Its

That tag isn't always included in the DNS record for backward 
compatibility with DomainKeys.  And it is optional.  As you are doing 
a query for a TXT RR, expect garbage.

>note for verifiers to be ready for multiple string responses.

 From RFC 3833:

    Much discussion has taken place over whether and how to provide data
    integrity and data origin authentication for "wildcard" DNS names.
    Conceptually, RRs with wildcard names are patterns for synthesizing
    RRs on the fly according to the matching rules described in section
    4.3.2 of RFC 1034.  While the rules that control the behavior of
    wildcard names have a few quirks that can make them a trap for the
    unwary zone administrator, it's clear that a number of sites make
    heavy use of wildcard RRs, particularly wildcard MX RRs.

Regards,
-sm

---

From: "Mark Delany" <[email-masked]>
Date: 15 Oct 2010 23:19:00 -0700

> but then it seems prior art existed in the form of DKIM (which was started around 2004 http://news.domainmonster.com/dkim-email/)

DKIM largely derives from DomainKeys which largely derives from US
Patent 6,986,049 filed in Sep 2003. In 2004 the IPR was bequeathed to
the IETF by the Assignee (aka my employer at the time).

See: https://datatracker.ietf.org/ipr/693/
and
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=9&f=G&l=50&co1=AND&d=PTXT&s1=delany.INNM.&OS=IN/delany&RS=IN/delany

Given the timing, clearly the 2005 filing of 7,487,217 you mention
cannot encroach on the prior filings of DomainKeys. If anything it's
around the other way as 6,986,049 could invalidate 7,487,217.

But, IANAL and I never want to be one. I am just stating known facts
here.

Mark.

---

From: John Levine <[email-masked]>
Date: 16 Oct 2010 14:02:19 -0000

>US PATENT 7487217
>http://www.freepatentsonline.com/7487217.html
>
>but then it seems prior art existed in the form of DKIM (which was
>started around 2004 http://news.domainmonster.com/dkim-email/)

This isn't a patent about authentication, it's about spam filtering
using the reputation of domains associated with mail.  Since it's from
Microsoft, the description uses Sender ID but the claims, which are
what counts, are phrased more generally.

It was filed in 2005, so offhand I don't know how hard it would be to
find earlier discussions of reputation based filtering.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 16 Oct 2010 12:28:05 -0400

> It is not up to me to determine whether you are wrong. :-)

 From an IETF procedural angle.  :)

> compatibility with DomainKeys.  And it is optional.  As you are doing a 
> query for a TXT RR, expect garbage.
> 

The difference is that MX records are well structured fixed RR 
records, where merged TXT records have a multi-technology mix with 
multiple non-fixed structured definitions.  So the client has to be 
aware of all of them or be savy enough to look for what for what it wants.

But my question was:

If 4871 does not speak of requiring the DKIM client of parsing merged 
TXT records to look for its specific inputs, then section 3.6.2.1 
needs to make up for this dearth of verifier design information.

I ask because in Murray's suggested text:

     "The use of wildcard TXT records in the DNS often result in
      something coming back from a query that isn't a valid DKIM key 
record
     (and ADSP will encounter the same thing).  Verifiers should expect
     this to occur and plan accordingly."

I like it, but from an IETF standpoint, doesn't the last sentence 
imply a 'change of code' thing that we try to avoid here?

I think the way it is stated was design to avoid this.  Right?

-- 
HLS

---

From: SM <[email-masked]>
Date: Sun, 17 Oct 2010 03:20:10 -0700

Hi Hector,
>  From an IETF procedural angle.  :)

I'll comment on how I read what the WG Chairs said in general 
terms.  If you believe that the process followed is not fair, you 
could discuss the matter with the WG Chairs.  I'll quote a message 
from a WG Chair [1]:

  "You're certainly welcome to file an appeal, if you think there's been
   a procedural problem.  The first step, of course, is to bring the
   issue to the attention of the chairs (which you have), and the next is
   to discuss it with the responsible AD (Sean)."

That clearly states whom you can contact to discuss any IETF WG 
procedural problem.

  "you can increase the chances that people will read your posts if
   you post clearly, concisely, and calmly (the three Cs?), and avoid
   invective and excess."

That sounds like good advice.  If we describe a problem clearly and 
concisely, it is easier for the readers to understand our 
arguments.  It is easier to find a solution if we discuss the matter calmly.

And quoting another message from a WG Chair [2]:

  "I think it'd also be good if people could bear in mind that we're
   not saving or endangering the planet here - we're moving an RFC
   along the standards track by making very very minor changes and
   clarifications in a quite controlled fashion. (Most of which will
   be ignored by many coders;-)"

The first part explains the work this WG is trying to do.  I gather 
that you do know that some of the advice in the RFC will be ignored 
whatever this WG says; the SHOULD will be reinterpreted to suit 
personal taste and some people will read the MUST as legal advice.

>imply a 'change of code' thing that we try to avoid here?

There is, for example, a "should" in the text you quoted and some 
people may nit about it.  Would the above text force a "change of 
code" in your implementation of DKIM?

>I think the way it is stated was design to avoid this.  Right?

Yes, it could be so.

An issue similar to the one in the subject line was raised in 2008 [3].

Regards,
-sm

1. http://mipassoc.org/pipermail/ietf-dkim/2010q4/015022.html
2. http://mipassoc.org/pipermail/ietf-dkim/2010q4/015063.html
3. http://mipassoc.org/pipermail/ietf-dkim/2008q2/010394.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 18 Oct 2010 12:18:39 +0100

>     o  From (REQUIRED in all signatures)
But that is weaker what what it already says, which implies saying  
"h=from" even if NO from is (contrary t0 5322) present.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Oct 2010 08:35:33 -0400

Charles, I was showing what already is written and suggesting that it 
might need clarification.

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Oct 2010 09:25:56 -0400

SM wrote:
> I'll comment on how I read what the WG Chairs said in general terms.  If 
> you believe that the process followed is not fair, you could discuss the 
> matter with the WG Chairs.  I'll quote a message from a WG Chair [1]:

SM, I think you made a correlation I did not expect.

> There is, for example, a "should" in the text you quoted and some people 
> may nit about it.  Would the above text force a "change of code" in your 
> implementation of DKIM?
> 

That is all I wanted to point out or ask about.

My original text did not try to make any additional Verifier 
requirement even though I knew that that is what is required because 
DKIM failed or at least inadequately envision the mixed TXT issues.

I'm not saying the text below should be used, but to point out it was 
addressed as a DNS management guideline.

I was trying to appease the IETF procedure here but not saying 
anything more about a verifier needs to do.  But technically I do 
agree that we should be more specific and as Murray wrote

     "Verifiers should expect this to occur and plan accordingly."

I was just wondering is this was going to be a contentious point.

Again, the posted issue was about the mixed TXT issue.  I understood 
that DKIM was not specific regarding dealing with mixed TXT.  What I 
don't know if that was on purpose, a presumption that was well 
understood a verifier will look for v=DKIM1 or just fell through the 
crack.  In any case, I didn't want to post an issue that would add 
more requirements, but simply highlight for DNS management people to 
not make it difficult for DKIM adopters.

But I think that might not be good enough and we might need to go 
ahead and add text about a verifier looking for the right string in a 
merged TXT response, just like SPF specification provides for its 
implementators.

I am just wondering if you guys (the editors) recognize what appears 
to be a technical need conflicted with "IETF procedure" time lines to 
get this doc "out the door."

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 10:06:14 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Friday, October 15, 2010 7:14 PM
> Cc: [email-masked]

OpenDKIM returns a syntax error in both cases.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 10:10:07 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Delany
> Sent: Friday, October 15, 2010 11:19 PM
> Subject: Re: [ietf-dkim] DKIM and patents
> 
> > US PATENT 7487217 http://www.docstoc.com/docs/57449330/Network-
> Domain-Reputation-based-Spam-Filtering---Patent-7487217
> >

I'm not sure the PTO wouldn't just decide they're orthogonal.  DK and DKIM are about identity and authorization, not reputation.

Having been through the patent process, I can say for sure it's a lot of buzzword bingo anyway in terms of eligibility and enforcement.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Oct 2010 11:51:56 +0100

On Mon, 18 Oct 2010 18:06:14 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

>> From: [email-masked]  
>> [mailto:[email-masked]] On Behalf Of John Levine

And to complete the picture, what does it do when verifying?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Oct 2010 09:47:02 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Wednesday, October 20, 2010 3:52 AM
> To: DKIM

I'm not sure what you think "both" meant, but I meant it as "when signing and when verifying".  I don't know of any other DKIM operating modes.