5.7.125. email_in¶

5.7.125.1. NAME¶

email_in.pl - The Bugzilla Inbound Email Interface

5.7.125.2. SYNOPSIS¶

./email_in.pl [-vvv] [–default name=value] [–override name=value] < email.txt

Reads an email on STDIN (the standard input).

Options:

--verbose (-v)        - Make the script print more to STDERR.
                        Specify multiple times to print even more.

--default name=value  - Specify defaults for field values, like
                        product=TestProduct. Can be specified multiple
                        times to specify defaults for multiple fields.

--override name=value - Override field values specified in the email,
                        like product=TestProduct. Can be specified
                        multiple times to override multiple fields.

5.7.125.3. DESCRIPTION¶

This script processes inbound email and creates a bug, or appends data to an existing bug.

Authentication¶

To be able to use this function you must register your PGP key with bugzilla. Any emails you send to bugzilla must be cryptographically signed with the registered key. Any emails that do not have this signature, fail validation, or do not have a corresponding public key configured in bugzilla will be discarded.

Configuring a public key¶

To configure your public key, simply visit the user preferences page, click on the Secure Mail heading and paste your GPG key in the text box.

Creating a New Bug¶

The script expects to read an email with the following format:

From: account@domain.com
Subject: Bug Summary

@product ProductName
@component ComponentName
@version 1.0

This is a bug description. It will be entered into the bug exactly as
written here.

It can be multiple paragraphs.

For the list of valid field names for the @ fields, including a list of which ones are required, see “create” in Bugzilla::WebService::Bug. (Note, however, that you cannot specify @description as a field– you just add a comment by adding text after the @ fields.)

The values for the fields can be split across multiple lines, but note that a newline 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”.

If you specify @summary, it will override the summary you specify in the Subject header.

account@domain.com (the value of the From header) must be a valid Bugzilla account and the address must be specified in the PGP key specified in the account’s preferences.

Mail signatures that comply with rfc3676 will be removed from the description and comment text. This format contains a trailing space and can be difficult for users to identify.

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.

Adding/Removing CCs¶

To add CCs, you can specify them in a comma-separated list in @cc.

To remove CCs, specify them as a comma-separated list in @removecc.

Errors¶

If your request cannot be completed for any reason, Bugzilla will NOT 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.

5.7.125.4. LIMITATIONS¶

The email interface only accepts emails that are correctly formatted per RFC2822. If you send it an incorrectly formatted message, it may behave in an unpredictable fashion.

You cannot modify Flags through the email interface.

This documentation undoubtedly has bugs; if you find some, please file them here.