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

On 10/6/11 6:48 AM, Keith Moore wrote:
> > Perhaps you need to re-examine your understanding of how DNSBLs actually 
> > operate.
> 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.
Keith,

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?
-Doug