We have been busy with a forthcoming feature for our Issue Tracker, which is the ability to receive emails with details of new issues or emails containing updates to previously raised issues.
After much thought and consideration the following design criteria are 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. Implement Akismet.
- Implement a mechanism to try and ensure that the email FROM address is genuine. Not required if restricting to already ‘known’ users.
- Implement some ‘custom’ email header tags to aid in determining valid ‘update’ emails which are recognised by Issue Tracker.
- 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.
- Provide an option to disallow/allow unknown (public/guest) users from submitting issues.
- 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 progress field.
- Inline replies are not supported. Hence, the additional details should be extracted from the top of the message body.
- 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.
- 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. Already a (partial) component requirement.
One idea we have considered to avoid spam is to send back an email that requires a certain interaction that the user needs to perform. This would probably stop bots but not manual spamming so is not (currently) considered a requirement.
One other thing being considered is using a service such as Mandrill to track the send emails. This might well provide some authentication of the email address, but may be overkill. This might fit nicely into the CMandrill component from Compojoom, but needs further investigation..