[Top] [All Lists]

Re: The anti-abuse rDNS check that FTP gave up

2011-10-06 14:43:39

On 10/6/11 6:48 AM, Keith Moore wrote:
Perhaps you need to re-examine your understanding of how DNSBLs actually 
I understand them quite well.  It's called dilution of responsibility.  It's a 
great mechanism for causing harm while escaping blame.  The destination MTA 
blames the RBL, the RBL blames the MTA, the end users get screwed.

IMHO, the strongest motivator for changing email stems from a provider's desire to redirect complaints elsewhere. As a result, schemes like DKIM allow any number of signatures that also fail to capture either who sent the message or their intended recipients. From a domain name perspective, these missing details cut both directions, in either dodging responsibility or in allowing actions beyond their control held against them by a reputation service. With the uncertainty involved, challenges by large domains are likely to find issues resolved in their favor. The same applies for SPF, where such records authorize the shared providers. With no certainty which message element selects SPF records, or what assurances were offered to assure against SPF related spoofing, it would be risky to even use SPF as a basis for directing feedback, rather than depending upon who controls the IP address. Of course, this also ignores DDoS threats related to SPF macro processing.

MAPS attempted to categorize the entire IPv4 address space, often in conjunction with assistance from larger ISPs. When a large ISP emitted a significant amount of spam, they would be encouraged to share the addresses deployed for access with a ULA prohibiting public servers (the DUL), or to simply block port 25. This type of information was essential to combat spammers employing asymmetric strategies, where even modem dial-ups appeared to emit a volume normally requiring T3 connections. To assist in maintaining the DUL list, ISPs were asked how they assigned reverse DNS for this space. Conventions established better ensure against DUL listing mistakes. In the era of IPv4, these addresses were considered sufficiently limited and this permitted aggressive categorization to re-actively block abusive sources. Due to the unlimited nature of domain names, control primarily focused on IP addresses to conserve resources. That era ends with the Internet adopting IPv6.

Even MTAs refusing to accept IPv6 connections will still be affected. There are any number of translation schemes where an IPv4 address no longer represents a single entity. The announced IPv6 address prefix space, ignoring the lower 64 bits, already represents 56,000 times that of the entire IPv4 address space, and growing exponentially. It seems growth of IPv6 prefixes should flatten out at about 340,000 times that of the IPv4 address space. This increased size roughly reflects the resources that will be needed to extend reactive blocking of abusive sources.

Changing reputation to that of recognition from that of reactive blocking could dramatically reduce the resources required to convey whether a connection is likely non-abusive. For this to happen, there is a need to authenticate outbound MTAs. This might be done by using a challenge that gets signed and confirmed by a public certificate. Something like DANE seems well positioned at offering a service that could work in conjunction with both IPv6 or IPv4 environments.

With such a scheme, large providers should not have any trouble being recognized, but they will then need to deal with complaints. Hopefully, these complaints would also be shared with related customers who may have had their system compromised. What will it take to convince ISPs they need to accept this responsibility and that doing so is in their best interest?