Can't send mail -- unprocessable entity

I’ve set up a new site, using my script that calls discourse-setup like a normal person would.

Email is not going out. It never shows up in the mailgun logs. I’ve double-checked the password/username and switched from port 2525 to 587. I am able to telnet to both ports from the server (and from inside the container). I’ve rebuilt and rebooted.

It seems like it’s timing out and not connecting at all, but I can’t explain how that could be.

Started POST "/admin/email/test" for at 2017-12-01 20:18:17 +0000
Processing by Admin::EmailController#test as */*
  Parameters: {"email_address"=>""}
Sent mail to (1623.2ms)
Completed 422 Unprocessable Entity in 2117ms (Views: 0.6ms | ActiveRecord: 6.3ms)

Can you get the actual content that is triggering the unprocessable entity?

That’s all that gets put in the production.log. Where else can I look?

And a verification email fails with this:

Job exception: 535 5.7.0 Business Verification

Actually, I can’t figure out what those are; I’d guess they are verification emails triggered when a user tried repeatedly to get one, but another one just showed up and I can’t imagine that this guy is trying again and again (he notified me of the problem already and he knows I’m working on it).

All of the email log tabs are empty.


Apparently the account is on some kind of Double Secret Probation. There’s a big banner at the top that says:


From the API all I see is that the domain is active. In the Mailgun logs, nothing ever shows up. My best guess at this point is that the IP that the Digital Ocean droplet has been marked as a Bad Player, so now it can’t send mail. And I guess Mailgun doesn’t want them to know that they know that they’re bad, so it just silently fails.

As I said before the Rails logs are also full of

Job exception: 535 5.7.0 Business Verification

but that doesn’t happen when you do the mail test.

Anyway, unsurprisingly, this isn’t a Discourse problem.

I filed a fairly irate support ticket. I’ll update if they ever figure it out.

I tried once before to log in and it failed but the MX 10 DNS settings weren’t all in place (though it shouldn’t have mattered), so I thought, it might resolve when the last settings are in place.

When I tried today, I alerted you.