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
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.
(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
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.
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.
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.
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.
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).
