Understanding email in functionality


(Neil Brooks) #1


I notice that its possible to turn on the facility for people to send an email to a specific email address which in turn will post their reply as a new topic or perhaps a response to a topic.

Does this person need to be an existing registered user for this to happen, or can Discourse be set up to allow anonymous posts by email?

(David Taylor) #2

There is a site setting “enable staged users”. If it is enabled, “staged” user accounts will be created for that email address. If it is disabled, the email will be bounced.

There’s a brief description of staged users at the top of this topic: Start a New Topic via Email ✉

(Neil Brooks) #3

Perfect! Thank you. If we wanted to create a third party form, hosted on potentially another server, allowing anonymous users to fill in said form which in turn would post into Discourse as staged users using their email address in the reply-to header of the email, would this be possible?

Or would the email be treated as SPAM by the Discourse system?

(Gerhard Schlager) #4

See my post in Can Email-In be used to "ingest" a mailing list?

(Neil Brooks) #5

@gerhard thanks for the post, although from what I understand, this is to suck in some pre-defined mailing lists. Ideally what I want to do is have the same function that’s provided by staged users via email, but through a form thats always open and the end user still gets their topic updates by email.

I hope that makes sense?

(Gerhard Schlager) #6

Sorry, I got a little bit confused by the other topic :blush:

I think if you want to use your own form you’ll either need to use the API or make your form send an email to your Discourse. But you’ll lose a lot of of features that the Discourse UI provides for creating posts.

(Neil Brooks) #7

Yes, I’m thinking that sending an email from a third party form, using a third party email address is also going to cause issues with email validation and spam filtering too.

(David Taylor) #8

Discourse itself doesn’t include any spam filtering (beyond checking for the auto-generated header), so even if SPF/DKIM records don’t match it should work. If you have spam checks upstream of discourse then you may run into problems.

A “better” solution would definitely be to use the API.

(Neil Brooks) #9

I agree @David_Taylor I’ll need to take a look at the API to see what it provides in terms of methods. Thanks for the great advice.

(Brian Gillespie) #10

I’ve got exactly the same desire. Some orders from our customers need to be approved before we charge their credit card and process the order. We currently do this by sending emails to our sales team. Sometimes the sales team needs to get in touch with the original user, and wants to reply.

So for us, the original email headers could be:

From: "Web Order Bot" <order-bot@our-domain.com>   # (clearly whitelisted)
To: discourse-ingestion@discoursemail.com
Reply-To: "New Customer" <never-been-to-discourse@customer.com>
Subject: Order 192831

What I’d love to see is a new Discourse staged user never-been-to-discourse@customer.com get created, and the incoming message be from that user. Our team could then reply directly to the customer in Discourse. As it stands, they reply to order-bot@our-domain.com which doesn’t work very well.

If we need to use an API to do this, can you point me to the APIs for creating new posts and staged users?

(Brian Gillespie) #11

@sam @supermathie is there a way to make the above work?

(Michael Brown) #12

Using the API rather than email is a good way to do this, you’re right, though I’ll check with one of my team members more familiar with the API to say exactly which calls to make.

Or, you could probably modify the headers to be:

Sender: "Web Order Bot" <order-bot@our-domain.com>   # (clearly whitelisted)
To: discourse-ingestion@discoursemail.com
From: "New Customer" <never-been-to-discourse@customer.com>

and that should work as you expect (I think, I haven’t actually tested that).

(Brian Gillespie) #13

No Dice. Unfortunately, I can’t send emails using a From header to send email outside our domain. And understandably so - that’s a fantastic way to obfuscate email for SPAM purposes.

So, my only options as I see it are for “reply-to” to work, or an API solution.

(Régis Hanol) #14

The only supported way right now is to “enable forwarded emails” and forward an email from never-been-to-discourse@customer.com.

(Michael Brown) #15

That’s too bad - we use exactly this workflow here on meta.

I bet if you do that and have your system craft an email from web-order-bot that looks like a forwarded email from the end user, it should work as you expect!

(Brian Gillespie) #16

Thinking with a little bit clearer head, rather than doing our send via Amazon SES (how we do most of our mail delivery), if I just send to mx-sjc1.discoursemail.com directly, I can set the mail headers the way you want them set.

… and it even works!