The following is something that I’ve observed through trial and error, but haven’t seen documentation for nor encountered a warning or error for.
On our site, which is hosted by Discourse (for which we’re very appreciative!), setting a Custom incoming email address for a category only seems to work if the email address is prefixed by “foo+{something}@discoursemail.com” (where ‘foo’ is the general slug for our site).
Specifically, I often set up a new category, set up what I consider to be an intuitive email address for it, send a test mail to that address, and never get a bounce (correction: I did eventually get one several hours later) nor see it show up in our site’s received or rejected email logs. Then I eventually remember my previous experiences, set the address to foo+<some name>, run another test and it immediately works.
If I’m not imagining it, this seems understandable as a means for Discourse to distinguish mails intended for one hosted site from another, but I wanted to check that I’m correct. Or, if I’m not, see whether there are other explanations for why my initial choices of email address seem to go to /dev/null.
For our (hosted) site, I didn’t realize that …@{OUR PREFIX}.discoursemail.com was an option and have only ever tried using …@discoursemail.com as the hostname because that’s what the default “accept incoming emails” address uses (and I’ve updated my original query above to try and clarify this since I left the hostname off in the original question). I’ll give that a try, thanks for the tip!
Though I understand that Discourse can’t verify email addresses for self-hosted instances of Discourse, would it be possible to have the hosted instances generate a warning or error if the email address was not of an expected format? (or an expected format when using a …discoursemail.com address?
I think you’ve confirmed my suspicion that this is an issue specific to hosted Discourse sites like ours. I don’t know what level of effort would be required to have such sites verify that the …discoursemail.com addresses entered in this field are valid, but such a feature would’ve saved me a fair amount of time and frustration over the past several years of setting up new mailing lists and aliases, wondering why they don’t work. I imagine it would help others as well.
Alternatively, even a little tool tip on that field for a hosted site indicating that a legal address must be slug+...@discoursemail.com or ...@slug.discoursemail.com would go a long way. Though I don’t know whether making that tip specific to hosted Discourse sites makes that approach unworkable.
This is not true — the constraint is that the email must be delivered (not addressed) to one of these addresses to work. An example is the following setup which is what we and many of our customers use:
(in Discourse) configure Postings category to accept inbound email sent to postings@contoso.com
(on contoso.com mail server) configure postings@contoso.com to forward to {ANYTHING}@contoso.discoursemail.com
end result: mail addressed to postings@contoso.com gets sent to the Postings category
This functions effectively the same as:
(in Discourse) configure Postings category to accept inbound email sent to postings@contoso.discoursemail.com
end result: mail addressed to postings@contoso.discoursemail.com gets sent to the Postings category
@supermathie — Good point about the delivery address being more relevant than the one that the mail is addressed to.
Refining my previous request, I think a warning when trying to enter inbound email addresses that match the @discoursemail.com or @*.discoursemail.com patterns, yet that don’t start with slug+… or end with @slug.discoursemail.com would still be valuable to warn about for communities hosted by Discourse.
This would still permit your first case (since it doesn’t have discoursemail.com as a suffix) while still warning me about trying to set up a slug-users@discouresmail.com address, which is the type of pattern I always reached for and then got confused by when mails to it were silently dropped on the floor.
(Note that your second case wouldn’t generate a warning either, assuming contoso is your community’s slug).