Project

General

Profile

Fetched emails going into rejected folder

Added by Deoren Moor about 13 years ago

I have Redmine 1.2.1 installed as of this writing and getting odd results. Some emails are placed in the rejected_emails to begin with, but once I manually move the email back into the Inbox and mark it as unread, it'll be processed on the next try. For several emails, that trick doesn't work.

cd /opt/redmine
RAILS_ENV=production script/about
About your application's environment
Ruby version              1.8.7 (i686-linux)
RubyGems version          1.3.7
Rack version              1.1
Rails version             2.3.11
Active Record version     2.3.11
Active Resource version   2.3.11
Action Mailer version     2.3.11
Active Support version    2.3.11
Application root          /opt/redmine
Environment               production
Database adapter          mysql
Database schema version   20110511000000

A shell script that runs every 5 minutes.

# Purpose: Fetch emails and import into Redmine

# References:
#   * http://www.redmine.org/projects/redmine/wiki/RedmineReceivingEmails

cd /opt/redmine

sudo -u www-data rake -f /opt/redmine/Rakefile redmine:email:receive_imap \
    RAILS_ENV="production" \
    host=host.example.com username=user@example.com password=example \
    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=tracker,priority,project,status,category > /dev/null 2>&1

Where can I configure the rules to accept all emails from a particular domain, no matter what flags might be tripped? Is there documentation for tuning this?

Thanks.


Replies (1)

RE: Fetched emails going into rejected folder - Added by Deoren Moor over 11 years ago

To respond to my own question, it seems that the production mode doesn't enable logging of useful email-related troubleshooting information. Instead, as suggested by this post, you'll need to enable development mode.

For me this was as easy as copying/pasting/editing the email and database config sections to say development instead of production. In addition, I modified the "scraping script" to use RAILS_ENV="development" instead of RAILS_ENV="production".

I then saw that in our most recent case of this problem that it was due to an account that we'd long forgotten about being locked. I modified the email address to have a prefix of no-longer-works-here- and am considering that an acceptable workaround for now. Now that I know about the differences in logging between production and development, I'll switch to development mode when I need to troubleshoot email scraping problems.

    (1-1/1)