Continuing the discussion from Email-in Discourse::InvalidAccess: The Discourse::InvalidAccess hit again. This time, the length of Subject is not in cause. I’m suspecting that it has to do with the category being a restricted sub-category. But the category is set to receive email from addresses without an account, so I would expect the email to go through and create a new topic. The use-case is a CFP: people should be able to send messages, but only organizers should be able to read the messages and discuss them. I think this is different than the case described in Email in to a private category [image] hellekin: So, to summarize: Given a private category with email-in authorized for unknown email addresses (i.e., belonging to no existing account, AKA staged user) → if an email comes in from an unknown address: it is delivered to the private category → if an email comes in from a known address: it is delivered if and only if the user is a member of a group authorized to access the category. Therefore, if you want to use email-in for a CFP, configure a private group’s email-in and use that address. Messages can be “made public” and turned into a topic in a category (private or not). Relevant documentation: Configuring incoming email to create new topics or group messages - Site Management - Discourse Meta

I rebuilt after a (noop) git pull, and now it seems to be working with the second domain added to Postfix’s relay_domains. Before these series of tests, and with the change, I had no more error, but emails did not appear at all, neither in the category nor in the error logs. In containers/mail-receiver.yml we’ve got: POSTCONF_relay_domains: forum.example.net, example.net (Of course, example.net is not what’s actually in the configuration file. What’s in there is the hostname for the forum and the parent domain name, both of which are configured in the DNS) I noticed that @mpalmer mentioned years ago that adding a second domain could be done but [image]Can Mail Receiver be configured for 2 distinct mail domain? Not trivially, although of course since you have full access to the Postfix configuration, you can make it do whatever you like if you fiddle enough. My recommendation is to have the domain2 e-mails handled by a general-purpose MTA that forwards the e-mails to domain1. So I expected the little relay_domains configuration to not be enough, but it seems to work, given that you git pull before rebuilding. There must be some quirk in the way mail-receiver container is built that fails to update pups…

Somehow the failure returned. This is a bit ridiculous, because previous tests were OK. Now after another rebuild, incoming email is refused again. I resorted to repeat the git pull then rebuild dance but this time it did not seem to work. I suspect the sub-category situation may be playing, unless something changed in the way incoming email is handled with regard to category permissions. The situation is now that people send email, and they receive rejection email, so I have to copy-paste the rejected emails and assign the topics to the original poster. The ‘user experience’ is therefore terrible, and the overhead is pretty obnoxious. I cannot really accept incoming email is a public category, this is the whole point of doing a CFP. But Discourse now seems unable to serve this purpose. :cry:

[image] hellekin: But the category is set to receive email from addresses without an account, so I would expect the email to go through and create a new topic. Are these rejected emails from users who do already have an account?

Some yes. Emails from people with no accounts are rejected (but the category is set to receive email from addresses without an account). Emails from people in the authorized groups seem to get through fine. Emails from people with an account but no access to the category are rejected. It seems to me that the permissions are checked despite the default acceptance setting. I’m currently reviewing mail-receiver container code to see if I can find something there.

For the ones who do have an account but don’t have access to the category, it’s expected that those would be rejected. The Accept emails from anonymous users with no accounts only applies to staged users, and those with an existing account have the category permissions applied. It’s odd that people with no accounts are being rejected. Could this be because of the changes you made to the mail receiver?

So apparently the rejection is handled by the endpoint at /admin/email/smtp_should_reject.json. [image] JammyDodger: It’s odd that people with no accounts are being rejected. Could this be because of the changes you made to the mail receiver? I made the change because emails were bouncing. I first added multiple emails to the incoming email address (separating them with |) and that seemed to work. [image] JammyDodger: The Accept emails from anonymous users with no accounts only applies to staged users, and those with an existing account have the category permissions applied. OK this makes sense. But it’s a bit confusing. If “anyone” can email in, but existing users cannot, it kinds of defeat the purpose. I’m going to check on refused email whether they are staged or not. Thank you so much for helping me debug @JammyDodger.

I think you’re right @JammyDodger, staged users go through, existing users with normal access to the category go through, but existing accounts without access cannot send email to the category. I guess a workaround would be to create a CFP group without any notification for the category that comprises all existing users. But it sounds very hackish and might have side effects of canceling existing notifications… Not sure what to do.

That could… Probably this is what should be done. Do you know whether a group with a muted category will have precedence over another group with the same category set to watching?

So, to summarize: Given a private category with email-in authorized for unknown email addresses (i.e., belonging to no existing account, AKA staged user) → if an email comes in from an unknown address: it is delivered to the private category → if an email comes in from a known address: it is delivered if and only if the user is a member of a group authorized to access the category. Therefore, if you want to use email-in for a CFP, configure a private group’s email-in and use that address. Messages can be “made public” and turned into a topic in a category (private or not).

Private sub-category email-in Discourse::InvalidAccess

Product Support

JammyDodger January 18, 2024, 12:08pm 9

I think people use emailing into a group as an alternative, if that could be useful?

Topic		Replies	Views
Category not accepting "anonymous email" from known users Bug	29	4248	June 12, 2026
Private support categories: staged users can email in, but not registered users Product Support	4	1690	March 27, 2019
Mail address per category Feature	7	2612	March 20, 2017
"Email in allowed groups" setting is too permissive Product Support email , mailing-list	4	528	January 30, 2024
Creating a topic via email without write access to the category? Product Support	3	1810	January 11, 2019

Private sub-category email-in Discourse::InvalidAccess

Related topics