Eric points out, correctly, that issue 1534 fell through the cracks when I was preparing the slides for last week's meeting, so we didn't discuss it. I had intended it to go into the "medium" category, but we shouldn't close it without the opportunity for some discussion.
The text of the item from the tracker is: > > http://mipassoc.org/pipermail/ietf-dkim/2007q4/008437.html > > >> s The signing practices apply only to the named domain, and not > >> to subdomains. > > > > So this is intended to overcome the problem of not being able to use > wildcards? > > > > What is the query behavior that validators need to use, to discover this > > record, when they start with a message having a deeply-nested From field > > domain name? > > > To the extent that the above is not sufficiently clear: > > There is not way to properly enforce or even discover the semantics of > this flag, in the general case of sub-domains. This option needs to > removed or be specified in a way that works. My response is that the upward query, and the t=s flag (which provides a way to limit the application of ASP outside the immediate domain) are not intended to cover subdomains. Rather, they provide a way to cover terminal leaf nodes within the domain (e.g., hostnames) that can be used as domains (in the 2822 sense) in email addresses. While the need to cover this hole exists primarily as a consequence of the use of hostnames (vs. MX records) as email delivery points, this problem can't be solved by requiring MX records for domains publishing ASP, as was suggested in Issue 1547. Suppose that a message from blarney.example.com was being ASP checked, and we don't know anything about that domain. First you look for _asp._domainkey.blarney.example.com TXT, and if you don't find it, let's say you do an MX query for blarney.example.com, and it isn't found either. The possibility exists that blarney.example.com is a host that receives its mail using its A record, and just hasn't published an ASP record. At this point you would need to conclude, unless the MX query resulted in an NXDOMAIN error, that blarney.example.com has an "unknown" ASP. The requirement for an MX record would apply when the ASP record does exist, but in that case you wouldn't need to query for it anyway. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
