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