<<

email_in.pl

NAME

email_in.pl - The Bugzilla Inbound Email Interface

SYNOPSIS

 ./email_in.pl [-vvv] < 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.

DESCRIPTION

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

Creating a New Bug

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

 From: [email protected]
 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.

 -- 
 This is a signature line, and will be removed automatically, It will not
 be included in the bug description.

The @ labels can be any valid field name in Bugzilla that can be set on enter_bug.cgi. For the list of required field names, see "Create" in Bugzilla::WebService::Bug. Note, that there is some difference in the names of the required input fields between web and email interfaces, as listed below:

For the list of all field names, see the fielddefs table in the database.

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:

 @short_desc = This is a very long
 description

Will be parsed as "This is a very long description".

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

[email protected] must be a valid Bugzilla account.

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:

If you do both, @bug_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 @short_desc 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

You can't just add CCs to a bug by using the @cc parameter like you can when you're filing a bug. To add CCs, you can specify them in a comma-separated list in @newcc.

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

Errors

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.

There is no attachment support yet.

CAUTION

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. So make sure that your MTA validates that the message is actually coming from who it says it's coming from, and only allow access to the inbound email system from people you trust.

LIMITATIONS

Note that the email interface has the same limitations as the normal Bugzilla interface. So, for example, you cannot reassign a bug and change its status at the same time.

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

You cannot send an HTML mail along with attachments. If you do, Bugzilla will reject your email, saying that it doesn't contain any text. This is a bug in Email::MIME::Attachment::Stripper that we can't work around.

You cannot modify Flags through the email interface.

<<