IPv6 isn't SMTP

Thu Mar 27 00:12:49 UTC 2014

On Wed, Mar 26, 2014 at 5:16 PM, Blake Hudson <blake at 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