Redmine incoming email and helpdesk-style issue creation

Choose between forwarding and polling before anyone configures a mailbox, because the choice decides who on your mail platform has to act, how messages behave during an outage and where credentials live. With forwarding, your mail server receives messages for a support address and hands a copy to Redmine's incoming email handler, usually through a rule, alias or transport route that you or your mail administrator create. Redmine does not reach out to fetch anything; it waits for the server to deliver. With polling, Redmine connects to a mailbox over IMAP or POP3 on a schedule, reads unseen messages, creates or updates issues and then marks or moves those messages according to its settings. The Redmine configuration guide describes both paths, and the exact options, supported protocols and any mailbox handling behavior depend on your mail provider and your Redmine version, so confirm them there before you commit. Forwarding puts the work on the mail platform side. Your mail administrator must create the forwarding rule or connector, decide whether it sends the original message or a copy, and confirm that the sending address and any authentication headers are accepted by Redmine's receiving process. Polling puts the work on the Redmine side and on the mailbox. Someone must create a dedicated mailbox, enable IMAP or POP3 access if the provider has it disabled, grant an application credential or service account access, and decide whether modern authentication such as OAuth is available for that account. Ask your provider which of these are supported for your tenant before you plan the build. Outages behave differently. If Redmine is down or the poll fails during a forwarding period, the mail server may queue, defer or bounce messages according to its retry policy, and a bounce can reach the original sender. With polling, messages usually stay in the mailbox until Redmine returns and reads them, which makes the mailbox itself a buffer, but the delay is only as safe as the retention settings on that mailbox. Test what your provider does to unread mail after a failed login, and decide how long a backlog is acceptable for your support queue. Credentials and rotation need an owner. A polling setup stores a mailbox password or token in Redmine's configuration, so it becomes a secret that must be protected at rest, excluded from shared configuration exports and rotated when staff change or your password policy requires it. Forwarding usually avoids storing a mailbox credential in Redmine, but it still relies on a shared secret or allowed-sender controls for the receiving side. Document where each secret lives, who can read it and what happens to intake when it is rotated. A shared mailbox also conflicts with personal inboxes. If a support address is also a person's mailbox, polling may mark messages as read or move them before that person sees them, and replies sent from personal accounts may never reach Redmine. Use a dedicated support mailbox, agree with users that replies go to the support address, and check how Cc'd staff are treated, since that interacts with automatic watcher behavior covered elsewhere on this page.

When Redmine creates an issue from an email, the addresses in the To and Cc fields can be turned into watchers on that issue. A watcher is not assigned work, but watchers receive notifications about later changes and can see the issue within the limits of their project role. That makes the To and Cc list a visibility decision as well as a convenience. Before you enable this behavior, decide who should receive updates on a ticket that began as an email, and whether the answer changes depending on who sent the message. The main exposure comes from people who are on the original thread but should not be on the issue. A customer or supplier copied on the first message may be matched to an existing Redmine account, such as a portal user from another client, and then receive every later note that the account is allowed to see. Internal staff who reply all to a thread that includes an outside party can also add that party to the issue at a later point, depending on how your installed version handles replies. Treat every address on the message as a possible future recipient.

Matching watcher rules to project roles is the control that most often prevents over-sharing. A watcher should receive notifications only when their role in that project allows them to view the issue and the relevant notes. Review each role that could be attached to an external or cross-client account, and confirm which permissions it grants on issues, notes and attachments. Keep internal-only discussion in private notes, and confirm that private notes are withheld from watchers whose role does not allow viewing them in your installed version. Do not rely on the sender's domain as a proxy for trust, because a domain can belong to a partner, a reseller or a shared mail provider.

Run a test with mixed recipients before you enable automatic watchers for a live mailbox. Use a test project and send one message that includes an internal user with the intended role, an external user with a portal-style role, an address with no Redmine account, and a user whose role lacks view permission. Then check the watcher list on the created issue, the recipients of the notification emails, and whether private notes added afterward reach the external accounts. Record the outcome for each address so you can compare it with the design, and keep the record with your change documentation.

Confirm all of this in the Redmine version you run, and retest after each upgrade or plugin change, because mail handling and notification rules are areas where behavior can shift between releases. Ask the team that owns the mail configuration to name the setting that controls watcher creation, to state whether unregistered addresses are ignored, and to show where private notes are filtered from notifications. If a plugin changes mail handling, include it in the test. Once the results match your role design, write down the approved behavior so that future changes to the mailbox or project roles trigger a new review.

Once email intake is live, the operations team needs a short, repeatable watch list, because most intake failures are quiet. The first signal is failed fetches: if Redmine polls a mailbox over IMAP or POP3, a expired password, a changed server certificate or a mailbox quota problem stops new issues from appearing without any error in the user interface. The second is rejected messages. Redmine logs messages it cannot turn into issues or notes, for example when the sender is unknown and anonymous creation is not allowed, or when the keyword overrides point to a project or tracker that does not exist. Review these logs on a schedule and assign an owner for each category, so rejected mail does not disappear into a shared inbox nobody reads.

Duplicate issues from reply threads are the failure users notice first. When a reply loses its threading headers, or a mail client rewrites the subject, the message can open a new issue instead of adding a note to the existing one. Check a sample of newly created issues each week against the threads they came from, and record which mail clients or forwarding paths cause the most splits. Mailbox growth is the slow risk. If Redmine reads from a mailbox that is never cleared, or if messages are only marked as read, the mailbox and the fetch time both grow. Ask the mail team what retention and archival rules apply to the intake address, and confirm who deletes or archives processed messages.

Intake rules should be managed as configuration, not as one-off edits in production. Record each keyword override, default project and tracker, unknown-sender setting and watcher rule in a change log with the reason for the change, and test each change against a copy of a representative mailbox before it goes live. The Redmine upgrade guide requires copying configuration and third-party plugins to the new installation and then running the database and plugin migrations, so every upgrade should end with a documented test of intake: send a new message, a reply and a message from an unknown sender, then confirm the expected result for each.

Background job tooling needs a decision too. The Redmine installation guide lists Sidekiq among optional components for background job queues in production. Whether your intake design depends on it, for example to process mail asynchronously at volume, is a question to confirm against the guide for the Redmine version you plan to run and against your chosen fetch method, before the design is final. If Sidekiq is part of the design, add its queue depth and failed jobs to the watch list and include it in the upgrade test. Ask your implementation partner to show where these checks sit in the runbook and who receives the alerts.