On 7/22/11 7:09 AM, O'Reirdan, Michael wrote: > Chaps > > I would like to bring to your attention and solicit comments on the > following draft. > > http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00 > > Thanks > > Mike O'Reirdan Mike,
Indeed, abuse issues represent a challenge for both IPv4 and IPv6 as these two address families merge. ISPs are rapidly moving away from IPv4 native access infrastructure and toward use of LSN to support legacy IPv4 services. However LSN inhibits use of IP Address reputation when shared simultaneously across hundreds of customers. The size of IPv6's current rapidly growing assignments makes vetting its entirety daunting, especially as IPv4 services move to IPv6 to retain server connectivity. To control abuse, end-to-end authentication is needed as a reliable basis in which to assess behaviors of specific services. Unfortunately, while DKIM potentially could help identify spoofed messages, DKIM's lack of header field validation minimizes even this role. In addition, abuse is normally defined in terms of unsolicited actions. DKIM fails to confirm the target of a solicitation. As such, reputations based upon DKIM using an unsolicited basis would make domains prone when reputation is not associated with a specific service end point. As such, authentication at the SMTP level is more appropriate. Perhaps DANE will remove possible cost impediments associated with the use of certificates. An authentication process is needed to fast-track (white-list based upon the authenticated service) source IP addresses. Neither DKIM nor SPF (due to amplification concerns) safely supports such a fast-tracking process. When based upon domains being authenticated, there would not be any scaling advantage using b-tree structures that are not well suited for DNS. IMHO, use of http://tools.ietf.org/html/rfc3123 referenced by the authenticated service domain provides a more reasonable strategy, since DNS is not well suited to handle large volumes of textual lists. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
