Re: [ietf-dkim] Escaping things in key/ADSP records

2009-08-03 Thread Tony Hansen
It could put in a heading of "Unrecognized tag X=" for each such tag.

Tony Hansen
t...@att.com

Steve Atkins wrote:
> On Aug 3, 2009, at 9:13 AM, Murray S. Kucherawy wrote:
> 
>>> -Original Message-
>>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
>>> boun...@mipassoc.org] On Behalf Of Steve Atkins
>>> Sent: Sunday, August 02, 2009 6:34 PM
>>> To: DKIM WG
>>> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
>>>
>>> [...]
>> Nice work!  However:
>>
>>> If anyone has good (or known bad) records that it gets wrong I'm
>>> interested to hear about it.
>> It reports the contents of medusa3._domainkey.blackops.org as  
>> invalid which is not correct.  That record contains an "r=" and an  
>> "rs=" tag, both of which are defined by active I-Ds.  Those tags may  
>> be unknown to RFC4871, but that specification says such should  
>> merely be ignored; they don't render the record invalid.
> 
> For typical DKIM users though, commenting on an invalid field as "This  
> is probably invalid, but there might be an experimental I-D that's  
> using it, so maybe it's OK and receivers may or may not ignore it" is  
> going to be far more confusing than "This is wrong, fix it." - as if  
> they're using "r=" it's probably a typo or a misunderstanding, rather  
> than intentional use of an experimental field.
> 
> You're intentionally using non-standard or experimental fields - so  
> you know better than the mechanical validator, and that's OK.
> 
> (If we were to add a form on dkim.org that points to the checker, that  
> might be the place to discuss what it considers valid and what it  
> doesn't.)
> 
> It might be interesting to have an alternate checker that tracks the  
> additional fields being discussed in active I-Ds too, though. Is there  
> a registry of experimental fields or list of I-Ds anywhere?
> 
> Cheers,
>Steve
> 
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-08-03 Thread Michael Thomas
On 08/03/2009 09:13 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
>> boun...@mipassoc.org] On Behalf Of Steve Atkins
>> Sent: Sunday, August 02, 2009 6:34 PM
>> To: DKIM WG
>> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
>>
>> [...]
>
> Nice work!  However:
>
>> If anyone has good (or known bad) records that it gets wrong I'm
>> interested to hear about it.
>
> It reports the contents of medusa3._domainkey.blackops.org as invalid which 
> is not correct.  That record contains an "r=" and an "rs=" tag, both of which 
> are defined by active I-Ds.  Those tags may be unknown to RFC4871, but that 
> specification says such should merely be ignored; they don't render the 
> record invalid.

An active I-D does not a standard make ;-)

But yeah, it should probably just tag them as unknown/ignored-by-4871 rather 
than an error.

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-08-03 Thread Steve Atkins

On Aug 3, 2009, at 10:28 AM, Murray S. Kucherawy wrote:
>>
>>
>> For typical DKIM users though, commenting on an invalid field as  
>> "This
>> is probably invalid, but there might be an experimental I-D that's
>> using it, so maybe it's OK and receivers may or may not ignore it" is
>> going to be far more confusing than "This is wrong, fix it." - as if
>> they're using "r=" it's probably a typo or a misunderstanding, rather
>> than intentional use of an experimental field.
>
> How about: "The following tags are non-standard and will likely be  
> ignored by most verifiers"?
>
> Some of Tony's examples such as "h=rsa-sha1" can certainly be  
> reported as "invalid" as they are standardized tags with illegal  
> values (i.e., the legal values are enumerated).
>
>> It might be interesting to have an alternate checker that tracks the
>> additional fields being discussed in active I-Ds too, though. Is  
>> there
>> a registry of experimental fields or list of I-Ds anywhere?
>
> Alas, no.  And it would be difficult, I think, to try to corral  
> people into using one in general (though the audience is currently  
> pretty small so for now it's a practical idea).

Ah.

If there's no registry of fields then there's nothing to say that a  
receiver isn't experimenting with an r= field that's completely  
different to the r= field that Tony is publishing. So it isn't safe to  
assume that a receiver that isn't using Tony's definition of r= will  
ignore his r= field, rather we're solidly into undefined behavior and  
something that is definitely an error in a production record (as  
opposed to a record used for pre-arranged testing with a specific  
receiver).

Cheers,
   Steve

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-08-03 Thread Murray S. Kucherawy
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Steve Atkins
> Sent: Monday, August 03, 2009 9:59 AM
> To: DKIM WG
> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
> 
> For typical DKIM users though, commenting on an invalid field as "This
> is probably invalid, but there might be an experimental I-D that's
> using it, so maybe it's OK and receivers may or may not ignore it" is
> going to be far more confusing than "This is wrong, fix it." - as if
> they're using "r=" it's probably a typo or a misunderstanding, rather
> than intentional use of an experimental field.

How about: "The following tags are non-standard and will likely be ignored by 
most verifiers"?

Some of Tony's examples such as "h=rsa-sha1" can certainly be reported as 
"invalid" as they are standardized tags with illegal values (i.e., the legal 
values are enumerated).

> It might be interesting to have an alternate checker that tracks the
> additional fields being discussed in active I-Ds too, though. Is there
> a registry of experimental fields or list of I-Ds anywhere?

Alas, no.  And it would be difficult, I think, to try to corral people into 
using one in general (though the audience is currently pretty small so for now 
it's a practical idea).

-MSK

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-08-03 Thread Steve Atkins

On Aug 3, 2009, at 9:13 AM, Murray S. Kucherawy wrote:

>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
>> boun...@mipassoc.org] On Behalf Of Steve Atkins
>> Sent: Sunday, August 02, 2009 6:34 PM
>> To: DKIM WG
>> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
>>
>> [...]
>
> Nice work!  However:
>
>> If anyone has good (or known bad) records that it gets wrong I'm
>> interested to hear about it.
>
> It reports the contents of medusa3._domainkey.blackops.org as  
> invalid which is not correct.  That record contains an "r=" and an  
> "rs=" tag, both of which are defined by active I-Ds.  Those tags may  
> be unknown to RFC4871, but that specification says such should  
> merely be ignored; they don't render the record invalid.

For typical DKIM users though, commenting on an invalid field as "This  
is probably invalid, but there might be an experimental I-D that's  
using it, so maybe it's OK and receivers may or may not ignore it" is  
going to be far more confusing than "This is wrong, fix it." - as if  
they're using "r=" it's probably a typo or a misunderstanding, rather  
than intentional use of an experimental field.

You're intentionally using non-standard or experimental fields - so  
you know better than the mechanical validator, and that's OK.

(If we were to add a form on dkim.org that points to the checker, that  
might be the place to discuss what it considers valid and what it  
doesn't.)

It might be interesting to have an alternate checker that tracks the  
additional fields being discussed in active I-Ds too, though. Is there  
a registry of experimental fields or list of I-Ds anywhere?

Cheers,
   Steve

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-08-03 Thread Murray S. Kucherawy
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Steve Atkins
> Sent: Sunday, August 02, 2009 6:34 PM
> To: DKIM WG
> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
> 
> [...]

Nice work!  However:

> If anyone has good (or known bad) records that it gets wrong I'm
> interested to hear about it.

It reports the contents of medusa3._domainkey.blackops.org as invalid which is 
not correct.  That record contains an "r=" and an "rs=" tag, both of which are 
defined by active I-Ds.  Those tags may be unknown to RFC4871, but that 
specification says such should merely be ignored; they don't render the record 
invalid.

-MSK

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-08-03 Thread Tony Hansen
Excellent job. Perhaps a pointer to this can go on the dkim.org site?

Tony Hansen
t...@att.com

Steve Atkins wrote:
> On Jul 31, 2009, at 2:02 PM, Steve Atkins wrote:
> 
>> (This may be a duplicate, I have too many email addresses)
>>
>> On Jul 31, 2009, at 12:08 PM, Scott Kitterman wrote:
>>
>>> On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen  wrote:
 I'm wondering if there is a need for a web interface at dkim.org  
 that
 would validate someone's _domainkey TXT record.

>>> I'd say yes.  It would provide a good way to isolate record  
>>> specific issues
>>> from other potential problems people are having error sources when
>>> troubleshooting.
>> I have some perl code that does some validation for internal use; it'd
>> be fairly easy to turn it into a webapp.
> 
> http://dkimcore.org/tools/dkimrecordcheck.html
> 
> Given a selector and a domain it'll slurp the record from DNS.
> 
> Then it parses it, using the BNF from the spec (why, oh,
> why do we support FWS in a DNS record?) and then
> sanity checks the various fields and gives a good / bad message.
> 
> If anyone has good (or known bad) records that it gets wrong I'm
> interested to hear about it.
> 
> Cheers,
>Steve
> 
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-08-02 Thread Steve Atkins

On Jul 31, 2009, at 2:02 PM, Steve Atkins wrote:

> (This may be a duplicate, I have too many email addresses)
>
> On Jul 31, 2009, at 12:08 PM, Scott Kitterman wrote:
>
>> On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen  wrote:
>>> I'm wondering if there is a need for a web interface at dkim.org  
>>> that
>>> would validate someone's _domainkey TXT record.
>>>
>> I'd say yes.  It would provide a good way to isolate record  
>> specific issues
>> from other potential problems people are having error sources when
>> troubleshooting.
>
> I have some perl code that does some validation for internal use; it'd
> be fairly easy to turn it into a webapp.

http://dkimcore.org/tools/dkimrecordcheck.html

Given a selector and a domain it'll slurp the record from DNS.

Then it parses it, using the BNF from the spec (why, oh,
why do we support FWS in a DNS record?) and then
sanity checks the various fields and gives a good / bad message.

If anyone has good (or known bad) records that it gets wrong I'm
interested to hear about it.

Cheers,
   Steve

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-08-01 Thread Tony Hansen
Jim Fenton wrote:
> If you still have the records, can you count the number of records
> with g=; ? That's used in an example in some of the DomainKey specs
> and works for DK but means "match nothing" for DKIM.

I was planning on doing an analysis of the key values anyway, so here goes.

65461 DNS _domainkey records were examined that did not contain syntax 
errors. Of these, 37309 were used by DKIM and 46623 were used by 
DomainKeys. (Some were used by both.) Of them, 2186 have v=DKIM1.

 mistakes 
As noted before, there were a number of mistakes found within the key 
records. I found occurrences of all of these
DKIM=unknownO=- a=rsa-sha1
c=nofws c=relaxed/relaxed
d=SOMEDOMAINdkim=alli=*
kv=DKIM1o=- o=~
q=dns

If I trim the list down to the v=DKIM1 records, there are STILL errors:
c=relaxed/relaxed   o=-

There are a few records that have r=EMAIL values in them.

 legal keys 

== g= ==

The following valid g= values were used by DKIM:

g=
g=*
g=noreply

For v=DKIM1 records, it's just

g=*
g=noreply

This confirms the suggestion a couple meetings ago that vendors should 
treat g= as equivalent to g=* if v=DKIM1 is not found.

There were NO cases of g=; found for v=DKIM1 records.

== h= ==

The following valid h= values were used by DKIM. All of these were in 
v=DKIM1 records:

h=sha1
h=sha1:sha256
h=sha256

A notable mistake was an entry with this value:
h=rsa-sha1

== k= ==

The following valid k= values were used by DKIM.

k=rsa

A notable mistake was an entry with this value:

k=rsa-sha1

It was NOT the same record as the similar h= mistake.

== n= ==

1879 of the records used n=.

== s= ==

The value
s=email
was used in 33 records, 31 along with v=DKIM1.

== t= ==

The following valid t= values were used by DKIM.

t=s
t=s:y
t=y
t=y:s

Of note are these two mistakes:
t=n
t=s|y


Hope people found this of interest.

Tony Hansen
t...@att.com
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-07-31 Thread Steve Atkins
(This may be a duplicate, I have too many email addresses)

On Jul 31, 2009, at 12:08 PM, Scott Kitterman wrote:

> On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen  wrote:
>> I'm wondering if there is a need for a web interface at dkim.org that
>> would validate someone's _domainkey TXT record.
>>
> I'd say yes.  It would provide a good way to isolate record specific  
> issues
> from other potential problems people are having error sources when
> troubleshooting.

I have some perl code that does some validation for internal use; it'd
be fairly easy to turn it into a webapp.

Cheers,
   Steve

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-07-31 Thread Murray S. Kucherawy
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Scott Kitterman
> Sent: Friday, July 31, 2009 12:09 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
> 
> On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen  wrote:
> >I'm wondering if there is a need for a web interface at dkim.org that
> >would validate someone's _domainkey TXT record.
>
> I'd say yes.  It would provide a good way to isolate record specific
> issues
> from other potential problems people are having error sources when
> troubleshooting.

A verifier equipped with additional code to email sites whose keys or policy 
records contain errors might be useful.  Then again, it might also be obnoxious.

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-07-31 Thread Scott Kitterman
On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen  wrote:
>I'm wondering if there is a need for a web interface at dkim.org that 
>would validate someone's _domainkey TXT record.
>
I'd say yes.  It would provide a good way to isolate record specific issues 
from other potential problems people are having error sources when 
troubleshooting.

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-07-31 Thread Jim Fenton
Tony,

If you still have the records, can you count the number of records with
g=; ?  That's used in an example in some of the DomainKey specs and
works for DK but means "match nothing" for DKIM.

-Jim

Tony Hansen wrote:
> Mark Martinec wrote:
>  > John Levine wrote:
>  >> It is certainly the kind of bug that occurs in PHP scripts when the
>  >> programmer doesn't perfectly understand the quoting rules.  It's
>  >> happened to me.
>  >
>  > I'm collecting a set of common mistakes breaking DKIM signatures.
>
> Pulling up a message from a while ago. Mark, did you ever get further 
> with your set of common mistakes?
>
> I had occasion to look at a number of DNS key records, and find the 
> following common mistakes:
>
> Sample size: 65456 DNS _domainkey (DKIM+DK) records
>
> 16missing semi-colons between fields
> 1 missing any separators (k=rsap=)
> 14invalid quotation marks (") surrounding the entire record
> 2 invalid \" surrounding the entire record
> 5 invalid parens or paren+quotes surrounding the entire record
> 47\-quoted characters, particularly \;
> 9 TTL value or other random DNS data showing up in the record
> 1 TTL value being in the record instead of the public key
> 17random characters in the record, e.g. {, CRLF, backspace, SUB, >
> 113   SPF records being returned
> 13key only, no p= or any other options
> 1 encoded ; as %3B
> 1 missing tag before =
> 8 other data in record (dkim=all, O=-, r=, &, ")
> 1 v=DKIM1 not first field in record
> 50other random errors
> ---
> 299
>
> I was not able to verify if any of the keys that had spaces within them 
> were actually valid keys or not.
>
> The good news is that of the sample, the majority of the records were 
> just fine.
>
> I'm wondering if there is a need for a web interface at dkim.org that 
> would validate someone's _domainkey TXT record.
>
> Thoughts?
>
>   Tony Hansen
>   t...@att.com
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>   
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Escaping things in key/ADSP records

2009-07-31 Thread Tony Hansen
Mark Martinec wrote:
 > John Levine wrote:
 >> It is certainly the kind of bug that occurs in PHP scripts when the
 >> programmer doesn't perfectly understand the quoting rules.  It's
 >> happened to me.
 >
 > I'm collecting a set of common mistakes breaking DKIM signatures.

Pulling up a message from a while ago. Mark, did you ever get further 
with your set of common mistakes?

I had occasion to look at a number of DNS key records, and find the 
following common mistakes:

Sample size: 65456 DNS _domainkey (DKIM+DK) records

16  missing semi-colons between fields
1   missing any separators (k=rsap=)
14  invalid quotation marks (") surrounding the entire record
2   invalid \" surrounding the entire record
5   invalid parens or paren+quotes surrounding the entire record
47  \-quoted characters, particularly \;
9   TTL value or other random DNS data showing up in the record
1   TTL value being in the record instead of the public key
17  random characters in the record, e.g. {, CRLF, backspace, SUB, >
113 SPF records being returned
13  key only, no p= or any other options
1   encoded ; as %3B
1   missing tag before =
8   other data in record (dkim=all, O=-, r=, &, ")
1   v=DKIM1 not first field in record
50  other random errors
---
299

I was not able to verify if any of the keys that had spaces within them 
were actually valid keys or not.

The good news is that of the sample, the majority of the records were 
just fine.

I'm wondering if there is a need for a web interface at dkim.org that 
would validate someone's _domainkey TXT record.

Thoughts?

Tony Hansen
t...@att.com
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Escaping things in key/ADSP records

2008-10-30 Thread Mark Martinec
John Levine wrote:
> It is certainly the kind of bug that occurs in PHP scripts when the
> programmer doesn't perfectly understand the quoting rules.  It\'s happened
> to me.

I'm collecting a set of common mistakes breaking DKIM signatures.

Mentioning a web interface to DNS and PHP brings the following to mind:

$ host -t txt default._domainkey.biofeedbackinternational.com
 "k=rsa\;
  p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAOr7pvAlT3y3qLf3zusWTjo5xI8yHSoj
  rS0nq bYpD1wEwroTAoqMOy2laMFEVC2Wr7G 0GAMN9XkH5dpBQQtnFj REbwc6sku
  6NJGPRB  IzNW iHrZ bcOtrHBgudeWwIDAQAB\;"

Note that each '+' in a published base64-encoded p tag has been
converted into a space, as per URI decoding rules. Naturally their
signatures fail, but nobody cares.

  Mark

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2008-10-30 Thread Bill.Oxley
Is there any chance that this is an OS inspired edit? Perhaps the web
front end has a built in escape clause

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Olivier MJ
Crepin-Leblond
Sent: Thursday, October 30, 2008 4:22 AM
To: John Levine; ietf-dkim@mipassoc.org
Cc: [EMAIL PROTECTED]
Subject: Re: [ietf-dkim] Escaping things in key/ADSP records

+1

Many ISPs do not input records directly into the zone files. Their front
end is often a
web-based interface and get pre-processed by a system checking validity
before being
updated in the zone file automatically using script(s).
My ISP (as in, I am a client of theirs), one of the largest in the US,
had to migrate my
domain to their new nameservers because the legacy ones could not cope
with the ; and the
underscore (_). Thankfully I took this up with them early enough for the
new nameservers
to have a front end allowing those characters, but it looks like they've
used the
backslash...

Aside from the aesthetics of the record, does the escape affect
functionality?

Olivier

- Original Message - 
From: "John Levine" <[EMAIL PROTECTED]>
To: 
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 30, 2008 12:52 AM
Subject: Re: [ietf-dkim] Escaping things in key/ADSP records


> >DNS TXT records can contain multiple strings which we just
concatenate to
> >form a complete key record.  That part's easily managed.  However
some
> >people have taken it upon themselves to escape semi-colons for some
> >reason, presumably because some programs like "dig" do that in their
> >output, which in turn is done perhaps to disambiguate a literal
semi-colon
> >with one that starts a comment in a zone file.
>
> I find it hard to see this as anything other than a bug in whatever
> scripts they're using to create their DNS records.  The DNS has counts
> for all variable length fields, so there's never a need to escape
> anything in the bits on the wire.
>
> R's,
> John
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html

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

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2008-10-30 Thread John Levine
> Is there any chance that this is an OS inspired edit? Perhaps the web
> front end has a built in escape clause

It is certainly the kind of bug that occurs in PHP scripts when the 
programmer doesn't perfectly understand the quoting rules.  It\'s happened 
to me.

R's,
John

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Olivier MJ
> Crepin-Leblond
> Sent: Thursday, October 30, 2008 4:22 AM
> To: John Levine; ietf-dkim@mipassoc.org
> Cc: [EMAIL PROTECTED]
> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
>
> +1
>
> Many ISPs do not input records directly into the zone files. Their front
> end is often a
> web-based interface and get pre-processed by a system checking validity
> before being
> updated in the zone file automatically using script(s).
> My ISP (as in, I am a client of theirs), one of the largest in the US,
> had to migrate my
> domain to their new nameservers because the legacy ones could not cope
> with the ; and the
> underscore (_). Thankfully I took this up with them early enough for the
> new nameservers
> to have a front end allowing those characters, but it looks like they've
> used the
> backslash...
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Escaping things in key/ADSP records

2008-10-30 Thread Tony Hansen
duly noted

Tony Hansen
[EMAIL PROTECTED]

Murray S. Kucherawy wrote:
> On Thu, 30 Oct 2008, John L wrote:
>> A reasonable concern, but it seems to me that the best response is to 
>> educate people about how to create valid DKIM setups.  Early in the life 
>> of SPF there used to be a lot of broken SPF records, but eventually 
>> people got the hang of setting them up.
> 
> So, is this an appropriate topic for the deployment document?  Seems like 
> we're in agreement.

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2008-10-30 Thread Olivier MJ Crepin-Leblond
+1

Many ISPs do not input records directly into the zone files. Their front end is 
often a
web-based interface and get pre-processed by a system checking validity before 
being
updated in the zone file automatically using script(s).
My ISP (as in, I am a client of theirs), one of the largest in the US, had to 
migrate my
domain to their new nameservers because the legacy ones could not cope with the 
; and the
underscore (_). Thankfully I took this up with them early enough for the new 
nameservers
to have a front end allowing those characters, but it looks like they've used 
the
backslash...

Aside from the aesthetics of the record, does the escape affect functionality?

Olivier

- Original Message - 
From: "John Levine" <[EMAIL PROTECTED]>
To: 
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 30, 2008 12:52 AM
Subject: Re: [ietf-dkim] Escaping things in key/ADSP records


> >DNS TXT records can contain multiple strings which we just concatenate to
> >form a complete key record.  That part's easily managed.  However some
> >people have taken it upon themselves to escape semi-colons for some
> >reason, presumably because some programs like "dig" do that in their
> >output, which in turn is done perhaps to disambiguate a literal semi-colon
> >with one that starts a comment in a zone file.
>
> I find it hard to see this as anything other than a bug in whatever
> scripts they're using to create their DNS records.  The DNS has counts
> for all variable length fields, so there's never a need to escape
> anything in the bits on the wire.
>
> R's,
> John
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html

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


Re: [ietf-dkim] Escaping things in key/ADSP records

2008-10-29 Thread Murray S. Kucherawy
On Thu, 30 Oct 2008, John L wrote:
> A reasonable concern, but it seems to me that the best response is to 
> educate people about how to create valid DKIM setups.  Early in the life 
> of SPF there used to be a lot of broken SPF records, but eventually 
> people got the hang of setting them up.

So, is this an appropriate topic for the deployment document?  Seems like 
we're in agreement.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Escaping things in key/ADSP records

2008-10-29 Thread John Levine
>DNS TXT records can contain multiple strings which we just concatenate to 
>form a complete key record.  That part's easily managed.  However some 
>people have taken it upon themselves to escape semi-colons for some 
>reason, presumably because some programs like "dig" do that in their 
>output, which in turn is done perhaps to disambiguate a literal semi-colon 
>with one that starts a comment in a zone file.

I find it hard to see this as anything other than a bug in whatever
scripts they're using to create their DNS records.  The DNS has counts
for all variable length fields, so there's never a need to escape
anything in the bits on the wire.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Escaping things in key/ADSP records

2008-10-29 Thread John L
>> I find it hard to see this as anything other than a bug in whatever scripts 
>> they're using to create their DNS records.  The DNS has counts for all 
>> variable length fields, so there's never a need to escape anything in the 
>> bits on the wire.
>
> People who know the protocol would obviously agree, but I'm not certain 
> everyone pasting these things into zone files has knowledge like that. 
> They're more likely to follow scripts or examples they find online.

Indeed.  That's why it's important to stamp out this kind of mistake 
earlier rather than later.

> Why "dig" decided to start rendering semi-colons as escaped in their output, 
> when they're not explicitly so in the zone file or on the wire, is currently 
> a mystery to me.  I'm just concerned that it will confuse some people tasked 
> with deployment somewhere down the line.

A reasonable concern, but it seems to me that the best response is to 
educate people about how to create valid DKIM setups.  Early in the life 
of SPF there used to be a lot of broken SPF records, but eventually people 
got the hang of setting them up.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Escaping things in key/ADSP records

2008-10-29 Thread Murray S. Kucherawy
On Wed, 29 Oct 2008, John Levine wrote:
> I find it hard to see this as anything other than a bug in whatever 
> scripts they're using to create their DNS records.  The DNS has counts 
> for all variable length fields, so there's never a need to escape 
> anything in the bits on the wire.

People who know the protocol would obviously agree, but I'm not certain 
everyone pasting these things into zone files has knowledge like that. 
They're more likely to follow scripts or examples they find online.

But in fact it's even less of a problem than I feared.  Some local testing 
shows the following two TXT records in a regular bind zone file are 
semantically equivalent in the current implementation:

IN  TXT "foo;bar"
IN  TXT "foo\;bar"

The RFCs about zone files are unfortunately ambiguous on the backslash. 
They only specify that backslash can be used to escape a quotation mark 
inside a quoted string.  They don't say what backslash means in any other 
context.

Why "dig" decided to start rendering semi-colons as escaped in their 
output, when they're not explicitly so in the zone file or on the wire, is 
currently a mystery to me.  I'm just concerned that it will confuse some 
people tasked with deployment somewhere down the line.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html