4 ms·

It doesn't help that the use of an IPv4 is a status symbol that indicates that you are willing to spend money on your infrastructure (and are thus not a spammer

It doesn't help that the use of an IPv4 is a status symbol that indicates that you are willing to spend money on your infrastructure (and are thus not a spammer). If you attempt to run an email server on IPv6, you will see what I mean.

immibis 2y ago
I found an open email relay on IPv6 once, because nobody scans IPv6 and therefore nobody ever sent spam through it. (Apparently this was caused by a reverse proxy misconfiguration causing the server to think IPv6 connections were from localhost)
- sleepy_keita 2y ago
  Also the surface area of IPv6 is huge, it just takes so much time to scan everything. It's not security, but it's a deterrent.
  - crote 2y ago
    And yet scanning IPv6 is exactly what some people are doing. IPv6 nodes aren't individual random addresses in a 128-bit address space. They are going to be grouped in subnets, so it makes sense to explore /64 ranges where you know there's already at least 1 address active. There's a pretty decent chance at least some addresses are going to be sequential - either due to manual configuration or DHCPv6 - so you can make a decent start by scanning those. For non-client devices, SLAAC usually generates a fixed address determined by the NIC's MAC address, which in turn has a large fixed component identifying the NIC's vendor. This leaves you with a 24-bit space to scan in order to find other devices using NICs made by that vendor - not exactly an unfair assumption in larger deployments. Much faster scanning can of course be done if you can use something like DNS records as source for potential targets, and it's game over once an attacker has compromised the first device and can do link-local discovery. It's not going to be extremely fast or efficient, but IPv6 scanning isn't exactly impossible either. It's already happening in practice[0], and it's only going to get worse. [0]: https://www.akamai.com/blog/security-research/vulnerability-scanning-IPv6-why-should-we-care https://www.akamai.com/blog/security-research/vulnerability-...
    - lazide 2y ago
      Well, and the easiest way is some sort of web bug/tracker/log or traffic analysis. See what address gets used, and blam.
deleted 2y ago
[deleted]
cjek420 2y ago
That's not what I am observing while running a number email servers which having both IPv4 and IPv6. Spam is only on IPv4 and about 80% of legitimate email is on IPv6.
- holowoodman 2y ago
  Yes, but those facts don't reach the email filtering business: There, IPv4 IPs have some reputation, maybe good or bad. IPv6 "just doesn't exist" and has a universally bad reputation. Thus your IPv6-Emails will be filtered and dropped more often, even though you are correct that actually IPv6 is an indicator of non-spam. I've got quite a few transport rules to work around those kinds of braindead filters...
  - eqvinox 2y ago
    > IPv6 "just doesn't exist" and has a universally bad reputation. I've been sending my mail via IPv6 for ages without issues… did you mean reputation or reputation?
    - holowoodman 2y ago
      > I've been sending my mail via IPv6 for ages without issues… In most cases it does work and there are no problems. But especially medium-sized businesses who run their own email through some crappy mailfiltering middlebox file anything that comes from or through an IPv6 endpoint to spam. > did you mean reputation or reputation? I don't understand your question. I meant IP address reputation, which is what many mail filtering systems use to estimate spam probability or outright reject email. See for example https://www.spamhaus.org/ip-reputation/ https://www.spamhaus.org/ip-reputation/
      - remram 2y ago
        That does not match my experience either. In fact I don't see why any mail server would bother getting and configuring an IPv6, listen on it, just to drop all received messages. Just don't listen on v6, that would achieve your goal, would prevent reputable dual-stack senders (like Google!) to send messages over v6 that you'll drop, and simplify your configuration.
0x1ceb00da 2y ago
In many situations it's a necessity. Ipv4 only devices can't connect to ipv6 only servers. So if you have ipv4 clients, your server has to support ipv4.
- pastage 2y ago
  Get a front that binds a IPv4, with a loadbalancer or a wireguard tunnel.

immibis 2y ago

I found an open email relay on IPv6 once, because nobody scans IPv6 and therefore nobody ever sent spam through it. (Apparently this was caused by a reverse proxy misconfiguration causing the server to think IPv6 connections were from localhost)

sleepy_keita 2y ago
Also the surface area of IPv6 is huge, it just takes so much time to scan everything. It's not security, but it's a deterrent.
- crote 2y ago
  And yet scanning IPv6 is exactly what some people are doing. IPv6 nodes aren't individual random addresses in a 128-bit address space. They are going to be grouped in subnets, so it makes sense to explore /64 ranges where you know there's already at least 1 address active. There's a pretty decent chance at least some addresses are going to be sequential - either due to manual configuration or DHCPv6 - so you can make a decent start by scanning those. For non-client devices, SLAAC usually generates a fixed address determined by the NIC's MAC address, which in turn has a large fixed component identifying the NIC's vendor. This leaves you with a 24-bit space to scan in order to find other devices using NICs made by that vendor - not exactly an unfair assumption in larger deployments. Much faster scanning can of course be done if you can use something like DNS records as source for potential targets, and it's game over once an attacker has compromised the first device and can do link-local discovery. It's not going to be extremely fast or efficient, but IPv6 scanning isn't exactly impossible either. It's already happening in practice[0], and it's only going to get worse. [0]: https://www.akamai.com/blog/security-research/vulnerability-scanning-IPv6-why-should-we-care https://www.akamai.com/blog/security-research/vulnerability-...
  - lazide 2y ago
    Well, and the easiest way is some sort of web bug/tracker/log or traffic analysis. See what address gets used, and blam.

deleted 2y ago

[deleted]

cjek420 2y ago

That's not what I am observing while running a number email servers which having both IPv4 and IPv6. Spam is only on IPv4 and about 80% of legitimate email is on IPv6.

holowoodman 2y ago
Yes, but those facts don't reach the email filtering business: There, IPv4 IPs have some reputation, maybe good or bad. IPv6 "just doesn't exist" and has a universally bad reputation. Thus your IPv6-Emails will be filtered and dropped more often, even though you are correct that actually IPv6 is an indicator of non-spam. I've got quite a few transport rules to work around those kinds of braindead filters...
- eqvinox 2y ago
  > IPv6 "just doesn't exist" and has a universally bad reputation. I've been sending my mail via IPv6 for ages without issues… did you mean reputation or reputation?
  - holowoodman 2y ago
    > I've been sending my mail via IPv6 for ages without issues… In most cases it does work and there are no problems. But especially medium-sized businesses who run their own email through some crappy mailfiltering middlebox file anything that comes from or through an IPv6 endpoint to spam. > did you mean reputation or reputation? I don't understand your question. I meant IP address reputation, which is what many mail filtering systems use to estimate spam probability or outright reject email. See for example https://www.spamhaus.org/ip-reputation/ https://www.spamhaus.org/ip-reputation/
    - remram 2y ago
      That does not match my experience either. In fact I don't see why any mail server would bother getting and configuring an IPv6, listen on it, just to drop all received messages. Just don't listen on v6, that would achieve your goal, would prevent reputable dual-stack senders (like Google!) to send messages over v6 that you'll drop, and simplify your configuration.

0x1ceb00da 2y ago

In many situations it's a necessity. Ipv4 only devices can't connect to ipv6 only servers. So if you have ipv4 clients, your server has to support ipv4.

pastage 2y ago
Get a front that binds a IPv4, with a loadbalancer or a wireguard tunnel.