Getting Discourse to Send Mail via Alibaba Cloud DirectMail

Fixes Net::ReadTimeout and Error 436

Introduction

When you self‑host a Discourse forum, reliable e‑mail delivery is a make‑or‑break prerequisite. Discourse must be able to send sign‑up confirmations, password resets, and digest e‑mails, or your community never really comes alive. If you want to avoid the cost of the usual suspects (SendGrid, Mailgun, etc.), Alibaba Cloud DirectMail is an attractive alternative.

This post walks through two hurdles I hit while wiring Discourse up to Alibaba Cloud:

1. A mysterious Net::ReadTimeout during SMTP negotiation

2. A 436 “MAIL FROM doesn’t conform with authentication” error once the first problem was fixed

I’ll explain why they happen and show exactly how to solve them.

---

1. The Net::ReadTimeout Trap

Symptom

./launcher logs app shows:

Net::ReadTimeout

Root Cause

Discourse defaults to STARTTLS on port 587. On port 465, however, Alibaba Cloud expects a TLS handshake immediately. If you try STARTTLS there, Discourse first opens a plain‑text connection, then issues a STARTTLS command. The server rejects the clear‑text hello and the connection hangs—hence the timeout.

Analogy

• 465 is “put on the hazmat suit before entering.”

• 587 is “step inside, chat for a second, then suit up if privacy is required.”

Fix

Force Discourse to speak TLS from the very first byte by:

1. Using port 465

2. Disabling STARTTLS

3. Explicitly enabling SSL/TLS

# containers/app.yml  (env section)
DISCOURSE_SMTP_ADDRESS: smtpdm-us-east-1.aliyuncs.com
DISCOURSE_SMTP_PORT: 465
DISCOURSE_SMTP_USER_NAME: "YOURNAME@YOURDOMAIN.TLD"
DISCOURSE_SMTP_PASSWORD: "YOURBEAUTIFULPASSWORD"
DISCOURSE_SMTP_ENABLE_START_TLS: "false"   # critical!
DISCOURSE_SMTP_SSL: "true"
DISCOURSE_SMTP_FORCE_TLS: "true"
DISCOURSE_NOTIFICATION_EMAIL: "no-reply@forum.cnbuy.co"
DISCOURSE_SMTP_AUTHENTICATION: "plain"

---

2. The 436 “MAIL FROM Doesn’t Conform” Error

Symptom

After the timeout is gone, the log shows:

436 "MAIL FROM" doesn't conform with authentication [@sm060104]
(Auth Account: YOURNAME@YOURDOMAIN.TLD | Mail Account: noreply@YOURDOMAIN.TLD)

Root Cause

Alibaba Cloud insists that the envelope sender (MAIL FROM) match the authenticated user. Discourse, by default, tries to send notifications as noreply@YOURDOMAIN.TLD, which mismatches YOURNAME@YOURDOMAIN.TLD (your SMTP credential).

Fix

Tell Discourse to use the same address for notifications:

## containers/app.yml  (run section)
run:
  - exec: echo "Beginning of custom commands"
  - exec: rails r "SiteSetting.notification_email='YOURNAME@YOURDOMAIN.TLD'"
  - exec: echo "End of custom commands"

Then rebuild:

./launcher rebuild app

---

3. Verification

1. Sign up with a throw‑away e‑mail address.

2. Check that the confirmation mail lands in the inbox (not spam).

3. Watch the Discourse logs—no more timeouts or 436 errors.

---

Conclusion

• Always match the transport to the port. Port 465 demands implicit TLS; port 587 expects STARTTLS.

• Align notification_email with your SMTP credential when your provider enforces a one‑to‑one mapping.

• With those two tweaks, Alibaba Cloud DirectMail becomes a drop‑in, cost‑effective SMTP backend for Discourse.

Happy self‑hosting! If this saved you an afternoon of hair‑pulling, feel free to share the post or drop a comment below.