Continuing the discussion from Digital Ocean is blocking outgoing mail!: It seems that Digital Ocean is blocking out bound SMTP traffic for at least some customers. My guess is that soon you’ll have to jump through hoops to be able to access a remote SMTP port. Simple solution: Mailgun, Sendgrid, and Sparkpost all accept TLS traffic on port 2525. I propose these changes to discourse-setup changing default SMTP port for those services to 2525. adding a test (e.g., nc -z -w5 smtp.mailgun.org 25) to see if the chosen SMTP port is open Why those 3 services services? They’re the ones that discourse-setup currently knows about and recommends smtp_user_name for). Unless someone (i.e., @codinghorror) has some reason not to, I’ll try to do this later this week. I’ll also see about changing the scary “your ip doesn’t resolve to your hostname” message too. It continues to confuse people. Or maybe I’ll look again at finding a more reliable way to test that the resolved host IP connects to the server.

You don’t agree with any of it? I’d say having the set-up script test that the named mail server can be reached on the named port is a good thing and will help people identify problems faster. Maybe do nothing else is done to help people get around the blockage, lest DO get more aggressive.

The response that I just got from Digital Ocean didn’t say “Yeah, we’re blocking everyone by default”, so perhaps my knee-jerk reaction was out of line, but adding a simple “can we connect to the smtp server at all” test still seems like a reasonable idea. Here’s their response, which I find unsatisfying. Note that this DO tech says that his only way to know if a droplet has been blocked is to try to telnet to google’s smtp servers.

We shouldn’t be sending mail on port 25 anyway. 587 is the “submission” port, for MUAs (which is what Discourse is) to submit mail to a fully-fledged MTA, using an encrypted and authenticated connection. AFAIK all decent ESPs support submission, and if a provider blocks 587 outbound, I’m more than happy to go full rage-womble on them, because there is absolutely zero reason to do so on anti-abuse grounds.

I wasn’t clear, then. They are also blocking 587. It seems to be the case that they are blocking all standard ports that transmit mail.

[image] pfaffman: They are also blocking 587. [download] I’ll spin up a test droplet, and if I can reproduce, then it will be rage-womble: ENGAGED. Addendum: drat, they’re wise to my plan and my test droplet could do outbound 587. If anyone gets a direct contact at DO who wants to argue the point, feel free to point them my way, otherwise it’s a bit weird to be raising a ticket for a problem I’m not actually having…

I doubt you’ll reproduce. With a new account, maybe. Maybe with a new account? Maybe a new account that doesn’t have a credit card? Among my frustrations is that they won’t say what makes you get blocked. I guess if that were public it’d tell spammers how to sneak by.

I’ll include a link to this post in my next exchange with them.

[image] pfaffman: I’ll include a link to this post in my next exchange with them. OK then, let me give you the full spiel, then: Port 25 outbound is an obvious candidate for filtering, because if you can hit the Internet on port 25, you can deliver e-mail to practically anyone. If that e-mail is unwanted, the only useful “identity” information that the recipient has to try and prevent further abuse is the sending IP address. That identity is tied, in general, to a hosting provider, not an individual subscriber, so any reputation hit for spamming goes, in the first instance, onto the hosting provider. For a cloud provider, whose only customer contact is a (potentially stolen) credit card, there are practically zero consequences that can be imposed on the actual responsible party (the customer). So, the hosting provider ends up wearing the blame. It’s no surprise, therefore, that cloud providers are somewhat reticent to let everyone have unfettered outbound port 25. It’s a shame, but it’s not a surprise. The thing is, port 587 is a whole different kettle of fish. You cannot deliver e-mail to any address on the Internet by connecting to port 587. In order to get an e-mail sent through port 587, you need to, at the very least, authenticate yourself. That provides an identity, separate from the sending IP address, on which to apply consequences. If the e-mail ends up being spam, then it’s the e-mail provider (as the party which made the connection to port 25) which takes the reputation hit. They know this, and there’s all sorts of stuff they do to balance “getting paid to deliver e-mail” and “not getting blacklisted to hell and back” (with varying levels of success). My point here is that the reputation hit from delivering an e-mail that was submitted over port 587 lands on the intermediary, not the hosting provider. Now, you might say, “aha! but the Received: headers will show it came from our IP space originally, and we’ll still get blamed”. There’s two responses to that. First off, nobody who’s been doing e-mail for more than five minutes believes any Received header they didn’t generate, because they’re trivial to spoof. Much fun was had in the good old days blaming spam on all sorts of innocent parties via that trick. Second of all, if you’re worried about multi-hop reputation problems, you need to block 2525 as well, because guess what? 2525 is a de facto standard submission port, as well, because some people can’t remember two different numbers, or something. They behave practically identically, and any problems you’d have if you allowed submission over the standard port of 587 also apply to submission over 2525. So, yeah. Unblock outbound 587, please. The Internet thanks you.

I’ll submit that next time I get to a computer. I suspect it’s new accounts that are getting filtered, which is a significant proportion of my installs. A while back, mailgun started requiring credit cards; I told people to give credit card numbers. I can’t suggest a fix here (Other than use 2525). Your logic about filtering 587 seems sound. We’ll see.

Proposed changes to discourse-setup because Digital Ocean blocks outbound smtp

Development

codinghorror (Jeff Atwood) July 25, 2017, 2:05pm 2

I don’t agree with any of this. Unless you have actual evidence that DO is globally blocking the smtp port for all new signups, not just some of them…

Topic		Replies	Views
Looks like DO is disabling Smtp in their Discourse hosting plans Self-hosting hosting	25	1117	August 20, 2024
DigitalOcean blocking SMTP and forcing SendGrid usage Product Support email	11	4147	April 17, 2025
Any alternative way to connect to email service then SMTP (on Digital Ocean) Product Support email	6	553	April 18, 2025
Digital Ocean, SendGrid, Netlfity - Register Admin account email not coming through Self-hosting	30	3623	December 29, 2020
If local logins are disabled Product Support	29	1230	July 17, 2026

Proposed changes to discourse-setup because Digital Ocean blocks outbound smtp

Related topics