Subject: [v6ops] Thoughts on email reputation

From: Fred Baker <[email-masked]>
Date: Mon, 24 Apr 2017 10:04:12 -0700

Raising a new topic...

I recently read https://sendgrid.com/blog/where-is-ipv6-in-email/, which expresses concern about using IPv6 for email, specifically in the area of blocking spam. He notes that most reputation systems today block an IPv4 /32, and is concerned that blocking an IPv6 /128 will be ineffective. His proposed solution: block a source domain, based on the reputation of the domain and the fact that we now have domain signatures. He notes that blocking domains will be a big step for reputation systems, as they don't do anything of the kind today.

I'm with him on blocking domains that originate spam. I do note the fairly common practice (of porn and malware shops) of reserving a domain and using it, deciding whether it is worthwhile, and then releasing it before it has to be paid for. I'm told that there is an entire industry that churns through domain names pretty rapidly, and consider that this might simply flood the reputation systems. I'm also concerned about proportionality, as described in https://en.wikipedia.org/wiki/Proportionality_(law)#European_Union_law.

I'm also with him on blocking /128s; my biggest issue is with temporary addresses, which I understand Windows and MacOS, and probably Linux, use for sessions they originate, reserving permanent addresses for DNS and services one might access using it. If we are blocking addresses that send spam, it seems like they might change every 24 hours.

However, it seems likely to me that a system that changes its address daily likely changes its /64 infrequently, when it moves. If it is fixed, the /64 will be as well; if it is used by a human being, it is likely to use a relatively small set of prefixes, not just prefixes at random. So a spam source might tarnish a prefix at home and another prefix at work, but not an arbitrary number of prefixes.

So, just a thought, how about we ask the reputation services to talk about reputations for /64? That would be a relatively small step away from their current model of reputations for addresses, and might be both (more) proportional and equivalently effective.

---

From: Gert Doering <[email-masked]>
Date: Mon, 24 Apr 2017 19:52:24 +0200

Hi,

On Mon, Apr 24, 2017 at 10:04:12AM -0700, Fred Baker wrote:
> So, just a thought, how about we ask the reputation services to
> talk about reputations for /64? That would be a relatively small
> step away from their current model of reputations for addresses,
> and might be both (more) proportional and equivalently effective.

My thinking has always been to do a staggered approach - start with /128s,
if you see "more than one bad egg", down-rate the whole /64, and trickle
that upwards - so eventually, a whole /32 would have a bad reputation 
if the spammer decides to just rotate addresses in that /32 quickly.

For a start, reputation for /64 is better than /128 :-) - but I think
it's not sophisticated enough.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Philip Homburg <[email-masked]>
Date: Mon, 24 Apr 2017 20:10:16 +0200

In your letter dated Mon, 24 Apr 2017 10:04:12 -0700 you wrote:
>I recently read https://sendgrid.com/blog/where-is-ipv6-in-email/, which expre
>sses concern about using IPv6 for email, specifically in the area of blocking 
>spam. He notes that most reputation systems today block an IPv4 /32, and is co
>ncerned that blocking an IPv6 /128 will be ineffective. His proposed solution:
> block a source domain, based on the reputation of the domain and the fact tha
>t we now have domain signatures. He notes that blocking domains will be a big 
>step for reputation systems, as they don't do anything of the kind today.
>
>I'm with him on blocking domains that originate spam. I do note the fairly com
>mon practice (of porn and malware shops) of reserving a domain and using it, d
>eciding whether it is worthwhile, and then releasing it before it has to be pa
>id for. I'm told that there is an entire industry that churns through domain n
>ames pretty rapidly, and consider that this might simply flood the reputation 
>systems. I'm also concerned about proportionality, as described in https://en.
>wikipedia.org/wiki/Proportionality_(law)#European_Union_law.

I'll stay out of the blocking domains can of worms. 

If we look at IPv4, you can block individual /32s. But if you get a lot of
spam from a certain network, then it makes sense to look at announced prefixes
and block those.

The thing here is that it is the local policy of the block list. Lists that
want to be conservative block a /32. Or maybe a /24. Aggressive block lists
block everything related to an AS, or possibly even an upstream AS. Or all
resources allocated to a country, etc.

This is exactly the same in IPv6. Except that a /24 in IPv4 might be a /64
or a /56 or /48, or even bigger. That requires some experience to figure
out what is what.

Where IPv6 creates a new technical issue is if a spammer can allocated
arbitrary new IPv6 addresses in a /64. If a spammer can assign a new
IPv6 address to each individual spam, then it is possible that the DNS lookups 
overload caches, resulting in more load on the DNS servers of the block list.

There is somewhere a complex proposal to encode prefixes in DNS and use
that for block lists.

For myself, I implemented a scheme that first tries to look up the
first 64 bits of an address and then the full IPv6 address. Then any
/64 will result in a cache hit.

>So, just a thought, how about we ask the reputation services to talk about rep
>utations for /64? That would be a relatively small step away from their curren
>t model of reputations for addresses, and might be both (more) proportional an
>d equivalently effective.

So the technical challenge is to implement a DNSBL lookup scheme that scales.
We should leave the policy of what to block exactly to the individual
block lists.