On 4/4/11 7:47 AM, John R. Levine wrote: > ... kludges to work around short term deployment problems are rarely > a good way to do long term standards development. The problems go > away, but the kludges don't.
Why are A and AAAA records used to locate mail servers and not limit discovery to just MX records? The reasoning was to allow simple installation of email without a need for "special" DNS resources. This improvised "ease of deployment" method now requires searching for A, AAAA and MX records, which then means any host can be considered a target or a purported source of abusive email. How long will this improvised discovery method remain? Adding to the improvised discovery problem, there are now two punycode conversions, the 2003 and 2008 version, along with Asian and local domains using UTF-8 directly. How long will the improvised punycode method remain? After all, resolving a domain expects both punycode AND UTF-8 to be attempted where aliases might also be discovered. It seems RFC5321 continued use of improvised punycode and failed to clarify what form an alias might take. From the outset I opposed the g= component of the key, and the i= portion of the signature. Nevertheless there remains a need for a convention able to opaquely identify internal sources for reporting and abuse tracking purposes. Adding headers separate from the signature obfuscates a relationship. Rather than changing code able to handle i= parameters, it would be reasonable to remove any wording that suggests this parameter offers identification, and leave this definition to be defined through extensive use. There is little experience with domain based reputation, where it is also clear that normally open IPv6 address reputations would be ineffectual at responding to abuse. Although there are potentially more domain names than their are IPv6 addresses, domain names offer a means to consolidate authority through domain hierarchy. It would also be a poorly considered improvised method to use sub-domains to sign for a domain since this would muddle authority hierarchy. A sub-domain should not claim authority over a parent domain. Keep the i= parameter and define it as being opaque. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
