My follow-up attempt was also blocked, so I'll try to post the report to the forum thread mentioned previously.
--------------------------------------------------------------------------------
Scenario:

# John Doe leaves Example.com and we lock his account (we don't want him logging into Redmine).
#* UserID of jdoe tied to jdoe@example.com
# John Doe notices a problem with the Example.com services/products, so he emails support from his email address.
#* While we don't want him _in the system_ John Doe retains access to his original email account since he is an Example.com customer.
# John Doe's email is rejected and it is moved to @rejected_emails@ where a support person may or may not notice it being there for some time.

Goal:

* Allow overriding the locked account status to credit the email from @jdoe@ as coming from an Anonymous user
--------------------------------------------------------------------------------
The email scraping script used in its present form:

<pre>
#!/bin/bash

cd /opt/redmine

sudo -u www-data bundle exec rake -f /opt/redmine/Rakefile redmine:email:receive_imap \
RAILS_ENV="production" \
host=mail.example.com username=support@example.com password=secretPassword \
move_on_success=accepted_emails move_on_failure=rejected_emails \
project=unassigned category=unassigned tracker=support \
no_permission_check=1 unknown_user=accept port=993 ssl=1 \
allow_override=project,tracker,status,priority,category,assigned_to,\
fixed_version,start_date,due_date,estimated_hours,\
done_ratio > /dev/null 2>&1
</pre>

I could see an option similar to this one being introduced for use with an email scraping script:

unknown_user=[ignore|accept|create]
--------------------------------------------------------------------------------
Deoren Moor wrote:
> Scenario:
> * John Doe leaves Example.com and we lock his account (we don't want him logging into Redmine).
> * UserID of jdoe tied to jdoe@example.com
> * While we don't want him _in the system_ John Doe retains access to his original email account since he is an Example.com customer.
Do employees and customers really share the same maildomain? I'd argue that this is insecure, random customers could identify themselves as employees and trick other customers into disclosing information (phishing)...
--------------------------------------------------------------------------------
Jan Niggemann wrote:
> Do employees and customers really share the same maildomain?

I used 'employee' and 'customer', but really what I had in mind is an educational institution where the same mail domain _is_ shared. I can't speak for others, but ours is setup this way.
--------------------------------------------------------------------------------
This would come in handy and would go nicely with other requests to allow locked accounts to be the target of assignee, author and other queries where they're currently excluded.

Perhaps a UI option to "Reject email from locked accounts" or something similar.
--------------------------------------------------------------------------------