Want a fast and easy way to file a bug?

Now you can file bugs simply by sending an email.

Bugzilla, hosted by devZing, has a feature that allows a user to send an email to an email address. Bugzilla reads the email and automatically inserts a bug into Bugzilla with the content of the email.

Interested? Here’s how it works…

Set up

Administrators: Start with an email address your users can send their defects and comments to. Log into your devZing account (http://devzing.com/login) and Choose Email Bugs from the Bugzilla menu.

Note that all the email in this account with be read and deleted. So don’t enter your personal email account – you have been warned.

The port number depends on how the mail server is set up. Typical port assignment: POP3=110, IMAP=143, Secure IMAP (IMAP4-SSL)=585, IMAP4 over SSL (IMAPS)=993, Secure POP3 (SSL-POP)=995.

If you don’t know the value for one of the fields check with your System Administrator. (Or check your email provider’s help documents.)

Helpful hint: Use the Account Log (Settings -> Account Logs) to track errors once users start sending emails.

If you are using Gmail you will need to enable POP or IMAP access, see https://support.google.com/mail/answer/7126229. You may need to change the Google “Less secure apps” setting. Be sure you are only signed into the gmail account that Bugzilla will use then go to https://www.google.com/settings/security/lesssecureapps and make sure it is set to “Turn off”

Click the Test button to ensure devZing can communicate with your mail server and if successful click Save.

Sending the Emails

Users must follow a few guidelines when they send emails to the administrator. These are necessary steps to enable Bugzilla to receive and correctly read the emails.

  • First get the bug submission email address from your Bugzilla administrator. Your “from” email address must be the same address you use to login to Bugzilla.
  • Subject Line: Put a summary of the bug as your subject line.
  • The text of the email will be the bug description
  • Any fields (see below) must be specified before your bug description.

Here is a list of all the different fields you can specify in your email:

Field Name Description MustMatch?* Required?
@product The name of the product the bug is being filed against. Yes Yes
@component The name of a component in the product above. Yes Yes
@version A version of the product above; the version the bug was found in. Yes Yes
@summary A brief description of the bug being filed. If you specify this field it will override the summary you specified in your email subject line. No No
@platform What type of hardware the bug was experienced on. Yes Maybe**
@severity How severe the bug is. Yes Maybe**
@op_sys The operating system the bug was discovered on. Yes Maybe**
@priority What order the bug will be fixed in by the developer compared to the developer’s other bugs. Yes Maybe**
@alias A brief alias for the bug that can be used instead of a bug number when accessing this bug. Must be unique in all of this Bugzilla.   No No
@assigned_to A user to assign this bug to if you don’t want it to be assigned to the component owner. Yes No
@qa_contact If this installation has QA Contacts enabled you can set the QA Contact here if you don't want to use the component’s default QA Contact. Yes No
@status The status that this bug should start out as. Note that only certain statuses  can be set on bug creation. Yes No
@target_milestone A valid target milestone for this product. Yes No
@cc A comma separated list of users to CC on this bug. Yes No
@id Specifies the bug number to modify. See “Modifying an Existing Bug”  below for more information. Yes No
@removecc A comma separated list of users to remove from the CC list on this bug. Yes No

* The value must match exactly one of the names defined in your Bugzilla for this field.
** It is possible that your Bugzilla administrator has provided a default value for this field.

In addition to the above parameters, if your installation has any custom fields, you can set them just by passing in the name of the field and its value as a string. Remember that all custom fields start with cf_ so for example you might specify

@cf_mycustomfield custom value

The values for the fields can be split across multiple lines, but note that a new line will be parsed as a single space, for the value. So, for example:

@summary This is a very 
long description

Will be parsed as “This is a very long description”.

Because of this you will need to add a blank line before your description if your description is after your fields.

Note that signatures must start with “–“, the standard signature border.

Modifying an Existing Bug

Bugzilla determines what bug you want to modify in one of two ways:

  • Your subject starts with [Bug 123456] — then it modifies bug 123456.
  • You include @id 123456 in the first lines of the email.

If you do both, @id takes precedence.

You send your email in the same format as for creating a bug, except that you only specify the fields you want to change. If the very first non-blank line of the email doesn’t begin with @, then it will be assumed that you are only adding a comment to the bug.

Note that when updating a bug, the Subject header is ignored, except for getting the bug ID. If you want to change the bug’s summary, you have to specify @summary as one of the fields to change.

Please remember not to include any extra text in your emails, as that text will also be added as a comment. This includes any text that your email client automatically quoted and included, if this is a reply to another email.


If your request cannot be completed for any reason, Bugzilla will send an email back to you. If your request succeeds, Bugzilla will not send you anything.

If any part of your request fails, all of it will fail. No partial changes will happen.


The script does not do any validation that the user is who they say they are. That is, it accepts any ‘From’ address, as long as it’s a valid Bugzilla account.