Category not accepting "anonymous email" from known users

I looked at the code and it seems to me that:

  1. if authserv_id is enabled
  2. Email::AuthenticationResults will assign either fail or pass verdict, which results in enqueue or accept action
  3. Posts with enqueue action will be marked for review/approval (lib/new_post_manager.rb - self.post_needs_approval?)

Is my reasoning correct?
Does this mean attempts at spoofing would probably end up in review?

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

1 Like

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)

  1. Email received from address with no user; staged user created, new topic created.
  2. " " " address with staged user; staged user matched, new topic created.
  3. " " " address with real user with create permission; real user matched, new topic created.
  4. " " " 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?

Yes, mail from staged/non-activated users would (should?) have not been accepted in my original scenario.

1 Like

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.