Reporting via Email

• Keeping track of who reported an issue.
• Making sure we don't open Mantis to spam.
• Making sure that users don't spoof the email FROM address to impersonate other users.
• Support different types of email formats and protocols (e.g. POP3).
• Making sure a company keeps control on the issues in their bug tracker (i.e. make sure no one can report a single issue that has spam links). A company doesn't want their customers to login to their bugtracker and find spam issues.

giallu

Do we really think mantis can control/avoid SPAM when google itself can't? If a company receives spam, the problem is on the mail server, not on the mantis installation.

• The reporting by email feature should be disabled by default.
• Use one dummy account to associate with all emails, in this case the originating email address should be included in the issue description.
• When an event triggers a notification to the reporter of the issue, this should cause an email to be sent to the email address from which the issue was reported. This should be independent of whether we set the reporter as a dummy account or a real account.
• Attachments to emails or replies to notifications should be added as attachments.
• Handle mime/multi-part emails.

• Ability to retrieve email messages from POP3 accounts.
• Support for one email account per project or one for all projects. (Ari Maniatis I don't think this is needed - it is trivial for most Mantis admins to arrange for several email addresses to be delivered into the same POP account)

giallu

Could we start from a tenfold easier scenario like: ability to process an email from the standard input? did I say, pretty please?

A mechanism to allow various fields (project, category, priority, etc) to be set in a task would be useful.

• Support some sort of way to annotate email messages (e.g. setting attributes other than summary, description and project).
• Using a catch-all Mantis email address, route email by destination address:
  • new@bugs.mantisbt.org - creates a new bug (default project)
  • project@bugs.mantisbt.org - creates a new bug in that project, default category
  • project.category@bugs.mantisbt.org - creates a new bug in that project and category
    • substitute space for underscore character appearing in name, e.g., Feature_Requests becomes “Feature Requests”

Ari Maniatis: I don't believe the above is particularly important. The main use for email submission is for customers who can't be expected to use a task tracking system, particularly when the tasks are system admin or sales requests. If the customer/user can be taught to send emails to a range of complex addresses, then they will probably be able to use a web submission form. Also, in almost every case we need to be able to categorise the task, set priorities, etc ourselves since the customer would mostly get it wrong (everything they submit is super-high priority!). So the workflow involves us editing every incoming task regardless.

If automated collection of this metadata is important, I'd suggest a template block at the top of the incoming email rather than trying to overload the email address with meaning. In fact, even better would be to follow the existing Bugzilla format. It has been well thought through and the compatibility would be useful.

http://www.bugzilla.org/docs/3.0/html/api/email_in.html

giallu

+1 to what Ari said and +100 to using an established format like the one proposed. Moreover, I wonder how you can expect a sysadmin to create all those email addresses just for mantis usage. IMHO everything should work with a single email address

123@bugs.mantisbt.org - comments and attachments to issue 000123

• permits email conversation by replying to (or CC'ing) 123@bugs.mantisbt.org
• simplifies code for email-to-bugid lookup (performance)
• explicit references handles cases where subject line is changed/removed

Ari Maniatis Again, rather than overloading the email address with meaning, I'd suggest overloading the subject. There is considerable precedent for this approach: [bug 1234] broken on IE 7 Naturally we'd need to look beyond “re:”, “aw:” and similar prefixes.

giallu 123@b.m.o implies we would need an email address for each bug: not really desiderable

• If a user replies to a notification related to an issue, then the new part in the reply should be added as a note. Inline replies are not supported. Hence, the note will be extracted from the top of the message. We should check for and remove the most common reply separators such as “on .+ replied with”, etc.
• Erring on the side of caution, if there are inline replies, the entire message should be stored. This might be difficult to detect since many mailers reformat the quoted text considerably (eg. Outlook ugh…). Once solution is to put “——please reply above this line——” in the outgoing email.

• Preference to disallow/allow unknown users from submitting issues
• Unknown users should require a reply validation hash to prevent spamming of the issue tracker.
• Support looking up a Mantis 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 the account.
• In the case where there are multiple users with the same email, then we should do the following:
  • Filter out the accounts appropriate access to report the issue to the target project.
  • Prefer accounts that were used to logged in rather than the ones that never logged in.
  • Select the account with least privilege, this is to handle the scenario where a user has an administrator and a developer or manager account.
• When a user reports a task via email, a confirmation email should be sent to the originating email address.
• An 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.
• Submissions from unregistered users:
  • For unverified email addresses, put submissions in holding queue
  • Email address verification through confirmation email or PGP signature (if message was signed)
  • Restrict anonymous notes/attachments to the original submitter

Ari Maniatis:

• Why do multiple Mantis users have the same email address? Can it be made a requirement that they are unique?
• We need the ability for users to have multiple email addresses. This is very common for our customers.