A standalone script can be used to forward incoming emails from your mail server.This script reads a raw email from the standard input and forward it to Redmine via a HTTP request.It can be found in your redmine directory: extra/mail_handler/rdm-mailhandler.rb.

In order to use it, you have to enable the API that receive emails:Go to Application settings -> Incoming emails, check Enable WS for incoming emails and enter or generate a secret key.

This line should go in the aliases file, which is usually specified in /etc/aliases. If the location is unknown, use the command postconf alias_maps to find out. After updating the aliases file, be sure to run newaliases to alert Postfix of the new entry.

If your domain is setup as a virtual mailbox map (so that you use /etc/postfix/virtual_mailbox_maps to do mappings in the form user@example.com /path/example.com/user) you should:

Explanation: - When you define virtual_mailbox_maps for a domain the default transport is virtual, which means specifying a local alias in /etc/postfix/virtual will fail (with "unknown user"). To fix this, we override the default transport by specifying a local transport for the email address in question, which means the local alias will resolve correctly, and your script will be executed.

A rake task (redmine:email:receive_imap) can be used to fetch incoming emails from an IMAP server. When you run the rake command from a cron job you can include the switch -f /path/to/redmine/appdir/Rakefile on the rake command, because otherwise the rakefile is not found. This is an example line for a cron file that fetches mails every 30 minutes:

If your setup is working, but you receive mails from the cron daemon, you can suppress the output from the rake command by adding the --silent switch. That should stop cron sending mails on every execution of the command.

project=PROJECT identifier of the target project
tracker=TRACKER name of the target tracker
category=CATEGORY name of the target category
priority=PRIORITY name of the target priority
allow_override=ATTRS allow email content to override attributes
specified by previous options
ATTRS is a comma separated list of attributes

See Issue-attributes for a list of values that can be used for the allow-override option.

Ignored emails are marked as 'Seen' but are not deleted from the IMAP server--these include unknown user, unknown project and emails from the redmine emission account.

The option allow_override is not only for overriding default values given to rake, but for every attribute in a mail. If you want to override the tracker in your mail you have to add allow_override=tracker as a parameter.

A rake task (redmine:email:receive) can be used to read a single raw email from the standard input.

Issue attributes control options:
project=PROJECT identifier of the target project
tracker=TRACKER name of the target tracker
category=CATEGORY name of the target category
priority=PRIORITY name of the target priority
allow_override=ATTRS allow email content to override attributes
specified by previous options
ATTRS is a comma separated list of attributes

See Issue-attributes for a list of values that can be used for the allow-override option.

The option allow_override is not only for overriding default values given to rake, but for every attribute in a mail. If you want to override the tracker in your mail you have to add allow_override=tracker as a parameter.

Redmine has a feature that provides the ability to accept incoming emails from unknown users. In order to use this feature, an extra parameter has to be included:

unknown_user=ACTION how to handle emails from an unknown user where ACTION can be one of the following values:
ignore: the email is ignored (default)
accept: the sender is considered as an anonymous user and the email is accepted
create: a user account is created for the sender (username/password are sent back to the user) and the email is accepted

Permissions have to be consistent with the chosen option. E.g. if you choose 'create', the 'Non member' role must have the 'Add issues' permission so that an issue can be created by an unknown user via email. If you choose 'accept', the 'Anonymous' role must have this permission.

If you receive emails via the rake task, the unknown-user option has to be written as:

unknown_user=[ignore|accept|create]

You can disable permission checking using the 'no_permission_check' option:

TODO: Is this true and is this related to the no_permission_check option?:

Since Redmine 0.9 the project doesn't have to be public, but authentication required in the Administration-> Settings->Authentication tab has to be unchecked.

If you do not want an "new account notification email" sent to every newly created user by rdm-mailhandler you must add the option "--no-account-notice". Is implemneted with 2.3.0 in issue #11498. Now an example:

Instead of using a cron to trigger the Rake task to retrieve incoming email, you can use Rufus Scheduler which will run the Rake task in the same process as Redmine.This is using less ressources and faster than calling the Rake task from a cron (or from the Task Scheduler on Windows).

To do that, install rufus-scheduler gem:

gem install rufus-scheduler

Create a what_you_want.rb file in /config/initializers/ and put the following content in your file. (Here for a POP3 account. Change it with your own parameters and own task.)

When receiving an email, Redmine uses the From address of the email to find the corresponding user. Emails received from unknown or locked users are ignored.

If the email subject contains something like "Re: [xxxxxxx #123]", the email is processed as a reply and a note is added to issue #123. Otherwise, a new issue is created.

Note that, in order to create an issue, all required custom fields must be provided. Without them, issue creation will fail. As an alternative you can ensure that every custom field has a default value which is then used during issue creation.

Of course, user permissions are checked and this email would be ignored if the user who sent this email is not allowed to add issues to project foo.Make sure that the target project doesn't use required custom fields with no default value for its issues, otherwise the creation of the issue will fail.

Based on the options you use when receiving emails (see allow-override option), users may be able to override some attributes when submitting an issue. This can be done by using keywords in the email body.

Example keyword list:

Project

Tracker

Category

Priority

Status

Start date

Due date

Target version

Estimated time

Done ratio

<Custom field name>

The values available are the ones of the context. E.g. Status available (for this Tracker and this Project) are labels in the localized language, exactly as displayed in the user interface or system default language (even with spaces, without quoting).

Example (email body):

This is a new issue that overrides a few attributes
[...]
Project: foo
Tracker: Bug
Priority: Urgent
Status: Resolved

The format for keywords differs from the allowed attribute values for the allow_override option:

project

tracker

status

priority

category

assigned_to

fixed_version (aka. Target version)

start_date

due_date

estimated_hours

done_ratio

Multiple attribute values can be specified in order to allow only certain keywords to be used.

The Administrator's settings may be used to automatically truncate emails, for example to eliminate quoted messages in forum replies. To do this, set the outgoing email header to something like --Reply above this line-- in the Email notifications settings. Then in the Incoming emails settings, enter the same line into the box "Truncate emails after one of these lines." (It is also possible to allow regex to be truncated, using the patch attached to #5864)