Daniel Taylor wrote the following on 3/26/2014 7:45 AM:
On 03/25/2014 11:18 PM, John Levine wrote:
3. Arguing about IPv6 in the context of requirements upon SMTP
connections is playing that uncomfortable game with
one�s own combat boots. And not particularly productive.
If you can figure out how to do effective spam filtering without
looking at the IP addresses from which mail arrives, you will be in a
position to make a whole lot of money.
But, as always, I'm not holding my breath.
R's,
John
PS: Note the word "effective".
You look at the IP, and verify forward and reverse DNS.
IPv6 doesn't make this any harder a problem than IPv4, it just means
that we're going to *have* to reject mail that comes in from IPv6
addresses that don't have clean DNS.
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.
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 (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. 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 for most folks to
address it on their own at L3 rather than trying to get everyone to
agree on a new/better way to send email messages.
--Blake