On Wed, Mar 26, 2014 at 5:16 PM, Blake Hudson <blake@ispn.net> wrote:
With this in mind, how hard is it for a spamming operation to setup rDNS for their IPv6 ranges? Not very hard, just like their ability to use SPF or DKIM (they will do it if it improves their deliverability). This is separate from infected bots on residential connections, which is effectively dealt with today through the PBL or some basic rDNS checks since practically everyone has rDNS in IPv4.
[snip] There are plenty of residential connections, and enterprise non-mail server connections, that PBL is no good for. As far as i'm concerned.... if you can force the spammer to use their own IP range, that they can setup RDNS for, then you have practically won, for all intents and purposes, as it makes blacklisting feasible, once again! Spammers can jump through these hoops --- but spammers aren't going to effectively scale up their spamming operation by using IP address ranges they can setup RDNS on. I would argue that less than 100% of spammers for sure would make the shift from compromising as many IP addresses as possible and turning them into mail servers. Following that.... what's really left is: misconfigured mail servers allowing open relays, and mail users that fall to phishing or pick easy to guess passwords. (Spammer intruding upon and co-oping mailboxes that are legitimate in the first place.)
Having rDNS doesn't automatically make you a good guy. SMTP operators will still have the need for reputation based services. Due to the design of the SMTP protocol
Indeed it doesn't, but it's highly suggestive. *I would rather rDNS be augmented with a registration of intent to run a mail server that can verifiably be linked to whomever is authorized contact for the IP space.
(which provides little protection for abuse on its own), people chose to place additional checks at L3. I see this as a deficiency in SMTP that we were fortunate enough to solve in an IPv4 landscape (after a lot of initial concern about RBLs and their operators), but is going to be harder to to utilize the same tool as effectively in IPv6.
It will be immensly harder.
The problem is with SMTP and is probably best addressed in the application layer through updates to SMTP or required bolt-ons (e.g SPF or similar); it was just simpler
SPF is useful, but not a complete solution. I'm curious what form you think these updates to SMTP would take? What changes to SMTP protocol itself could really have a meaningful impact, without frustrating, confusing, or terribly complicating the lives of millions of mail users?
--Blake
-- -JH