Subject: [ietf-dkim] Issue 1576: Revise wildcard discussion

From: Stephen Farrell <[email-masked]>
Date: Fri, 04 Jul 2008 13:03:23 +0100

Issue description: https://rt.psg.com/Ticket/Display.html?id=1576

Thread: http://mipassoc.org/pipermail/ietf-dkim/2008q2/010387.html

ssp-04 did revise the wildcard text, but not exactly as suggested
in the issue, nor am I clear about whether the new text satisfies
the couple of people (Eliot, Frank) who commented in the thread.

However, given that ssp-04 made changes along the lines suggested
if there's no further discussion I'll ask Eliot to close this one
on July 11.

S.

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 5 Jul 2008 03:21:25 +0200

> the couple of people (Eliot, Frank) who commented in the thread.

The version in ssp-04 IMO misses the following wildcard TXT points:
(1) There is no explicitly specified way to identify an ADSP record,
    when it comes as one of several TXT records in a q=txt reply.
    In the terminology of an IAB draft ADSP defines no TXT subtype.
(2) Even if ADSP would do this a set of wildcard TXT records for 
    various purposes (compare RFCs 1464, 4406, 4408, and 3920bis)
    might be too long for UDP.
(3) As a consequence of (1) ADSP likely doesn't work for wildcards.
    As a consequence of (2) the WG apparently refused to fix (1). 
    A simple "MUST start with 'dkim='" (or similar) could fix it.

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Sat, 05 Jul 2008 13:12:41 +0200

>      In the terminology of an IAB draft ADSP defines no TXT subtype.

The authors have chosen the DKIM style of using _adsp.domain, which 
effectively provides for subtyping.  Do you not believe that is 
sufficient?  I'll argue that the use of _adsp is actually better in that 
you don't have to parse through a bunch of crap to get to the 
appropriate record (normally).  You still need the code checks, of course.

>      might be too long for UDP.

And so I don't see how this holds, given the above.

>      A simple "MUST start with 'dkim='" (or similar) could fix it.

But to what end?  In what circumstance would a wildcard that stops at an 
existing label be at all useful?  This is where I have been bashing my head.

Eliot

---

From: John Levine <[email-masked]>
Date: 5 Jul 2008 12:36:07 -0000

>existing label be at all useful?  This is where I have been bashing my head.

Let's pretend that we want to try to tell the world that we don't send
mail from all the subdomains we don't send mail from:

*.foo.com. mx 0 .  	                ; MX says no mail
*.foo.com. txt "v=spf1 -all"            ; SPF says no mail
*.foo.com. txt "spf2.0/mfrom,pra -all"  ; Sender ID says no mail
*.foo.com. txt "dkim=discardable"       ; ADSP says no mail

So you can look up the MX or TXT for plugh.foo.com and get answers,
and you can also look up _adsp._domainkey.plugh.foo.com, only you get
the same answers.

Plan A: forget that silly prefixed name stuff and add yet another
magic string to tell our records apart from the other umpteen strings
that will soon overflow our 512 byte buffer.

Plan B: note that DNS wildcards, once again, don't do what you want
particularly when prefixed names are involved.  This issue is not
unique to ADSP and affects DKIM keys as well.

I believe we chose Plan B.

R's,
John

---

From: [email-masked] (Wietse Venema)
Date: Sat, 5 Jul 2008 08:35:37 -0400 (EDT)

> appropriate record (normally).  You still need the code checks, of course.

This _adsp subtyping does not work with wildcards, unless one has
a DNS server implementation that supports wildcards in the middle
such as _adsp.domainkey.*.example.com.

	Wietse

---

From: Eliot Lear <[email-masked]>
Date: Sat, 05 Jul 2008 16:53:57 +0200

> such as _adsp.domainkey.*.example.com.

I don't know what you mean by domainkey in this example, but assuming 
you meant that you'd like to implement somerthing like a new RR for  
*.domain, again I ask: to what end?  To protect non-existent domains?  
The only case covered is the analogous wildcard MX, and in this case 
adding a TXT tag doesn't actually solve the problem.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 05 Jul 2008 15:33:42 +0100

Can I ask those who think that the current text is not sufficient
to please suggest alternative text?

Thanks,
S.

PS: Eliot - since this one has attracted discussion, it should not
be closed by default on July 11.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 5 Jul 2008 17:15:38 +0200

Eliot Lear wrote:
 
> The authors have chosen the DKIM style of using _adsp.domain,
> which effectively provides for subtyping.  Do you not believe
> that is sufficient?

It's fine for *ordinary* ADSP records, but issue #1576 is about
the somewhat odd case of *wildcard* ADSP records.   

> But to what end? 

To the end of figuring out which of several *wildcard* TXT
records is about ADSP.

> This is where I have been bashing my head.

Maybe you missed the point *where* the wildcards are used, it's
not at _adsp._domainkey.example.com, where they would do nothing
useful, as you said.

If they are at all used it's directly at the domain in parallel
to an existing MX wildcard (or A or AAAA).  E.g. in parallel to
the existing wildcard *.claranet.de MX record.

That has already a wildcard TXT record beginning with v=spf1,
or it had that when I last checked it.  The draft (ssp-04)
says that you cannot add an ADSP wildcard, because a q=txt
for say _adsp._domainkey.xyzzy.claranet.de would then return
two TXT records, and ADSP does not know which of the two is
about ADSP.  SPF has no trouble to find its v=spf1 in this
case, SPF is only lost if two TXT records begin with v=spf1.

 Frank

---

From: Jim Fenton <[email-masked]>
Date: Sat, 05 Jul 2008 10:45:42 -0700

>     A simple "MUST start with 'dkim='" (or similar) could fix it.

There is a potential issue when looking up ADSP for a non-existent 
subdomain of a domain having a wildcard TXT record (such as an SPF 
record).  For example, if there is a wildcard TXT record for 
*.example.com, and the domain nonexistent.example.com does not exist at 
all (there are no RRs of any type associated with the label 
'nonexistent'), then the lookup for 
_adsp._domainkey.nonexistent.example.com will return the wildcard 
record(s).  It would therefore be desirable to have some indicator in 
the TXT record that this is, indeed, a DKIM ADSP record.  A requirement 
such as (3) for both publication and checking of the start of the record 
should do the job.

I'm not too worried about (2).  If there is an ADSP record, it will take 
precedence over any wildcard record(s) and be returned in its place.  
The only use of wildcards by ADSP is defined in section 6.3 which says 
that multiple wildcard TXT records produce an undefined ADSP result.  
I'm not sure that has to be the case if we define a TXT subtype as 
above, but in any case I'd discourage the publication of wildcard ADSP 
records, even though they might work in some instances described in 
section 6.3.

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 6 Jul 2008 16:59:49 +0200

> to please suggest alternative text?

"ADSP records always start with 'dkim=', syntax:
 record   = "dkim=" strength *[ FWS pair ] [FWS]
 strength = "unknown" / "all" / "discardable"
 pair     = name [FWS] "=" [FWS] value
 name     = ALPHA [*( ALPHA / "-" ) ALPHA ]
 value    = 1*<VCHAR>
   
 Each <name> has to be registered and can be used at most once in a
 record.  A <name> is cases-insensitive.  The special <name> "dkim"
 is required and used in the form "dkim=unknown, "dkim=all", or
 dkim=discradable" to start an ADSP record."

Later in the wildcard section replace the "ADSP won't work" blurb
with the real problem:  "Depending on the size of all wildcard TXT
records combined the DNS reply won't fit into an UDP datagram, and
might not make it to the party interested in the ADSP TXT record."

Add a reference to the wildcard RFC 4592, see also this related 
thread:  <http://thread.gmane.org/gmane.ietf.dkim/10528>
'Documenting "why" the horse is dead'

 Frank

---

From: John Levine <[email-masked]>
Date: 6 Jul 2008 15:41:09 -0000

>"ADSP records always start with 'dkim=', syntax:

There aren't enough bulldozers in the world to drain this swamp.

>might not make it to the party interested in the ADSP TXT record."

No kidding.  The IETF has so far carefully avoided the disreputable
practice of inventing faux record types by subtyping TXT with a prefix
string.  (SPF and Sender-ID don't count, being experimental.)  It's an
awful idea for a variety of reasons, starting with the non-existence
of a prefix registry and most importantly that every newly defined
prefix would increase the chance of overflow, thereby breaking the
users of existing prefixes.

Were we to do this, we'd get the spec kicked back with advice telling
us that if we want a new RR type, define one.  And they'd be right.

It's a well known and well documented limitation of _prefix names that
they don't play well with DNS wildcards.  That's life, it's not going
to change.

R's,
John

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 6 Jul 2008 19:37:55 +0200

> There aren't enough bulldozers in the world to drain

s/always/MUST/ is a cheap bulldozer.  Add a SHOULD NOT
for wildcards.  See the relevant RFC 4408 section 3.1.5,
"not recommended" + "discouraged", at this time RFC 4592
was still a draft.  But the SPF folks knew those drafts.
 
>> "Depending on the size of all wildcard TXT records 
>>  combined the DNS reply won't fit into an UDP datagram,
>>  and might not make it to the party interested in the
>>  ADSP TXT record."
 
> No kidding.  The IETF has so far carefully avoided the
> disreputable practice of inventing faux record types by
> subtyping TXT with a prefix string.  (SPF and Sender-ID
> don't count, being experimental.)

SPF got its own record type, in theory the IETF -- ignoring
the missing Last Call and the bogus status -- danced around
the issue.  And "subtyping" SPF DNS records works to some
degree.  It's no brilliant new idea, other DNS record types
have similar features.

If you have a SHOULD NOT for wildcards the "protocol police"
can't get you.  After a "MUST start with dkim=" limited to
this case ADSP could work as far as TXT wildcards can work.

The UDP issue isn't as hot as it was four years ago, EDNS0
is expected to work today, e.g., for IPv6.

> starting with the non-existence of a prefix registry

For the reasons you have noted there never will be a prefix
registry for TXT records.  There will be a registry for SPF
records as soon as somebody invents a new SPF subtyppe.  Or
if the author of the spf-options draft bothers to post a new
version of his I-D after with very simple conclusions about
two years of "experiments" with five subtypes plus an option
instead of precisely two subtypes without option.

Of course that won't help you for ADSP TXT records.  But you
don't need a subtype registry for the SHOULD NOT fine print.

> every newly defined prefix would increase the chance of
> overflow, thereby breaking the users of existing prefixes.

When publishers violate a SHOULD NOT they need to be aware 
why they do this, and of the limitations.  It is entirely
their problem, for SPF they can limit the TXT record usage
with wildcard TXT "v=spf1 redirect=elsewhere.example" (33
bytes in this example, let's say 120 bytes for two fairly
long xn--whatever.example redirects for both SPF and PRA).

> Were we to do this, we'd get the spec kicked back with 
> advice telling us that if we want a new RR type, define
> one.  And they'd be right.

The WG decided against subtyping SPF records for various
reasons.  And it wants the _adsp below _domainkey feature
for valid reasons in the case of ordinary (non-wildcard)
records.  Anybody trying to kick WG decisions documented
in several tickets from different folks (Dave + me, IIRC)
has a problem.  

Phil posted a complete superwildcard draft to tackle this
issue, it's not that "we" (TINW) have no ammo if somebody
riding his hobby horse tries to play polo with ADSP.

 Frank

---

From: John Levine <[email-masked]>
Date: 6 Jul 2008 18:33:40 -0000

>s/always/MUST/ is a cheap bulldozer.

Actually, I was referring to the swamp of prefixed TXT records.  As I
noted before, adding a prefix isn't the hard part, managing a
potentially unlimited sinkhole full of them is.

R's,
John

PS: SPF, being only experimental, isn't an interesting precedent.  A
reserved RR type doesn't make it any less experimental.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 6 Jul 2008 21:45:03 +0200

John Levine wrote:
 
> I was referring to the swamp of prefixed TXT records.

The SPF part of this zoo clearly needs a major cleanup,
the wannabe-"experimental" phase ended in April 2008.

> adding a prefix isn't the hard part, managing a

ACK, we agree that this zoo will never get a manager
wrt to TXT records.  IOW folks creating such wildcard
records have to manage this for their specific goals.
If they missed "not recommended" + "discouraged" it is
their problem.
 
> SPF, being only experimental, isn't an interesting 
> precedent.

The SPF folks submitted the draft for PS and IETF Last
Call, the IESG decided experimental without Last Call.
At that time there were about a dozen implementations,
and about a million of domains with an SPF policy.  As
far as "running code" and deployment go that was clear
enough.

The technical point is that this is *no* precedent for 
subtyping TXT, SPF got its own DNS record type.  You
are nevertheless free to say that ADSP records have to
start with dkim=, and readers are then free to figure
out that this is compatible with RFC 1464 among others.

And unsurprisingly RFC 4406 managed to be incompatible
with RFC 1464 among others.  But we know that RFC 4406
records don't start with dkim=, and we can ignore it.

> A reserved RR type doesn't make it any less 
> experimental.

And I'd bet that there were at least ten more popular
IETF protocols than SPF in the history of the Internet.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 7 Jul 2008 10:37:23 -0700

On Jul 4, 2008, at 5:03 AM, Stephen Farrell wrote:

> ssp-04 did revise the wildcard text, but not exactly as suggested in  
> the issue, nor am I clear about whether the new text satisfies the  
> couple of people (Eliot, Frank) who commented in the thread.
>
> However, given that ssp-04 made changes along the lines suggested if  
> there's no further discussion I'll ask Eliot to close this one
> on July 11.

Suggesting a wildcard domain to publish ADSP records is ill advised.  
The current ADSP draft fails to stipulate a syntax for host names,  
other than to mention case insensitive per RFC2821, or that RFC2821  
procedures _MAY_ be used to verify existence.

Ironically, declaring which transport protocol is asserted by ADSP  
records has been described as "mission creep" by some.  This  
indifference means there is _no_ guiding basis regarding valid domain  
name syntax.  There is a normative reference to RFC2822, where RFC2822  
uses an example of RFC2821 as to where a domain might be specified.   
Nevertheless, RFC2822 permits "atext" within the domain name.  As  
such, a domain such as "chosen.*.example.com, or  
"chosen._domainkey.example.com" would be valid.  Permitting these  
names defeats synthesizing ADSP records which, if relied upon, would  
then become a significant security hole.   Omission of any relevant  
public transport permits critical security aspects to be overlooked.

A "valid" domain depends upon the transport protocol, however, in the  
case of ADSP, no transport is defined!  When dealing with domains at  
the MUA, where DKIM validation, and therefore ADSP, might be applied,  
non-DNS based domains _are_ legitimately exchanged using non-SMTP  
transports.  One example would be MS Exchange.  Although it is  
unlikely any other public exchange transport other than RFC2821 will  
initially include DKIM signatures, this transport is not mentioned  
within the ADSP draft as providing a basis for conformance  
expectations.  There is also no mention of what might happen to  
converted messages carried by other transports then introduced into  
SMTP.

As a result, ADSP offers no guidance as to what TLD domains might be  
used to bypass conformance requirements.  For example, ".nntp",  
".local", or ".invalid" might offer a means to request exceptions to  
expectations asserted by ADSP records.  It also seems that getting  
exceptional TLDs defined now is important due to policy changes being  
proposed by ICANN.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 07 Jul 2008 14:59:09 -0700

> users of existing prefixes.

I agree that subtyping is something to be avoided; it's one of the 
reasons that ADSP records go into the _adsp._domainkey subdomain of the 
subject domain.  But wildcard TXT records do exist, and we have seen 
them (typically wildcard SPF records) returned in response to DKIM key 
queries and we will get them in response to ADSP queries for 
non-existent domains as well.

That being the case, requiring that ADSP records always start with 
something distinctive such as 'dkim=' would allow an ADSP checker to 
quickly ignore an unintended TXT record.

Doesn't it make sense to add the requirement for efficiency, not for 
subtyping reasons?

-Jim

---

From: "John Levine" <[email-masked]>
Date: 7 Jul 2008 18:07:01 -0400

> That being the case, requiring that ADSP records always start with something 
> distinctive such as 'dkim=' would allow an ADSP checker to quickly ignore an 
> unintended TXT record.

Well, maybe.  There's plenty of other ways a record can be ill-formed.

*.foo.example TXT "dkim=none dkim=discard"
*.foo.example TXT "dkim=a total crock nobody is gonna use"

> Doesn't it make sense to add the requirement for efficiency, not for 

It's hard for me to imagine that the cost of scanning a few dozen bytes of 
TXT record is going to be perceptible, and I'd rather not introduce new 
rules that are likely to encourage people to jump to unwarranted 
conclusions, e.g., that anything that starts with dkim= is valid.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Mon, 07 Jul 2008 15:14:03 -0700

> *.foo.example TXT "dkim=a total crock nobody is gonna use"
Of course I didn't mean to imply that checking the first five bytes of 
the ADSP record was going to guarantee validity of the rest of it.  The 
key word in my statement above was "unintended".

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 7 Jul 2008 17:46:23 -0700

> key word in my statement above was "unintended".

Section 4.1 will be problematic when ADSP records are concurrent with  
other TXT records also published at a wildcard domain.
,---
|A domain MUST NOT publish more than one ADSP record; the
|semantics of an ADSP lookup that returns multiple ADSP
|records for a single domain are undefined.
'---

The ADSP record is _any_ TXT record that exists below _adsp._domainkey  
domain prefixes.  While the "dkim=" tag is required, it could be  
anywhere within the record.

When a domain attempts to shield address records from being considered  
a valid source for unsigned messages, including the _domainkey prefix  
as well can be considered detrimental since this will increase zone  
size and administrative efforts.  In addition, for smaller domains,  
whenever the _domainkey zone is delegated to a third-party email  
provider, ADSP will also be controlled.  When separate domains below  
the _domainkey are delegated to enable use of multiple third-party  
providers, or to isolate ADSP control, then the third-party provider  
remains reliant upon the domain to publish the ADSP record, or to  
separately delegate the _adsp prefix as well.

ADSPs records below _adsp.<Author Domain> can be delegated, or  
controlled separately in the same manner as the _domainkey record.   
Placing the ADSP record below additional prefixes provides little  
benefit, especially when tag placement for the required dkim= tag is  
mandated as beginning the record.  Concerns related to potential TXT  
record confusion is reduced to an even greater degree than that  
provided by the additional prefixes since these prefixes offer no  
isolation for wildcard domains.  In addition, placing _adsp below  
_domainkey simply wastes an additional 11 bytes of payload.  Why  
attempt to optimize domain delegations for adsp records?  MX records  
are also likely involved when dealing with third-party providers.   
Unlike DKIM public key roll-over, there should be little reason for  
ongoing changes to ADSP records once established.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 08 Jul 2008 11:13:05 +0100

> procedures _MAY_ be used to verify existence.

Sure (though it might have been appropriate if the WG had agreed to  
REQUIRE the existence of an MX record as you had urged).

However, that is not the problem we are discussing. The case of interest  
in this thread is where the domain does NOT publish an ADSP record and has  
no intention of doing so. However, for some totally unrelated purpose it  
has published a wildcard that results in enquirers receiving a response  
when when they ask for a text record at the appropriate _adsp.whatever.  
The TXT record they receive will have nothing whatsoever to do with ADSP,  
and verifiers need to detect this state of affairs quickly and not waste  
time trying to parse it as an ADSP record. Having all genuine ADSP records  
start with some string such as "dkim=" will make such checks easier  
(though not foolproof because even a randomly created TXT record could  
start with "dkim-", though with low probability :-) ).

-- 
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: Stephen Farrell <[email-masked]>
Date: Tue, 08 Jul 2008 11:52:19 +0100

So, trying to get to closure on this, rather than go
'round and 'round. There seem to be 3 things being
discussed here, as listed below.

Even if you disagree and think there's a 4th thing - please
hold your fire until we bottom out on these three.

We'd like to close out on these things by Friday (11th) so
if you do care, you need to suggest text asap. If some
suggested text seems to be getting a bunch of +1's then we
won't be v. strict about that deadline, but if nothing is
getting support then I think we'll declare victory on this
one then.

Thing 1:

Charles Lindsey (and others) wrote (things like):
> Having all genuine ADSP records  

I think the counter John is making is that parsing the entire
ADSP record is equally easy, so his argument as I read it is that
the above is an optimization that isn't worthwhile.

Is it really significantly better/easier to check starts-with("dkim=")
rather than matches(the-ABNF-from-4.2.1")? The ABNF from 4.2.1. is:
             adsp-dkim-tag = %x64.6b.69.6d *FWS "=" *FWS
                             ("unknown" / "all" / "discardable")

(If responding, please ignore the [FWS] vs. *FWS issue.)

If you think the optimization is worthwhile, please post
text (and not discussion) and we'll see if that gets +1's
or -1's or gets ignored (at this stage I think the latter
two are the same). If you do post text for that please put
"dkim=" in the subject as well as 1576.

Thing 2:

Currently ssp-04 says that "ADSP records use the "tag=value"
syntax..." and also says that only one ADSP record is to be
published.

So if that means that records returned because of wildcards that
don't match eactly one instance of the ABNF are ignored then we seem
to be ok. If however, the current text isn't explicit enough about
how to handle records that don't parse correctly, or multiple records
then maybe there's more to say.

If you think there is, then please post text (and not discussion)
and we'll see if that gets +1's or -1's or gets ignored (at this
stage I think the latter two are the same).  If you do post text
for that please put "handling" in the subject as well as 1576.

Thing 3:

The last thing that seems to be involved in this thread is a
concern that the current description of the dangers of wildcards
is not sufficiently well explained. If you think that that is
the case then please post text (and not discussion)
and we'll see if that gets +1's or -1's or gets ignored (at this
stage I think the latter two are the same). If you do post text
for that please put "caveats" in the subject as well as 1576.

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Jul 2008 14:18:11 +0100

Sorry, Bill, I meant to ask those who wanted change to
propose new text. In each case if the new text proposed
gets a sufficient bunch of +1's then we go from there,
but if not, we stay as-is.

Stephen.

[email-masked] wrote:
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Tuesday, July 08, 2008 6:52 AM
> To: DKIM
> Subject: Re: [ietf-dkim] Issue 1576: Revise wildcard discussion
> 
>

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 8 Jul 2008 16:35:38 +0200

> Thing 1:
[...]
> text (and not discussion)

~~~ old ~~~
= It is possible to add a wildcard TXT record alongside a
= wildcard MX that will provide suitable ADSP records for
= any domain chosen by an attacker, since if the wildcard
= synthesizes chosen-name.example.com IN MX, it will then
= also synthesize _adsp._domainkey.chosen-name.example.com
- IN TXT.  However multiple wildcard TXT records produce
- an undefined ADSP result, which means you cannot also
- publish both ADSP records and records for any other
- TXT-using protocol (such as SPF) for a wildcard domain.
~~~ new ~~~
= It is possible to add a wildcard TXT record alongside a
= wildcard MX that will provide suitable ADSP records for
= any domain chosen by an attacker, since if the wildcard
= synthesizes chosen-name.example.com IN MX, it will then
= also synthesize _adsp._domainkey.chosen-name.example.com
+ IN TXT.  This practice is NOT RECOMMENDED, as it might
+ not work as expected in the presence of multiple TXT
+ records for different purposes.  When publishers try it
+ anyway, the ADSP record MUST start with "dkim=" followed
+ by one of the registered Outbound Signing Practices as
+ specified in section 5.2.
~~~ end ~~~

Remove (missing) three-letter acronym expansion for SPF.
Remove (missing) informative RFC 4408 reference.
Add (missing) informative RFC 4592 reference used in 6.3.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 8 Jul 2008 16:40:42 +0200

[...]
> If you do post text for that please put "caveats" in the
> subject as well as 1576.

~~~ old ~~~

 Frank

---

From: <[email-masked]>
Date: Tue, 8 Jul 2008 08:55:33 -0400

-----Original Message-----

Thing 1:

Thing 2:

Thing 3:

Thanks,
S.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 8 Jul 2008 11:11:17 -0700

On Jul 8, 2008, at 7:40 AM, Frank Ellermann wrote:

> + records for different purposes.

Good up to:

> When publishers try it

This provides little benefit unless the record syntax is changed
to offer a reliable defence. The [] denotes an addition made to
the Record Syntax.

4.2.1. Record Syntax
  ADSP records use the "tag=value" syntax described in section 3.2 of
  [RFC4871].

  Tags used in ADSP records are described below [and MUST immediately
  begin with the "dkim=" tag.]

> Add (missing) informative RFC 4592 reference used in 6.3.

Agreed.

---

From: John Levine <[email-masked]>
Date: 8 Jul 2008 19:34:42 -0000

>syntax..." and also says that only one ADSP record is to be

In earlier versions it was possible to have multiple SSP/ADSP records.
I didn't understand what multiple records would mean (nor I think did
anyone else) so I adjusted the wording to say at most one record.

I agree that the current wording doesn't explicitly say anything
about tourists, TXT records that show up but aren't planning to do
any work in our context.  Given that it's pretty well understood in
the DNS community that wildcards and _prefix names don't play well
together, I don't see it as urgent to reiterate that here, particularly
since our reiteration would risk being inconsistent with discussions
elsewhere.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 9 Jul 2008 09:32:17 -0700

On Jul 9, 2008, at 3:21 AM, Charles Lindsey wrote:

> On Tue, 08 Jul 2008 19:11:17 +0100, Douglas Otis <dotis@mail- 
> abuse.org> wrote:
>
> +1
> +1
> (or +1 to any similar improvements that acheive these same effects).
>

This was poorly worded since the subject does not agree with must.

4.2.1. Record Syntax

Tags used in ADSP records are described below.  [The record MUST
immediately begin with the "dkim=" tag].

-Doug