Discussion:
DNSBL and IPv6
(too old to reply)
Mikael Abrahamsson
2012-10-19 06:22:27 UTC
Permalink
Hello.

I just subscribed to this list and tried to read up.

I'm very interested in IPv6 and SPAM, and I'd like to add some to the two last
threads here regarding DNSBL and IPv6.

Fundamentally in IPv6, a "customer" (or entity or whatever) will in a lot of
cases not a single IP address, but a network.

Households will get /64s, or get a /56 via DHCPv6-PD. Phones get a /64 or a
network via DHCPv6-PD. Companies get /48 (or something else, but a bunch of
networks). This is fundamentally how IPv6 was intended to be used, and
hopefully that's how most ISPs will deliver it to customers.

So for spam detection to happen, detection of what is a "customer" needs to
happen, and this needs to be on a network level, not single IPv6 address level.
The RIR databases (at least RIPE) contain information about what kind of
per-customer subnet size is for a certain large block of addresses.

Equivalent in IPv4 is "this customer has an IPv4 /26" and spam blocking would
be done on a per-customer level, not per unique IPv4 address.

I'm a routing guy, not MUA/MTA guy, so I have little insight in what things
look like in the real world outside of my personal setup with postfix, some
DNSBL and procmail/spamassassin.

What I feel needs to happen is that policy needs to put in place to RIRs (via
ISPs) can present "what is a customer" on a network level, and then this
information can be put into DNS somehow, and used for DNSBL.

Example:

An ISP serves 10000 households with connectivity, each household gets a /56,
this is done via an IPv6 /42 (because this is in a single town and it's
aggregated like that). So this /42 would be in some kind of "residential
access" classification, so people could block on that, and if one wants to
block unique spammers, then this needs to be identified on a /56 level.

In other places I've pitched that the RIRs would publish this information in
some kind of format outside of whois, so perhaps we need to start there, to
create a standard (I don't know who should create the standard, but agreeing
that a standard is needed is one step) for how this information is published,
is a first step.

Thoughts?
--
Mikael Abrahamsson email: ***@swm.pp.se
Matthias Leisi
2012-10-19 06:52:12 UTC
Permalink
Post by Mikael Abrahamsson
Fundamentally in IPv6, a "customer" (or entity or whatever) will in a lot of
cases not a single IP address, but a network.
At the beginning of an SMTP transaction, all you have is a single IP.
Post by Mikael Abrahamsson
Households will get /64s, or get a /56 via DHCPv6-PD. Phones get a /64 or a
network via DHCPv6-PD. Companies get /48 (or something else, but a bunch of
As a spam filter (software developer), you may want to know more about
the reputation of the IP address connecting to you.
Post by Mikael Abrahamsson
So for spam detection to happen, detection of what is a "customer" needs to
happen, and this needs to be on a network level, not single IPv6 address
level. The RIR databases (at least RIPE) contain information about what kind
of per-customer subnet size is for a certain large block of addresses.
You need an algorithm where you start from a single IP address and
then potentially "move up" until you get a meaningful result. That's
more or less what the B-tree algorithm suggested by John Levine some
months ago would offer: variable "depth" and "density" of data
controlled by the DNSxL operator optimized for the (on average) lowest
number of lookups needed.

At the same time, having a standardised and light-weight protocol to
determine the allocation policy by the ISP would be hugely helpful
(this will likely then be mirrored by the DNSxL operator). Absent such
data,third parties have to fall back to some default /64 etc.
Post by Mikael Abrahamsson
What I feel needs to happen is that policy needs to put in place to RIRs
(via ISPs) can present "what is a customer" on a network level, and then
this information can be put into DNS somehow, and used for DNSBL.
I don't know whether RIRs can mandate the publication of this data
through policy.

-- Matthias
Mikael Abrahamsson
2012-10-19 07:25:12 UTC
Permalink
Post by Matthias Leisi
Post by Mikael Abrahamsson
Fundamentally in IPv6, a "customer" (or entity or whatever) will in a lot of
cases not a single IP address, but a network.
At the beginning of an SMTP transaction, all you have is a single IP.
Yes.
Post by Matthias Leisi
Post by Mikael Abrahamsson
Households will get /64s, or get a /56 via DHCPv6-PD. Phones get a /64 or a
network via DHCPv6-PD. Companies get /48 (or something else, but a bunch of
As a spam filter (software developer), you may want to know more about
the reputation of the IP address connecting to you.
Yes, and that reputation is derived from what subnet it's a subset of.
Post by Matthias Leisi
You need an algorithm where you start from a single IP address and then
potentially "move up" until you get a meaningful result. That's more or
less what the B-tree algorithm suggested by John Levine some months ago
would offer: variable "depth" and "density" of data controlled by the
DNSxL operator optimized for the (on average) lowest number of lookups
needed.
Sounds good to me.
Post by Matthias Leisi
At the same time, having a standardised and light-weight protocol to
determine the allocation policy by the ISP would be hugely helpful
(this will likely then be mirrored by the DNSxL operator). Absent such
data,third parties have to fall back to some default /64 etc.
Yes, which will be less than effective when customers are handed /48s and
can send from anything within that /48.
Post by Matthias Leisi
Post by Mikael Abrahamsson
What I feel needs to happen is that policy needs to put in place to
RIRs (via ISPs) can present "what is a customer" on a network level,
and then this information can be put into DNS somehow, and used for
DNSBL.
I don't know whether RIRs can mandate the publication of this data
through policy.
RIPE already does (basically), as in "this /42 contains customers where
each customer has a /56". I don't know about other RIRs.
--
Mikael Abrahamsson email: ***@swm.pp.se
John Levine
2012-10-19 22:41:31 UTC
Permalink
Post by Mikael Abrahamsson
What I feel needs to happen is that policy needs to put in place to RIRs
(via ISPs) can present "what is a customer" on a network level, and then
this information can be put into DNS somehow, and used for DNSBL.
Yeah, I've been talking to people on and off about this for over a
year. Even though providers can lie about their allocation
granularity, most won't, and the ones that lie would probably merit
total blocking anyway.

A customer allocation can be anywhere from a /56 to a /64, and I
expect we'll see hosting companies with a /64 per rack or per VM host,
so you'll have different customers within the same /64.

So, uh, anyone interested in doing simulations of how this sort of
stuff would work with various DNSBL designs? I have access to IPv4
mailstream connection data we can use to calibrate it.

R's,
John
Dave Warren
2012-10-20 00:25:19 UTC
Permalink
Post by John Levine
Post by Mikael Abrahamsson
What I feel needs to happen is that policy needs to put in place to RIRs
(via ISPs) can present "what is a customer" on a network level, and then
this information can be put into DNS somehow, and used for DNSBL.
Yeah, I've been talking to people on and off about this for over a
year. Even though providers can lie about their allocation
granularity, most won't, and the ones that lie would probably merit
total blocking anyway.
I'm less worried about those that lie outright than those that just
don't care either by not bothering to specify a policy at all (unless it
becomes mandatory somehow), or have more granularity than can be clearly
specified in a single policy.

For example, their policy might be to allocate at the /64 level, but
unless they also prohibit customers from obtaining more than one /64...
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Steve Atkins
2012-10-20 00:38:16 UTC
Permalink
Post by John Levine
Post by Mikael Abrahamsson
What I feel needs to happen is that policy needs to put in place to RIRs
(via ISPs) can present "what is a customer" on a network level, and then
this information can be put into DNS somehow, and used for DNSBL.
Yeah, I've been talking to people on and off about this for over a
year. Even though providers can lie about their allocation
granularity, most won't, and the ones that lie would probably merit
total blocking anyway.
I'm less worried about those that lie outright than those that just don't care either by not bothering to specify a policy at all (unless it becomes mandatory somehow), or have more granularity than can be clearly specified in a single policy.
For example, their policy might be to allocate at the /64 level, but unless they also prohibit customers from obtaining more than one /64...
The ability for customers to obtain more than one IPv4 /32 hasn't been too complex an issue for blacklist operators to deal with. Any blacklist operator who's successfully running an IPv4 blacklist can surely come up with reasonable (or unreasonable, I won't judge…) policies for IPv6.

The only relevant difference between v4 and v6 DNS based blacklisting is that the ability to easily hop around *within* your /64 makes it possible (easy) to blow the cache of a traditional caching DNS resolver if you do naive "look up a record based on the IPv6 address".

That doesn't affect the viability of source address based blacklisting. It doesn't affect the viability of distributing that data as DNS zone files (they suck for both v4 and v6, but they're usable). And it doesn't affect the viability of using DNS as the communication channel between an MX and a local authoritative blacklist server.

But it does mean that anyone wanting a recursive resolver in their distribution path might have to refine the process a little - which is what I assume John is looking at.

(I'm betting that "mask the bottom 64 bits before querying" would work just fine, but I don't think we have enough v6 space in use yet to say for sure.)

Cheers,
Steve
Mikael Abrahamsson
2012-10-20 04:41:33 UTC
Permalink
Post by Steve Atkins
(I'm betting that "mask the bottom 64 bits before querying" would work
just fine, but I don't think we have enough v6 space in use yet to say
for sure.)
I agree. Although I believe some ISPs will put multiple customers in a
single /64, this is mostly going to be dynamic customers anyway (multiple
laptops on a wifi for instance), and those I would imagine are treated
with the same policy so it doesn't really matter. Per /64 handling is a
reasonable tradeoff between granularity and practicality in my mind.
--
Mikael Abrahamsson email: ***@swm.pp.se
Matthias Leisi
2012-10-20 06:55:37 UTC
Permalink
Post by Mikael Abrahamsson
I agree. Although I believe some ISPs will put multiple customers in a
single /64, this is mostly going to be dynamic customers anyway (multiple
laptops on a wifi for instance), and those I would imagine are treated with
the same policy so it doesn't really matter. Per /64 handling is a
reasonable tradeoff between granularity and practicality in my mind.
And cheap VPS, where the "upgrade" from /128 to /64 is used as a
differentiator (just stumbled upon such a case,
http://www.kimsufi.com/fr/vks/).

-- Matthias
Tim Chown
2012-10-22 10:26:46 UTC
Permalink
Post by Steve Atkins
(I'm betting that "mask the bottom 64 bits before querying" would work just fine, but I don't think we have enough v6 space in use yet to say for sure.)
I agree. Although I believe some ISPs will put multiple customers in a single /64, this is mostly going to be dynamic customers anyway (multiple laptops on a wifi for instance), and those I would imagine are treated with the same policy so it doesn't really matter. Per /64 handling is a reasonable tradeoff between granularity and practicality in my mind.
A /64 basis seems to be the most sensible starting point, from which one could 'suck it and see'.

In client scenarios where multiple users share a /64, e.g. in a wifi hotspot, then they are probably sharing one public IPv4 address with IPv4 NAT now.

In data centre scenarios, what do we expect there? It's not clear from draft-lopez-v6ops-dc-ipv6-03. It may depend on whether the hosting is physical or virtual? The allocated prefix is likely to be quite stable.

In home networks, the current trend in Europe seems to be /60 to /56, though some offer /64 or /48. In some cases the equipment can only handle /64 now, but expect that to shift to /56 or /60 later. The work on draft-ietf-homenet-arch-05 expects the ISP to offer multiple /64's. It seems many ISPs will vary the prefix offered over time much as with dynamic IPv4 addresses today. In some countries, that's apparently a legal requirement.

In enterprises, /48, and more likely to be stable.

Our evidence from incoming spam is that most of it comes via dual-stack list servers. There's very little evidence of spam coming from autoconfigured addresses that would indicate client senders.

Tim
Peter J. Holzer
2012-10-20 07:30:31 UTC
Permalink
Post by Steve Atkins
Post by Dave Warren
I'm less worried about those that lie outright than those that just
don't care either by not bothering to specify a policy at all
(unless it becomes mandatory somehow), or have more granularity than
can be clearly specified in a single policy.
For example, their policy might be to allocate at the /64 level, but
unless they also prohibit customers from obtaining more than one /64...
The ability for customers to obtain more than one IPv4 /32 hasn't been
too complex an issue for blacklist operators to deal with. Any
blacklist operator who's successfully running an IPv4 blacklist can
surely come up with reasonable (or unreasonable, I won't judge
)
policies for IPv6.
The only relevant difference between v4 and v6 DNS based blacklisting
is that the ability to easily hop around *within* your /64 makes it
possible (easy) to blow the cache of a traditional caching DNS
resolver if you do naive "look up a record based on the IPv6 address".
A simple (maybe naive) idea to reduce cache poisoning would be to do
some kind of greylisting before doing the lookup: If you haven't seen
the address before, simply return a temporary error. If you have seen
it (within some time window), do the lookup.

Is there a reason why a legitimate MTA (talking to MXs, not submission
servers) would want to hop around in its net?

* IPv6 privacy extensions might be turned on by default and the admin
might not bother to turn them off, but I think they are too slow to
prevent delivery (although it will slow down most mails)
* An admin of an MTA serving many customers might want to use a
different IP address for each customer. But from the outside that
would just look like one MTA per customer, not a single MTA hopping
around
Post by Steve Atkins
That doesn't affect the viability of source address based
blacklisting. It doesn't affect the viability of distributing that
data as DNS zone files (they suck for both v4 and v6, but they're
usable).
There are many more IPv6 addresses and even /64 nets than IPv4
addresses. It's theoretically possible to ship around a zone file with
/all/ IPv4 addresses (that would be less than 100GB). This isn't remotely
possible for IPv6 space. It might be possible for allocated /64 nets
depending on how they are allocated (if every cell phone gets a /48 ...).
If you go down to the /128 level, a spammer doing the hopping maneuvre
could blow up your zone file beyond any reasonable limit.
Post by Steve Atkins
And it doesn't affect the viability of using DNS as the
communication channel between an MX and a local authoritative
blacklist server.
[...]

Right.

hp
--
_ | Peter J. Holzer | Der eigene Verstand bleibt gefÃŒhlt messer-
|_|_) | Sysadmin WSR | scharf. Aber die restliche Welt blickt's
| | | ***@hjp.at | immer weniger.
__/ | http://www.hjp.at/ | -- Matthias Kohrs in desd
Bart Schaefer
2012-10-20 14:25:04 UTC
Permalink
On Oct 20, 9:30am, Peter J. Holzer wrote:
}
} Is there a reason why a legitimate MTA (talking to MXs, not submission
} servers) would want to hop around in its net?

A legitimate MTA could still be running in a dynamically-assigned space.
In this case it might hop all over the space but probably wouldn't hop
very frequently.

A single MTA host might have multiple NICs each with its own IP, and not
always choose the same interface for the same MX on retry. Here it might
hop quite a lot, but among a limited number of choices.
John Levine
2012-10-20 21:42:57 UTC
Permalink
Post by Bart Schaefer
} Is there a reason why a legitimate MTA (talking to MXs, not submission
} servers) would want to hop around in its net?
Probably not, although I'm waiting for ESPs to figure out that if they
send every message from a different IP, it'll be much easier to
process bounces and complaints since all they'll need is the IP to
figure out what the list and address was.

Bad guys could use it to listwash, of course, but it's not totally
ridiculous.

R's,
John
Peter J. Holzer
2012-10-21 21:20:40 UTC
Permalink
Post by John Levine
Post by Bart Schaefer
} Is there a reason why a legitimate MTA (talking to MXs, not submission
} servers) would want to hop around in its net?
Probably not, although I'm waiting for ESPs to figure out that if they
send every message from a different IP,
I thought of that but I wouldn't be surprised to overflow the router's
ARP table even with our moderately sized mailing-lists (a few thousand
subscribers at most). That's why I only mentioned "one address per
customer", not "one address per message" as a likely tactic.
Post by John Levine
it'll be much easier to process bounces and complaints since all
they'll need is the IP to figure out what the list and address was.
Is it? For mailing-lists, I think VERP is simpler and more robust. The
IP address is buried somewhere in the Received headers of the bounced
message, so you have to parse those. For complaints to an ISP about a
customer that might indeed be useful. Depends on what information is
included in the complaint. If it contains the complete header of the
message there is probably other identifying information. It it doesn't,
chances are that the IP address isn't included, either.
Post by John Levine
Bad guys could use it to listwash, of course, but it's not totally
ridiculous.
There are other ways to listwash. I'm more worried that the bad guys are
using rapidly changing IP addresses to escape or overflow BLs.

hp
--
_ | Peter J. Holzer | Der eigene Verstand bleibt gefühlt messer-
|_|_) | Sysadmin WSR | scharf. Aber die restliche Welt blickt's
| | | ***@hjp.at | immer weniger.
__/ | http://www.hjp.at/ | -- Matthias Kohrs in desd
John Levine
2012-10-21 22:44:06 UTC
Permalink
Post by Peter J. Holzer
Post by John Levine
Probably not, although I'm waiting for ESPs to figure out that if they
send every message from a different IP,
I thought of that but I wouldn't be surprised to overflow the router's
ARP table
Well, yes, if you configure stuff in a naive way. I'd route an entire
/64 to the mail server, and configure the server as its own router
with all of those IP addresses internally forwarded to a single IP
that talks to the outside world. If you wanted to do IP hopping,
it wouldn't be hard to do.
Post by Peter J. Holzer
Post by John Levine
it'll be much easier to process bounces and complaints since all
they'll need is the IP to figure out what the list and address was.
Is it? For mailing-lists, I think VERP is simpler and more robust.
Depends what your intentions are. If you're trying to do listwashing,
you may wall see DNSBL listings rather than bounces. I like VERP just
fine and my lists use it, but I do get back FBL reports that are
munged to the point where I can't tell who complained. But they
rarely munge the IP.

R's,
John
Peter J. Holzer
2012-10-21 21:37:08 UTC
Permalink
Post by Bart Schaefer
}
} Is there a reason why a legitimate MTA (talking to MXs, not submission
} servers) would want to hop around in its net?
A legitimate MTA could still be running in a dynamically-assigned space.
In this case it might hop all over the space but probably wouldn't hop
very frequently.
By "dynamically-assigned space" do you mean a dynamically assigned
address within a /64 (either by DHCP or by privacy extensions)? If so, I
already mentioned that and yes, I think it doesn't change fast enough to
make greylisting infeasible (but frequently enough to make it annoying).

If you mean that an ISP is assigning a different /64 to the same
customer periodically (some privacy evangelists are demanding that this
should be the default), then this would probably be done even less
frequently, and this would most likely be treated the same as
dynamically assigned space today (i.e. very likely to be a zombie, not a
legitimate MTA).
Post by Bart Schaefer
A single MTA host might have multiple NICs each with its own IP, and not
always choose the same interface for the same MX on retry. Here it might
hop quite a lot, but among a limited number of choices.
An IP stack might also choose IP addresses at random or in a round robin
fashion if the interface has several. That could be a problem.

hp
--
_ | Peter J. Holzer | Der eigene Verstand bleibt gefühlt messer-
|_|_) | Sysadmin WSR | scharf. Aber die restliche Welt blickt's
| | | ***@hjp.at | immer weniger.
__/ | http://www.hjp.at/ | -- Matthias Kohrs in desd
John Levine
2012-10-20 21:40:48 UTC
Permalink
Post by Steve Atkins
The only relevant difference between v4 and v6 DNS based blacklisting is
that the ability to easily hop around *within* your /64 makes it
possible (easy) to blow the cache of a traditional caching DNS resolver
if you do naive "look up a record based on the IPv6 address".
That's always been our assumption, but there is at this point precious
little evidence that MTAs that query DNSBL through caches (as opposed
to those who have a local rsync mirror) have a cache hit rate much
greater than zero. If in fact they don't, the same design, perhaps
with a little TTL tuning to give clients a hint about which ones are
worth caching, could work no worse than they do now for similar mail
volumes.

That's why I want to do the cache simulations, to figure out what's
going on now. It shouldn't be terribly hard, and we have people
offering data. Want to help?

R's,
John
Jeff Macdonald
2012-12-04 18:51:26 UTC
Permalink
Hi John,

I'd like to help. Let me know what I can do.
Post by John Levine
Post by Steve Atkins
The only relevant difference between v4 and v6 DNS based blacklisting is
that the ability to easily hop around *within* your /64 makes it
possible (easy) to blow the cache of a traditional caching DNS resolver
if you do naive "look up a record based on the IPv6 address".
That's always been our assumption, but there is at this point precious
little evidence that MTAs that query DNSBL through caches (as opposed
to those who have a local rsync mirror) have a cache hit rate much
greater than zero. If in fact they don't, the same design, perhaps
with a little TTL tuning to give clients a hint about which ones are
worth caching, could work no worse than they do now for similar mail
volumes.
That's why I want to do the cache simulations, to figure out what's
going on now. It shouldn't be terribly hard, and we have people
offering data. Want to help?
R's,
John
_______________________________________________
Asrg mailing list
http://www.irtf.org/mailman/listinfo/asrg
--
Jeff Macdonald
Ayer, MA
John Levine
2012-12-04 21:08:10 UTC
Permalink
-=-=-=-=-=-
-=-=-=-=-=-
Hi John,
I'd like to help. Let me know what I can do.
I think I've hooked up with some academics interested in doing analyses, so what I
need now is data. Traces from largish mail servers would be good.

All I need is [timestamp,IP address] to do DNSBL traces.

Hal Murray
2012-10-25 02:00:17 UTC
Permalink
Depends what your intentions are. If you're trying to do listwashing, you
may wall see DNSBL listings rather than bounces. I like VERP just fine and
my lists use it, but I do get back FBL reports that are munged to the point
where I can't tell who complained. But they rarely munge the IP.
People trying to avoid listwashing will learn to munge the bottom bits of any
IPv6 address.

Similarly, DNSBLs could mask off the bottom bits of any IPv6 address that
they expose.
--
These are my opinions. I hate spam.
John Levine
2012-10-25 02:48:59 UTC
Permalink
Post by Hal Murray
Depends what your intentions are. If you're trying to do listwashing, you
may wall see DNSBL listings rather than bounces. I like VERP just fine and
my lists use it, but I do get back FBL reports that are munged to the point
where I can't tell who complained. But they rarely munge the IP.
People trying to avoid listwashing will learn to munge the bottom bits of any
IPv6 address.
Well, maybe. Personally, I think the threat of listwashing is overstated.
The really slimy senders have lists so dirty that no amount of washing will
clean them.

But anyway, I'm seeing a lot of assertions about how IPv6 mail will work,
and precious little running core or simulations. As always, anyone want
to do some, you know, research?

R's,
John
Steve Atkins
2012-10-25 03:00:03 UTC
Permalink
Post by John Levine
Post by Hal Murray
Depends what your intentions are. If you're trying to do listwashing, you
may wall see DNSBL listings rather than bounces. I like VERP just fine and
my lists use it, but I do get back FBL reports that are munged to the point
where I can't tell who complained. But they rarely munge the IP.
People trying to avoid listwashing will learn to munge the bottom bits of any
IPv6 address.
Well, maybe. Personally, I think the threat of listwashing is overstated.
The really slimy senders have lists so dirty that no amount of washing will
clean them.
But anyway, I'm seeing a lot of assertions about how IPv6 mail will work,
and precious little running core or simulations. As always, anyone want
to do some, you know, research?
It's mostly dependent on how IPv6 addresses for mailservers (legitimate and
otherwise) will be allocated, and how much IPv6 will be used for inter-domain
email delivery. Do we have any data, or researched speculation, about that
to work from?

Cheers,
Steve
Paul Smith
2012-10-25 10:46:31 UTC
Permalink
Post by Steve Atkins
Post by John Levine
Post by Hal Murray
Depends what your intentions are. If you're trying to do listwashing, you
may wall see DNSBL listings rather than bounces. I like VERP just fine and
my lists use it, but I do get back FBL reports that are munged to the point
where I can't tell who complained. But they rarely munge the IP.
People trying to avoid listwashing will learn to munge the bottom bits of any
IPv6 address.
Well, maybe. Personally, I think the threat of listwashing is overstated.
The really slimy senders have lists so dirty that no amount of washing will
clean them.
But anyway, I'm seeing a lot of assertions about how IPv6 mail will work,
and precious little running core or simulations. As always, anyone want
to do some, you know, research?
It's mostly dependent on how IPv6 addresses for mailservers (legitimate and
otherwise) will be allocated, and how much IPv6 will be used for inter-domain
email delivery. Do we have any data, or researched speculation, about that
to work from?
I actually think getting any *useful* data about this would be very
tricky at the moment, if not impossible.

I know that we can't use IPv6 anywhere. We have 4 broadband connections
with different suppliers, and none support IPv6 yet, and the data centre
we use for our servers also doesn't support IPv6 yet. I guess lots of
people are in the same situation, especially smaller companies. This
probably means that spammers in general won't be using IPv6 yet - would
it be worth their hassle, given that most of their 'customers' won't
have it. So, anyone who does have IPv6 MX servers will probably just be
getting IPv6 mail from people like Google, and no one else.

So, it might be interesting to get data to see how widely IPv6 is used
for email currently, but it's unlikely to be useful data to give us
realistic ideas how spam will affect the IPv6 infrastructure in the
future. eg, there may be virtually no IPv6 spam now, but it won't stay
that way.



(My personal view is that IPv6 for widespread email use is well in the
future. There is no huge advantage over IPv4 given that the number of
MTAs is vastly smaller than the number of other Internet connected
devices. For interoperability, everyone with an MTA will NEED an IPv4
address for now. There are complexity issues especially to do with
security, hacking protection, spam filtering etc. So, I think most mail
admins will be leaving IPv6 turned off until they need to turn it on -
which may take a while, since it'll be a catch-22 situation. What may
trigger it is if someone like Google decides to turn OFF all IPv4
support in their mail infrastructure, but I think that's unlikely for
the foreseeable future...

MSAs may support IPv6 a lot sooner to support their IPv6 MUAs, but those
won't have the spam issues.

I know this isn't an 'IETF approved' viewpoint, but it's mine, based on
our customers)



-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
Martijn Grooten
2012-10-25 12:14:00 UTC
Permalink
My personal view is that IPv6 for widespread email use is well in the future.
I think you'll find few experts who think that there's an urgent need for IPv6 for email. But IPv6 is currently being used for email (Google and Comcast are among those currently accepting email over IPv6 - and these are big players) and its use could (and probably will) increase. I think it would be a rather bad idea if spammers got an easy ride if they were to send mail over IPv6.

And personally, I think it would also be bad if we told people to start using IPv6 as soon as possible, except for email because we don't really know how to do spam filtering there.

Anyway, back on topic: I'm still not convinced we'd be talking about IPv6-based blacklists if we didn't have a long and successful history of IPv4-based blacklists.

IP-blacklists work well on IPv4 because the IP-space is small enough to keep the lists small and large enough so that different IPs really mean different senders.

I haven't really seen a suggestion on how to run IPv6-based blacklists that convinced me. (That's a rather unscientific claim, I know. I'd love for people to help John with his simulation so that we get a better idea; note that he doesn't need IPv6 data. I'm afraid I don't have the required data myself.)

Can't we do something entirely different for IPv6? Like, use domain-based filtering by making it mandatory to DKIM-sign a message you send over IPv6 outside of your network? As long as IPv4 and IPv6 are running in parallel it should be possible for IPv6 MTA to refuse messages that aren't DKIM-signed - and tell the sender to retry over IPv4.

I know this isn't an ideal solution either (one weakness is that it allows you to DDoS an MTA by sending large numbers of messages with an invalid signature), but perhaps it's better than trying to make IP-blacklists work over IPv6? Or perhaps someone can come with a better X now that MTAs can still afford to tell IPv6-senders "do X or retry over IPv4".

Martijn.


________________________________

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.
Matthias Leisi
2012-10-25 12:35:30 UTC
Permalink
On Thu, Oct 25, 2012 at 2:14 PM, Martijn Grooten
Post by Martijn Grooten
I haven't really seen a suggestion on how to run IPv6-based blacklists that convinced me. (That's a rather unscientific claim, I know. I'd love for people to help John with his simulation so that we get a better idea; note that he doesn't need IPv6 data. I'm afraid I don't have the required data myself.)
I'm obviously biased since I run dnswl.org, but an IPv6-based
whitelist may work better than an IPv6-based blacklist. Enumerating
the goodness is generally easier than enumerating the badness.

(Of course, all IPv6-DNSxLs have the same risk of caches blowing up if
not done right, and the "done right" thing has not been defined yet).

-- Matthias
Emanuele Balla (aka Skull)
2012-10-25 14:37:47 UTC
Permalink
Post by Martijn Grooten
Anyway, back on topic: I'm still not convinced we'd be talking about
IPv6-based blacklists if we didn't have a long and successful history
of IPv4-based blacklists.
IP-blacklists work well on IPv4 because the IP-space is small enough
to keep the lists small and large enough so that different IPs really
mean different senders.
I haven't really seen a suggestion on how to run IPv6-based
blacklists that convinced me. (That's a rather unscientific claim, I
know. I'd love for people to help John with his simulation so that we
get a better idea; note that he doesn't need IPv6 data. I'm afraid I
don't have the required data myself.)
The point, IMHO, is that *nobody* has those data yet...

The number of available IPs will explode with IPv6. The number of
"legit" distinct emitters is (probably) not.


At the end, everything will be about how fast abusive/infected machines
will move around the address space:

1) from one IP to another inside their own /64
2) from one /64 to another
3) from one ISP to another, particularly where showshoe-like schemes are
in place


For point 1, there will be a limit to this change rate, at least when we
speak about bots, and it's even been cited here already: a single
machine can't use too many addresses without saturating its router
neighbor table.
Which is a valid esteem for the number of different IPs the
IPv6-address-change-mechanism will be able to use effectively, then?
Truth is we don't know for sure...


For point 2, then. The ability of a bot to move from a /64 to another
will depend on its ISP policies and implementation (like the ability of
a bot to change its IP in IPv4 depends mostly on how the ISP implemented
its dynamic allocation). Which is a valid esteem for that?
Again, we don't know for sure: too few examples for having consistent
statistics.

For number 3, the number of different allocations will only depend on
the number of different machines owned by the spammer, while there may
be no "neighbor limit" here, if the ISP did it right, so he/she could
make full use of the entire allocation.
But again, we lack a lot of statistics here as well...


So, at the moment, the only thing you can simulate is what we already
have in IPv4.


But the real IPv6 scenario will depend mostly on policies and
implementations that are not in place yet... :-\
Post by Martijn Grooten
Can't we do something entirely different for IPv6? Like, use
domain-based filtering by making it mandatory to DKIM-sign a message
you send over IPv6 outside of your network? As long as IPv4 and IPv6
are running in parallel it should be possible for IPv6 MTA to refuse
messages that aren't DKIM-signed - and tell the sender to retry over
IPv4.
Theoretically this could be an option, but DKIM requiring the receiving
end to receive the message DATA before choosing a policy may prove to be
a limit.
Post by Martijn Grooten
I know this isn't an ideal solution either (one weakness is that it
allows you to DDoS an MTA by sending large numbers of messages with
an invalid signature), but perhaps it's better than trying to make
IP-blacklists work over IPv6? Or perhaps someone can come with a
better X now that MTAs can still afford to tell IPv6-senders "do X or
retry over IPv4".
Could be. We just need to find out a good X then ;-)




My personal opinion, FWIW, is that the DNSxL mechanism will still be
useful in the future if we can limit the lookup to the first 64 bits
instead of the full address.
This reduces the problem to something comparable to the current state of
IPv4: it's true that default user allocations are larger than IPv4 ones
(say a /56, AKA 256 "listing units", instead of a single one like in
IPv4), but it's something we can still work with, probably...

It it true that there are (and there will be) entities out there
assigning stuff like a /112 per-user instead of a /64.
But maybe it's not too late to come out with "an X" trying to disallow
this setup for wannabe-mailservers...
--
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
Paul Smith
2012-10-25 15:37:26 UTC
Permalink
Post by Emanuele Balla (aka Skull)
For point 1, there will be a limit to this change rate, at least when we
speak about bots, and it's even been cited here already: a single
machine can't use too many addresses without saturating its router
neighbor table.
Which is a valid esteem for the number of different IPs the
IPv6-address-change-mechanism will be able to use effectively, then?
Truth is we don't know for sure...
Hmm - I've heard talk about this problem of saturating the router
neighbour table. To be honest, I'm not entirely sure what a 'neighbour
table' is... But, why would people have a /64 block if the router can't
cope with it?
Post by Emanuele Balla (aka Skull)
Post by Martijn Grooten
I know this isn't an ideal solution either (one weakness is that it
Post by Martijn Grooten
allows you to DDoS an MTA by sending large numbers of messages with
an invalid signature), but perhaps it's better than trying to make
IP-blacklists work over IPv6? Or perhaps someone can come with a
better X now that MTAs can still afford to tell IPv6-senders "do X or
retry over IPv4".
Could be. We just need to find out a good X then
Rather than using DKIM, why not use client certificates keyed off the
sender domain. That way you don't need to get the message content.

It would require TLS for all IPv6 MTA-MTA connections, but given that
'old' servers won't support IPv6, and new ones 'should' support TLS,
that shouldn't be an insurmountable problem. It would also mean that a
sending MTA couldn't send to the same target MTA using the same
connection for different sender domains. This wouldn't be a problem for
small->moderate sized MTAs.

I suppose it's only the big MTAs (google et al) who would suffer a bit
because of something like this, but then, if it cut down on the spam,
they'd probably gain more than they lost.

The problem is that certificates on their own (like DKIM) won't
necessarily reduce spam, just spoofing. So, there'd need to be some way
of linking reputation to domain, but that would be the same with DKIM.




-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
Emanuele Balla (aka Skull)
2012-10-25 16:10:52 UTC
Permalink
Post by Paul Smith
Post by Emanuele Balla (aka Skull)
For point 1, there will be a limit to this change rate, at least when we
speak about bots, and it's even been cited here already: a single
machine can't use too many addresses without saturating its router
neighbor table.
Which is a valid esteem for the number of different IPs the
IPv6-address-change-mechanism will be able to use effectively, then?
Truth is we don't know for sure...
Hmm - I've heard talk about this problem of saturating the router
neighbour table. To be honest, I'm not entirely sure what a 'neighbour
table' is...
Basically, the ARP table, except for IPv6 not using ARP at all...
Post by Paul Smith
But, why would people have a /64 block if the router can't
cope with it?
The point is a /64 allows basically an infinite number of devices in one
single network (2^64 being big enough to be considered infinite for our
purpose).

This doesn't mean a router should be able to manage an infinite amount
of devices: no router could accomplish this requirement... :-)

The router basically needs to cope with a given number of devices inside
the /64. Maybe 10, maybe 100, maybe 1000, but a limited amount, compared
to 2^64. The neighbor table must be able to keep track of IPv6-MAC
associations for each device.

But if one of these devices starts changing address quickly enough, it's
going to saturate the router memory (or only the neighbor table) at some
point...

What happens next depends on how the router will manage the issue...
--
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
Paul Smith
2012-10-25 16:28:49 UTC
Permalink
Post by Emanuele Balla (aka Skull)
Post by Paul Smith
Hmm - I've heard talk about this problem of saturating the router
neighbour table. To be honest, I'm not entirely sure what a 'neighbour
table' is...
Basically, the ARP table, except for IPv6 not using ARP at all...
OK. I know what an ARP table is :-)

The name 'neighbour table' made me think it was trying to track which
other routers were around (ie 'neighbours' of this router), which was
strange if that got upset by the number of internal addresses being
used. My mental visualisation sees the router as a 'gatekeeper', so the
internal devices would be 'occupants' or something, not 'neighbours'.
So, I visualised that 'neighbours' would be things on the same 'level'
as the router - ie other routers.

I've done a bit more reading around on the subject, and am getting there
- I think :-)

It's tricky since we have no access to any IPv6 stuff unless I use a
tunnel or an internal test network, which has always been an
"artificial" environment AFAIAC (no local router involved), so doing
full scale real-world tests isn't possible yet.
Post by Emanuele Balla (aka Skull)
The router basically needs to cope with a given number of devices inside
the /64. Maybe 10, maybe 100, maybe 1000, but a limited amount, compared
to 2^64. The neighbor table must be able to keep track of IPv6-MAC
associations for each device.
OK



-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
Scott Howard
2012-10-25 16:50:27 UTC
Permalink
Post by Paul Smith
It's tricky since we have no access to any IPv6 stuff unless I use a
tunnel or an internal test network, which has always been an "artificial"
environment AFAIAC (no local router involved), so doing full scale
real-world tests isn't possible yet.
A tunnel doesn't need to be "artifical". Hurricane Electric will give you a
free IPv6 tunnel, including a routable range (/56 from memory). Setup the
tunnel on one machine, and then configure it to be a router for your local
network (using one of the networks from the /56). All of the hosts on that
network will now have "native" IPv6. Sure, to get out of your network it
has to go via a tunnel, but that's completely transparent to the end hosts.

Keep in mind the security implications though - if you don't setup a
firewall on your IPv6 tunnel endpoint/router, then you're basically putting
any of the systems it routing traffic for directly onto the Internet, with
a public IP address.

Scott
Mikael Abrahamsson
2012-10-26 13:27:35 UTC
Permalink
Post by Emanuele Balla (aka Skull)
At the end, everything will be about how fast abusive/infected machines
1) from one IP to another inside their own /64
2) from one /64 to another
3) from one ISP to another, particularly where showshoe-like schemes are
in place
I believe it's going to be common enough that legitimate MTAs will move
around within their /64 quite frequently (privacy extensions that are
default on in Windows for instance), means outgoing IPv6 address will move
to a new outgoing address every N hours (where N is somewhere between
1-48, I don't know exactly).
--
Mikael Abrahamsson email: ***@swm.pp.se
Matthias Leisi
2012-10-26 13:32:14 UTC
Permalink
Post by Mikael Abrahamsson
Post by Emanuele Balla (aka Skull)
1) from one IP to another inside their own /64
2) from one /64 to another
3) from one ISP to another, particularly where showshoe-like schemes are
in place
I believe it's going to be common enough that legitimate MTAs will move
around within their /64 quite frequently (privacy extensions that are
Using a /64 as a default seems reasonable, but a new standard for
DNSxL lookups should provide some flexibility, either for a full list
("default prefix length = /56") or on a more granular level (using
John L.'s original proposal, or some other useful method).

-- Matthias
Paul Smith
2012-10-26 14:08:58 UTC
Permalink
Post by Matthias Leisi
Post by Mikael Abrahamsson
I believe it's going to be common enough that legitimate MTAs will move
around within their /64 quite frequently (privacy extensions that are
Using a /64 as a default seems reasonable, but a new standard for
DNSxL lookups should provide some flexibility, either for a full list
("default prefix length = /56") or on a more granular level (using
John L.'s original proposal, or some other useful method).
The problem with a /64 for black/white listing is that it's not quite
the same as an IPv4 /32. So, at the moment we may have a /25 or /26
block, but we'd still have a single IPv6 /64

We may run 50 customer dedicated mail servers on our /64 block, and
ideally we'd want each to have their own reputation. So, we couldn't do
this if DNSBL/WL filtering is on a /64 block. With our current IPv4 /26
each customer's server would have it's own reputation on an IPv4 DNSBL/WL.

Obviously we couldn't say what level of granularity we'd want, or
spammers would just say 'we want /128 granularity', to overload everything.

We could (theoretically) get a /48 block, but that would be a waste (I
know there are LOTS of /48's out there, but still), since we wouldn't
need it for routing, just for making it work with /64 based
black/whitelisting.

I can't think of a good answer to this, but our case is a use case which
isn't going to be that unusual.



-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
Paul Smith
2012-10-25 14:37:51 UTC
Permalink
Post by Martijn Grooten
Can't we do something entirely different for IPv6? Like, use domain-based filtering by making it mandatory to DKIM-sign a message you send over IPv6 outside of your network? As long as IPv4 and IPv6 are running in parallel it should be possible for IPv6 MTA to refuse messages that aren't DKIM-signed - and tell the sender to retry over IPv4
Is it even possible to tell an IPv6 sender to retry over IPv4? I know
I've seen discussion about whether it should be possible, but I'm fairly
sure it wasn't at that time (I think it should be possible)

Having a 'retry over IPv4' option would help a lot, especially if we had
a mechanism to link an IPv6 and an IPv4 attempt - could be a good way of
bootstrapping an IPv6 reputation system (or whitelist). But, I'm not
sure the IETF would approve, and it may be too late anyway...

I do think that (with hindsight) IPv6 support for MTAs could have done
with more thought before it was standardised. Things like requiring DKIM
(or SPF or some new equivalent) and mechanisms to fallback to IPv4 may
have been good things to enforce in an IPv6 world so being a mandatory
part of 'SMTPv6' rather than options as we'd have to do now. MTA SMTP is
a totally different world from pretty much everything else IP because
although deployment is very widespread the actual number of legitimate
MTAs is tiny compared to the rest of the Internet connected stuff, and
SMTP is also quite vulnerable to 'legitimate attacks' unlike other
protocols (eg most spam is sent by doing everything according to the
standards, not by trying to find loopholes in it). IPv6 could have been
the place to build a 'safe new SMTP world', but that opportunity is
pretty much gone now :-(



-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
John Levine
2012-10-25 14:11:58 UTC
Permalink
Post by Steve Atkins
It's mostly dependent on how IPv6 addresses for mailservers (legitimate and
otherwise) will be allocated, and how much IPv6 will be used for inter-domain
email delivery. Do we have any data, or researched speculation, about that
to work from?
Well, I'm at a meeting where I can ask around.

I did a little greppage this morning and found that in the year that
I've had incoming v6 mail, I've gotten connections from a total of
2300 addresses. The vast majority of mail is from a handful of known
senders such as the IETF, and NANOG.

The real answer is that nobody knows what the IP address patterns will
be, but I think we can come up with some plausible scenarios. The
number of legitimate mail servers doesn't seem to be growing very
fast, so I expect the real mail will continue to come from a
relatively small set of IPs. Bot spam might just use whatever address
the host already has or might hop around. At breakfast this morning,
someone pointed out that Windows uses IPv6 anonymous addresses, and
they'd seen their users hop around somewhat.

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true

R's,
John

Here's the IPs that have connected more than 1000 times in the past
year:

34084 2001:1890:123a::1:1e
12971 2001:1838::cc5d:d48a
12113 2001:4f8:fff6::35
7611 2001:1890:1112:1::1e
5810 2001:1890:126c::1:1e
4810 2a02:2658:1011:1::2:2013
3747 2001:500:13::107
3298 2604:8d00:0:1::3
3259 2604:8d00:0:1::4
2309 2001:1890:123a::1:2f
2239 2604:8d00:0:1::9
2074 2001:48a8:6880:68::116:162
1635 2620:0:2d0:1::100
1281 2001:1868:4:1::25
1251 2a01:4f8:120:9382::145
1058 2001:1838:2001:8::4
Rob McEwen
2012-10-25 14:24:33 UTC
Permalink
Post by John Levine
but I think we can come up with some plausible scenarios.
One thing that is harmless and which should be promoted now is the
exclusive use of IPv6 addresses for authenticated e-mail headed to the
mail server. That way, IPv6 can be dynamically assigned IPs for things
like residential customers where that end user's IPv6 would never sent
mail directly to the recipient. Then, such a mail server could, for now,
ONLY accept mail for THOSE smtp-authenticated/IPv6 sessions, and
actually refuse non-authenticated IPv6 traffic. Such a server would then
relay out such mail via IPv4. 99.9% of the argument about hurrying up
IPv6 implementation for mail servers due to running out of IPv4 IPs are
solved by this scenario since there are thousands of dynamically
assigned IPs delegated to end users for every one legitimate mail server IP.

Not saying this is the answer for 100 years from now, but this scenario
scales well, too. When EVERYTHING is assigned an IPv6 IP (your car, your
refrigerator, etc)... those IPv6 IPs won't be prevented from sending
e-mail in the scenario I described above, even if mail servers haven't
yet moved into the IPv6 world.
--
Rob McEwen
http://dnsbl.invaluement.com/
***@invaluement.com
+1 (478) 475-9032
Emanuele Balla (aka Skull)
2012-10-25 14:48:05 UTC
Permalink
On 10/25/12 4:24 PM, Rob McEwen wrote:

Hi Rob!
Post by Rob McEwen
One thing that is harmless and which should be promoted now is the
exclusive use of IPv6 addresses for authenticated e-mail headed to the
mail server. That way, IPv6 can be dynamically assigned IPs for things
like residential customers where that end user's IPv6 would never sent
mail directly to the recipient. Then, such a mail server could, for now,
ONLY accept mail for THOSE smtp-authenticated/IPv6 sessions, and
actually refuse non-authenticated IPv6 traffic. Such a server would then
relay out such mail via IPv4. 99.9% of the argument about hurrying up
IPv6 implementation for mail servers due to running out of IPv4 IPs are
solved by this scenario since there are thousands of dynamically
assigned IPs delegated to end users for every one legitimate mail server IP.
Not saying this is the answer for 100 years from now, but this scenario
scales well, too. When EVERYTHING is assigned an IPv6 IP (your car, your
refrigerator, etc)... those IPv6 IPs won't be prevented from sending
e-mail in the scenario I described above, even if mail servers haven't
yet moved into the IPv6 world.
So you're basically suggesting that MXs should not allow any IPv6 SMTP
connection unless it's coming from a trusted entity, and only MSAs
should speak IPv6.

This will allow to work in the upcoming IPv4 shortage scenario, as you
say. But I think you underestimate how hard could be switching from this
scenario to the "all IPv6" one in the future...

In other words, you're basically suggesting something like "do not
publish any AAAA record for your MXs and just rely on IPv4, unless you
found a solution to the IPv6 spam problem".

But this is not suggesting a solution anyway... ;-)
--
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
Rob McEwen
2012-10-25 15:19:04 UTC
Permalink
Post by Emanuele Balla (aka Skull)
So you're basically suggesting that MXs should not allow any IPv6 SMTP
connection unless it's coming from a trusted entity, and only MSAs
should speak IPv6.
No. I'm talking about AUTHENTICATED e-mail that is, by design, NOT
considered the "sending IP" for that message. Maybe the "originate
IP"... but not the "sending IP". I'm not sure what you mean by "only
MSAs", this wouldn't prevent the use of IPv6 for OTHER uses. My answers
below should clear this up...
Post by Emanuele Balla (aka Skull)
In other words, you're basically suggesting something like "do not
publish any AAAA record for your MXs and just rely on IPv4, unless you
found a solution to the IPv6 spam problem".
I think you must be greatly misunderstanding me. When millions of end
user customers for a large set up their outlook programs (or
thunderbird, or whatever)... their connection to their ISP's mail server
does NOT use MX records!!!! Instead, that connection goes DIRECTLY to
the "a" record of the server host name that the end user puts in the
"smtp server" box in their mail client. Furthermore, since this is all
happening within an ISP's IP space and to their own customers.. the ISP
has MUCH granularity of control... so, if needed, directing of traffic
can be manipulated somewhat by the ISP (again, if needed).
Post by Emanuele Balla (aka Skull)
But this is not suggesting a solution anyway...
yes, this is a solution. Obviously NOT the final solution long term
solution... but this solves MANY problems in the meantime.
--
Rob McEwen
http://dnsbl.invaluement.com/
***@invaluement.com
+1 (478) 475-9032
Emanuele Balla (aka Skull)
2012-10-25 15:38:26 UTC
Permalink
Post by Rob McEwen
Post by Emanuele Balla (aka Skull)
So you're basically suggesting that MXs should not allow any IPv6 SMTP
connection unless it's coming from a trusted entity, and only MSAs
should speak IPv6.
No. I'm talking about AUTHENTICATED e-mail that is, by design, NOT
considered the "sending IP" for that message. Maybe the "originate
IP"... but not the "sending IP". I'm not sure what you mean by "only
MSAs", this wouldn't prevent the use of IPv6 for OTHER uses. My answers
below should clear this up...
Post by Emanuele Balla (aka Skull)
In other words, you're basically suggesting something like "do not
publish any AAAA record for your MXs and just rely on IPv4, unless you
found a solution to the IPv6 spam problem".
I think you must be greatly misunderstanding me. When millions of end
user customers for a large set up their outlook programs (or
thunderbird, or whatever)... their connection to their ISP's mail server
does NOT use MX records!!!!
I think we're speaking of the same thing here... :-)

MSA == Mail Submission Agent, the SMTP server your MUA (Outlook,
Thunderbird, pine) will connect to in order to send email.

MX in my notation was intended as "the MTA on the receiving end" or, in
other words, a mailserver that expects to be contacted by others MTAs
only, not by MUAs.


So, to rephrase the whole thing as I understood it:

- allow end customers to use IPv6 to *send* email through their ISP's
(not necessarily the connection one) IPv6-enabled authenticated mailserver

- do not allow the receiving mailserver (aka "the one published as MX
record for the domain") to receive email from strangers through IPv6


Did I get it right?
--
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
Rob McEwen
2012-10-25 15:47:59 UTC
Permalink
Post by Emanuele Balla (aka Skull)
- allow end customers to use IPv6 to *send* email through their ISP's
(not necessarily the connection one) IPv6-enabled authenticated mailserver
- do not allow the receiving mailserver (aka "the one published as MX
record for the domain") to receive email from strangers through IPv6
Did I get it right?
yes. Except that, again, the authenticated mail being sent by end users
to be relayed out by their ISPs mail server doesn't require that any
domains having "two-faced" MX records.
--
Rob McEwen
http://dnsbl.invaluement.com/
***@invaluement.com
+1 (478) 475-9032
Hal Murray
2012-10-26 00:34:59 UTC
Permalink
Post by Martijn Grooten
Anyway, back on topic: I'm still not convinced we'd be talking about
IPv6-based blacklists if we didn't have a long and successful history of
IPv4-based blacklists.
How about enumerating goodness rather than badness?

Does anybody have a list of techniques to consider?

We don't have to list IP Addresses. We could list domains and only accept
mail if the IP Address reverses to a listed domain (and forward confirms).

Would ISPs be willing to run a (white)list of their customers? (Either by
domain or IP Address.) How about web hosters?
Post by Martijn Grooten
Can't we do something entirely different for IPv6? Like, use domain-based
filtering by making it mandatory to DKIM-sign a message you send over IPv6
outside of your network?
Does DKIM tell me anything about the sending site being good or bad?

If I get a DKIM signed message, I could lookup the domain rather than the
sender's IP address. Does that avoid the too-many-IPv6 addresses problem?
Post by Martijn Grooten
I'm obviously biased since I run dnswl.org, but an IPv6-based whitelist may
work better than an IPv6-based blacklist. Enumerating the goodness is
generally easier than enumerating the badness.
What fraction of email comes from hosts you have listed? How hard would it
be to scale your list up to cover the whole world?

Assuming that you don't want to put all your eggs in one basket, how many
white lists would you need and/or how would you decide the order to check
them?

Do we need a list of ISPs that maintain a list of their their clients?
--
These are my opinions. I hate spam.
Emanuele Balla (aka Skull)
2012-10-26 08:12:20 UTC
Permalink
Post by Hal Murray
Post by Martijn Grooten
Anyway, back on topic: I'm still not convinced we'd be talking about
IPv6-based blacklists if we didn't have a long and successful history of
IPv4-based blacklists.
How about enumerating goodness rather than badness?
Does anybody have a list of techniques to consider?
We don't have to list IP Addresses. We could list domains and only accept
mail if the IP Address reverses to a listed domain (and forward confirms).
It's even worse, probably.
Reverse DNS lookups have the same problem DNSxL lookups have about
caching. And usually also a much higher latency because they need to hop
through several delegations before getting an answer.
Post by Hal Murray
Post by Martijn Grooten
Can't we do something entirely different for IPv6? Like, use domain-based
filtering by making it mandatory to DKIM-sign a message you send over IPv6
outside of your network?
Does DKIM tell me anything about the sending site being good or bad?
No, but gives you an hook (the signing entity) you can bind to a
reputation score.
Post by Hal Murray
If I get a DKIM signed message, I could lookup the domain rather than the
sender's IP address. Does that avoid the too-many-IPv6 addresses problem?
Not necessarily. See subdomaining...
--
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
Matthias Leisi
2012-10-26 13:28:35 UTC
Permalink
Post by Hal Murray
Post by Martijn Grooten
I'm obviously biased since I run dnswl.org, but an IPv6-based whitelist may
work better than an IPv6-based blacklist. Enumerating the goodness is
generally easier than enumerating the badness.
What fraction of email comes from hosts you have listed? How hard would it
be to scale your list up to cover the whole world?
We do store IPv6 addresses, but we don't publish them yet (since there
is no standard yet - the result of the discussion here may lead to the
emergence of a de-facto standard, or at least a first trial). So I can
not really tell what fraction we have listed in IPv6 world.

I can tell about our estimate on what we cover in terms of IPv4 based
on the dnswl.org stats. These stats are based not on SMTP trafffic,
but on the DNS traffic which we log (sample) on some of the public
mirrors. Larger senders with better cache utilization are likely to be
somewhat underrepresented in our data. We then do not use the absolute
numbers, but logarithmic magnitudes:

Magnitude Percent
10.0 100%
9.0 10%
8.0 1%
7.0 0.1%
6.0 0.01%
5.0 0.001%
4.0 0.0001%
3.0 0.00001%
2.0 0.000001%
1.0 0.0000001%

Extract from our magnitudes report (I'll happily share more data on request):
1 9.63 IPs where we have no record
2 9.24 IPs which are in our DB*, not published - contains a lot of
"bad apples" ("DNSWL Id 0")
3 8.86 IPs which are in our DB*, not published - with fewer "bad
apples" ("DNSWL Id 1")
4 8.44 Yahoo
5 8.38 Google
6 8.36 Internally blacklisted (snowshoe ranges etc)
7 8.12 Hotmail
8 8.03 Facebook
9 7.91 Exacttarget
10 7.89 cheetahmail.com

* Through imports from third parties or "learned" through the DNS logs

It's clear that key is the mag 9.63 of where we have no record. This
category contains all the residential/dynamic/botnet IPs; we do not
count the number of different IPs.

DNSWL Id 0 contains about 300k IPs, DNSWL Id 1 contains about 100k
IPs, all the other (published) DNSWL records contain about 200k IPs.
Records in 0 and 1 have quite some fluctuation (eg removed since they
are not present in the import source any more; promoted from "0" to
"1" based on some criteria; demoted from "1" to "0" based on the lack
of the same criteria). Entries are manually promoted from "0" and "1"
to one of the published DNSWL Ids.

Possibly 80k in each of the two "special" records may be considered
"good" (as in: not operated by spammer/bot herders), which would lead
to ~ 360k mostly legitimate SMTP-sending IPs.
Post by Hal Murray
Assuming that you don't want to put all your eggs in one basket, how many
white lists would you need and/or how would you decide the order to check
them?
One? Definitely too risky. Two? Not sufficient, in my view. Three?
That may work. Four? Could improve diversity. Five? There is a point
where returns of additional lists become diminishing (eg higher
latency, larger overlaps).

-- Matthias
Continue reading on narkive:
Loading...