In a support thread titled ‘Reply-by email pop3 auth failure’, sadie reports issues setting up email replies in Discourse using POP3 with openinbox.com, encountering authentication failures — possibly due to missing STARTTLS support. pfaffman recommends using the mail receiver container instead, citing better reliability and faster delivery. sadie shares attempts to configure MX records and debugs with Mxtoolbox, noting a 454 Relay access denied error when sending test emails — suspecting DNS misconfiguration. pfaffman clarifies that the MX record should point discourse.example.com to itself, advising against modifying the TLD’s email settings. sadie confirms success after testing via telnet on port 25 and realizing DNS propagation delays from their university email provider; switching to the openinbox account resolved delivery. They acknowledge past DNS experience and share a screenshot of their correct MX record setup on Namecheap. The root cause was DNS misconfiguration and propagation delays, resolved by aligning MX records and testing from the intended mail provider.
After trying to setup with a gmail account – failure message said google wanted oauth2 in addition to user/pass ..
I’m trying to get it to go on openinbox.com – not awfully expensive, supports starttls
I can verify login thusly:
gnutls-cli --starttls-proto=pop3 -p 110 pop3.openinbox.com
However when I ‘enable replying to topics via email’, I get auth failure
.. any help on this appreciated is the problem that Discourse doesn’t use STARTTLS?
It’s much easier to use the mail receiver container. See Configure direct-delivery incoming email for self-hosted sites. Aside from being easier, it’s more reliable, more flexible, and doesn’t require polling, so messages are delivered faster.
Jay, I’ve also tried that, perhaps my attempt to make an MX record is inaccurate .. I get and OK config at Mxtoolboxdotcom: (no PTR record, no support for TLS, otherwise all green)
We have to have a DNS record that directs our TLD email to our outgoing mail server, that seems to override my attempt to send mail to the server / subdomain, viz: sending test email to nobody@discourse.TLD,domain shows up in the mail receiver logs as:
reject: RCPT from outgoinghost.otherdomain 454 4.7.1 <nobody@TLD,domain>: Relay access denied; from=ME@otherdomain to=nobody@TLD.domain
I have this MX record:
MX Record HOST discourse.TLD,domain VALUE discourse.TLD,domain. PRIORITY 10 TTL 1 min
Well, as the saying goes, it’s always DNS.
There’s not much chance on getting it figured out with it using placeholders since neither you nor whoever is helping you can check anything, but I guess here’s an attempt anyway.
The MX record should be
discourse.example.com pointing to discourse.example.com with any priority.
Don’t change anything about the TLD’s email. Just the MX record for the mail receiver, which is the same hostname as Discourse.
Got it, that’s helpful .. and I was being dense
connected via telnet to port 25, ran the regular debug script:
RCPT to: nobody@discourse.artisans-collab.org … etc
This worked fine, log says “delivered” so I’ll go back to the config and see if I can get reply-by-email working now 
p.s.
I’m sure somewhere continuing to debug was DNS ..
Because I kept sending test messages from my regular email address (a large Uni) and apparently changes to DNS haven’t managed to propagate in to said large email infrastructre.
So I sent a test message from that openinbox account I was going to use for POP3, bingo, delivered fine
god I used to run dns servers, but it was a couple decades ago, and times were simpler.
Anyway, my MX (namecheap) looks exactly as you said, .. I’ll stop obfuscating
