This section looks specifically at the areas/concerns around using email to both create/open new issues and also using email to update existing issues. This feature makes use of the Cron facility discussed earlier, and because it is such a involved task is worthy of a section in its own right.
There are two situations where email could be useful. The first is for receiving emails about new issues and the second is for receiving updates for already existing issues.
The following design criteria is deemed necessary in the email issues functionality. They are included in no specific order of priority.
-
Ensure that there is a clear record of the person who is reporting the email. This effectively means relying upon the senders email address.
-
Need to ensure that the Issue Tracker is not open to spam in the received email.
-
Implementing a mechanism to try and ensure that the email FROM address is genuine.
-
Support different types of email formats and protocols (e.g. POP3, IMAP).
-
Ensure that the installation retains control of the issues in their system (i.e. make sure no one can report a single issue that has undesirable links). An installation doesn't want their customers/users to login to their issues and find porn and other undesirable related issues.
-
The reporting by email feature should be disabled by default.
-
Use one dummy email account to associate with all received emails, and use the originating email address as part of the criteria for determining who is raising/updating the issue.
-
When a user reports an issue via email, a confirmation email should be sent to the originating email address. This should be independent of whether we set the reporter as a unregistered or a registered account.
-
When an email is received for an existing or a new issue, the assignee should be sent an email, except if the assignee has indicated that they should NOT receive emails.
-
When an update to an issue is received, an email should only be sent if the user has a flag indicating that an email should be sent.
-
Attachments to emails should be added as attachments in the Issue Tracker component.
-
Must be able to handle mime/multi-part emails.
-
Replies to existing issues to be added to the ongoing progress field.
-
Inline replies are not supported. Hence, the additional details should be extracted from the top of the message
-
Look for and use a “——please reply above this line——” (or administrator define string) in the incoming email for updated issue emails. Add such a string to the outgoing notification email.
-
Provide an option to disallow/allow unknown (public/guest) users from submitting issues
-
Unknown users should require a reply validation hash to prevent spamming of the issue tracker.
-
Look up a Issue Tracker account based on an email. If an account if found use it, otherwise, there should be an option to reject the email or auto-create an unregistered account.
-
Ensure email addresses are unique. i.e. Multiple users cannot have the same email address.
-
One idea to avoid spam is to send back an email that requests a certain interaction that the user needs to do. This would probably stop bots but not manual spamming.