The discussion addresses concerns about spam protection when using the Mail-Receiver plugin to handle public inquiry emails on a private Discourse instance. tkforbes expresses doubt that Mail-Receiver can adequately detect spam compared to standard email providers like Gmail, particularly since maintaining a list of banned domains is impractical.
Architect points to a guide for filtering known bad sender domains and notes that while risks exist if addresses are in public registries, they have not faced significant issues. They suggest protecting the address from web crawlers (e.g., via captcha or click-to-show) and highlight that Discourse creates staged users for incoming mail, allowing admins to block both email addresses and IP addresses immediately upon detecting spam.
mpalmer agrees that domain blocking is not a robust general solution but emphasizes that mail-receiver can be customized to integrate advanced pre-delivery filtering tools like SpamAssassin, leveraging Postfix capabilities.
Finally, tkforbes reports that after testing with a honeypot address, they discovered Discourse effectively rejects many spam attempts automatically. Specifically, the system filters out messages from senders with auto-reply addresses, which can be verified in the admin Email Logs under the Rejected tab by filtering for “autogenerated” errors.
Presently (completely independent of Discourse), I use a published email address as an alias that sends an inquiry email message to a number of email addresses. The group rely on their email providers’ Spam detection. Most of them use Gmail.
People work independently on answering inquiries. It sometimes leads to duplicated effort or other problems.
How things might change using my Discourse.
My Discourse instance is completely private and requires members to login. I’ve begun to use the Mail-Receiver plugin so members can reply to topics by email and it seems to work well.
I’ve been reading about and testing the related Groups option that accepts incoming email to a custom address. I’m considering that for an inquiries email address. I can’t see how Mail-Receiver would adequately detect and prevent Spam.
I’ve also read that the Discourse team itself is using incoming email as a Support feature, so perhaps Spam isn’t getting in their way.
I haven’t had issues with spam e-mails sent to mail-receiver address, but there is a risk that can happen if you have the address listed in public registries those can start to get spam/marketing e-mail.
Yeah, I saw that guide. However, maintaining a list of banned domains isn’t an option. It’s impossible to stay ahead of the spammers - we get Spam daily to the addresses that are published on our web site, but at least most of those first go through detection services that we do not maintain i.e. Gmail, miab …
I might get brave enough to try using a Discourse Group email address although I think I can predict that we won’t be able to live with the result. We could always go back to our original process, but I really liked the idea of being able to distribute the work in a natural manner and which preserves the communications.
To avoid that probably protecting address from web crawlers if possible could help. I’m not certain how that is done, but have seen that implemented to have a captcha or just “click to show address” option could prevent crawler scrapping of address.
Is simple to change address if spam gets too bad.
When there is e-mail in will create staged user, with spam you can immediately block both e-mail and I.P. address of those.
I agree with you that blocking domains isn’t a solid general-purpose anti-spam measure – it’s more for whacking the occasional “heavy hitter”.
It is entirely possible, though, to customise mail-receiver to do whatever additional pre-delivery filtering you need, such as running incoming messages through SpamAssassin or similar, since you have the entire Power of Postfix at your command. I’ve been considering building a “mail receiver 9001” that incorporates these sorts of things out of the box, but it’d need to be a sponsored effort, as I don’t personally have a need for it at present.
Subsequent to opening this topic a couple of years ago, we engaged in a test using a honeypot email address that is published on our web site. Humans would know not to use it. In all this time we have had just a small number of spam emails.
I recently stumbled across the Rejected tab of the Discourse admin page called Email Logs. While there, I found numerous examples of Discourse rejecting spam email. An easy way for other admins to find their own examples is to type “autogenerated” into the Error filter box that appears on that page, or you could use this link when logged in as admin…