DO Ideas 2

Allow SMTP over IPv6

DigitalOcean are currently blocking outbound SMTP over IPv6, however this makes very little sense when it is allowed over IPv4.

The standard copy-paste reply from support is that this is due to "easing into the roll out" of IPv6. That makes little sense.

The same port-blocking policies should be applied to IPv4 and IPv6 traffic (ideally, NOT blocking SMTP at all)

  • Phillip Smith
  • Sep 11 2018
  • Will not implement
  • Sep 11, 2018

    Admin Response

    Hi Phillip, We do not allow SMTP over IPv6 because when IPV6 addresses are blacklisted providers will blacklist the entire /64. Due to this it is not very useful to allow DigitalOcean users to run mail servers on IPV6.
  • Attach files
  • Catalin Patulea commented
    September 11, 2018 17:00

    Just trying to send occasional mails to myself from my server's cron jobs. Trying very simple ssmtp setup, with ssmtp forces IPv6, can't make it choose IPv4. Can't send mails to myself from my server.

  • Anonymous commented
    September 11, 2018 17:00

    IPv4 doesn't now.

    What the hell? How i can do services without SMTP these days.
    DigitalOcean are you Ok?

    You should allow at least G-Suite relays.

    No more DigitalOcean.

  • Isaac commented
    September 11, 2018 17:00

    If you assigned droplets a proper /64 to begin with your point about providers blocking /64's would be moot.

    This is the last straw. I'm moving all my droplets to Linode. Your IPv6 strategy is flawed.

  • Andrew Ensley commented
    September 11, 2018 17:00

    This is pretty appalling. Is it DigitalOcean's hope that no one will ever send email over IPv6? Because that's already happening. This needs to be addressed.

  • Trev commented
    September 11, 2018 17:00

    Just wasted a few hours trying to setup SMTP on IPv6 to find out DO block the port! And then they direct me here. Unbelievable.

  • Elana Hashman commented
    September 11, 2018 17:00

    As is currently implemented, users do not get the full benefits of using IPv6 on DigitalOcean. One of the main ones is the ability to avoid IP reputation issues when sending email because of the sheer abundance of IP addresses in the IPv6 space.

    According to the specification (most recently, RIPE-684, a /64 per user is the minimum size Digital Ocean should be allocating. The way DO is currently provisioning IPv6 addresses (in /124 blocks per droplet) is not compliant.

    If this were fixed, it would solve the issue of email reputations, as users would not all share the same /64, and reputation filtering could proceed on a user by user basis.

  • Jim Fenton commented
    September 11, 2018 17:00

    Piling on here. I just opened a support ticket requesting that IPv6 SMTP be unblocked, and the request was declined and I was referred here.

    This makes very little sense:

    1. /64 networks are much more plentiful than IPv4 addresses, yet DigitalOcean allows IPv4 SMTP. Apparently multiple customers share the same /64 currently; DO might consider allocating a dedicated /64 to customers who need to use SMTP if cross-reputation is really a concern.

    2. IP address blacklisting is considerably less prevalent for IPv6 than for IPv4, due to the sheer size of the blacklist address space. Instead, some recipients require SPF or DKIM authentication so they can associate a reputation with the domain instead.

    3. Port 587 (submission) requires authentication to the receiving mail server, and therefore isn't associated with IP reputation/blacklists. Even my home ISP, which blocks port 25, allows 587. There is no reason why DigitalOcean should be blocking 587.

    4. DigitalOcean should generate an ICMPv6 message when a packet is blocked for this reason so we know what happened. I recognize that ICMP messages may be harmful in DDoS situations, but this is an *outgoing* block. If DO had generated an ICMP message, I wouldn't have spent a lot of time trying to debug my other (receiving) mail server and its firewall.

  • Adrien Jarthon commented
    September 11, 2018 17:00

    I just hit this filtering recently and was pretty surprised. In my case ( I don't even send email over IPv6, but I monitor other's servers, and if someones configure a simple TCP check on port 25 (to check if his SMTP server is up) I can't do this from DO. I never realized this before but this is pretty bad for me as this means I can't provide a good IPv6 support if it only works on some ports.

    I totally understand the reason why you are blocking this by default to avoid getting /64 ranges blocked, and I wont push for some white-listing here because I even If I don't spam, others could harm the /64 i'm on.

    The best solution IMO would be to give /64 range to droplets (or account) as exposed here:
    I would even be wiling to pay 1€ / month for a /64 IPv6 range if availability is an issue for you abd you don't want to give /64s to everyone.

  • Calvin Walton commented
    September 11, 2018 17:00

    This is a ok (not great) reason for blocking port 25, but you are also blocking ports 465 and 587 which are mail submission protocol, used for sending mail via an external authenticated mail server (e.g. gmail's SMTP server).

    Ideally, we'd be able to get a /64 for each droplet, which would solve this issue and also open up additional interesting uses for the ipv6 space. I'm pretty sure DO has more IPv6 /64 blocks than IPv4 addresses, and each instance already has an IPv4 address...

  • Pierre Abbat commented
    September 11, 2018 17:00

    Here's how I'd handle IPv6 addresses in a blacklist:
    * If the top half of the bottom half is all zero, it's probably fixed; block that IP address and no other.
    *If the middle 16 bits of the bottom half are fffe, the other 48 are a MAC address; block all addresses with the same bottom half, regardless of the top half.
    *If neither of the above is true, the address is probably randomly generated; block all addresses with the same top half (the /64) except those that match the first two categories.

    That said, I know a fixed IP address whose top half of bottom half is 1:0, not 0:0.

  • Jeremy McMillan commented
    September 11, 2018 17:00

    If you really wanted to control outbound SMTP, provide a metered usage MTA with reasonable (almost free) pricing for reasonable interactive email traffic, and a parabolic function to make legitimate heavy email users pay for the infrastructure and spammers not even bother.

  • Jeremy McMillan commented
    September 11, 2018 17:00

    Maybe the IPv6 allocation should be /64 at a minimum? That's what the rest of the Internet is doing.

  • Boris commented
    September 11, 2018 17:00

    On Digital Ocean droplets everything is working over IPv6 but SMTP. Why are you blocking outgoing SMTP connections over IPv6? IPv4 works, IPv6 ssh/http/ftp/whatever works, but not SMTP. Why?

  • Phillip Smith commented
    September 11, 2018 17:00

    Then allocate a /64 to each droplet as per this request [1] and allow SMTP from that /64?

    There are IPv4 RBL's that will blacklist entire /24's so I'm not sure how this is different.

    How about blocking it by default to prevent compromised hosts sending spam, but allow users who genuinely need it to allow it?


  • Vladimir commented
    October 18, 2018 19:16

    Allocate /64 to each VM, problem solved.