Sort of, this will be sent to the approve queue if DMARC fails, but if it is totally absent it will still go through.
Perhaps one way of pushing forward would be to add an explicit site setting that basically say āsite operator accepts riskā and if enabled allow mapping based on email
Iām a bit confused by the bug vs. intended behaviour debate. The way I have interpreted it is that for security reasons, creating new topics via email is not permitted if the email address matches an existing non-staged user; this is because email addresses can be spoofed and therefore users could be impersonated.
Replies are presumably acceptable because the address includes the reply key, demonstrating that the sender was the recipient of the notification email and is therefore likely the real user.
If that interpretation of the intended behaviour is correct, it is contradictory to what Iām actually experiencing. If my user does have permission to create in the category and I send an email from my registered email address to the categoryās email_in address, the email address is matched to my user and a new topic is created by my user.
This happens irrespective of whether accept emails from anonymous users with no accounts is enabled, since my user does have permission to create.
The current situation seems to be: (with email in anonymous users enabled)
Email received from address with no user; staged user created, new topic created.
" " " address with staged user; staged user matched, new topic created.
" " " address with real user with create permission; real user matched, new topic created.
" " " address with real user without create permission; real user matched, new topic rejected.
(Note: I did not test 4 just now) With email in anonymous users enabled, I would expect 3 and 4 to always behave the same. Whether that is both rejected to protect against impersonation or both accepted on the basis that a real user shouldnāt have fewer permissions than an anonymous user, they shouldnāt have different results.
The OP is all about secured categories (eg a category that anonymous can not even see). In that case staged users would certainly be rejected today, no?
Iāve just tested this to confirm the behaviour on our instance (20 commits behind, canāt see anything related in the changes). We have all posts by trust level 0 users require approval and I wasnāt sure if that would affect the route, so I extended the steps to test without that interfering.
These steps all relate to a category where the admin group has see/reply/create and no other permissions are set, an email in address is set and accept emails from anonymous users with no accounts is enabled.
ā>ā denotes an effect rather than an action.
Send email from address with no user
> Staged user is created, new post goes into review queue
Approve post
> New topic is created in private category
Change trust level of staged user to 1
Send another email from same address
> New topic is created in private category
If that didnāt happen, the accept emails from anonymous users with no accounts setting would have no purpose on categories that do not have either everyone or trust_level_0 with create permission.
I believe this is equivalent to #4 in the OP where the OP describes both #3 and #4 being expected to result in a new topic, however only #4 does.
With my previous post (before āThe current situationā), I was mostly aiming to discuss this point more generally, which seems to argue that #3 should not work because the way it currently works protects against users being impersonated.
However, as I describe in that post, that protection doesnāt exist where a matched user has create permission.