Subject: [ietf-dkim] New Issue: Why is s= REQUIRED?

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Mar 2006 09:54:49 +0000

I don't personally see why s= is REQUIRED and has no default. Perhaps
an explanation in section 3.5 would be good? Otherwise why not define
a default selector?

S.

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

---

From: Mark Delany <[email-masked]>
Date: Thu, 16 Mar 2006 15:41:39 +0000

> an explanation in section 3.5 would be good? Otherwise why not define

Technically no reason. But it may instill the assumption that most
domains will only ever generate and used one key, since a sensible
(and recommended) key roll-over will require a selector name.

Having said that, I'm not sure that assumption is invalid for the
bazillion domain that send a minute amount of email, such as most
vanity/personal domains.

There is a secondary, albeit minor effect with having a default
Selector. And that's discovery. Generally, no one can guess a valid
Selector unless they receive mail from a domain. If a default is
allowed, and deployment becomes widespread, an unrelated third party
has a good chance of guessing your Selector by testing for the
default.

I'm not sure I see a problem with that as easy discovery is under
control of the domain owner, so I'm merely observing the ability to
observe.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Mar 2006 09:27:08 -0800

> an explanation in section 3.5 would be good? Otherwise why not define

And why not define a default domain and a default ...

Some things really should not have defaults.  A primary name string is one of them.

d/
-- 

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Mar 2006 10:16:16 -0800

>an explanation in section 3.5 would be good? Otherwise why not define

Semantically, requiring a selector doesn't make much sense. From an 
interop standpoint, however, it does help. We are telling people that 
the domain name to look up begins with a selector. If we make that 
optional, we have to add more text about what the domain name will 
look like without a selector, and have examples of both. It may seem 
a bit lazy, but requiring a selector means fewer options for the 
protocol.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html