Bug 54231 - RFE: Ability to append comments via Email
RFE: Ability to append comments via Email
Status: CLOSED UPSTREAM
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
3.6
All Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: Simon Green
: FutureFeature
: 467514 522914 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-01 22:54 EDT by wdc
Modified: 2014-10-12 18:45 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-30 23:25:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 943052 None None None Never

  None (edit)
Description wdc 2001-10-01 22:54:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913

Description of problem:
Some bug tracking systems not only operate from within a set of
web forms but also take as their input submissions via email.

It makes perfect sense that, with all the additional bits, OPENING 
a bug in bugzilla should have to be done via the forms interface.

But when the dialog about the bug gets going, it is kind of a pain
to start up a web browser, go to the bug, and THEN add in my reply
to the other person's reply.

It would be a wonderful enhancement if I could hit REPLY in my
email program and append a comment via email.  Perhaps this has
not been added because of the tricky issue of authenticating the
submitter.  (IE email reply is BAD if someone could use email to spam
the bug list.)

I suggest that getting to the other side of that issue is not 
too terribly difficult:
     Run an MD5 hash on some of the outgoing reply that contains 
text that has some chance of being fairly unique.
     Include some text with "Reply must contain this text to
be accepted as a valid reply" bracketing.
     Then have an incoming email account with a parser, and an MD5
validator, and make that another input stream to bugzilla.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.hit the reply key to a bugzilla message
2.watch it come flying back in your face  :-)
3.
	

Additional info:

Thanks for a great bug tracking system!
Comment 1 David Lawrence 2006-04-08 13:51:41 EDT
Red Hat's current Bugzilla version is 2.18. I am moving all older open bugs to
this version. Any bugs against the older versions will need to be verified that
they are still bugs. This will help me also to sort them better.
Comment 2 wdc 2008-08-18 17:46:55 EDT
Thanks VERY much for digging it out of the dusty corner in which this enhancement request has sat for all this time.

Inasmuch as the report from this Bugzilla still says:

        On Aug 18, 2008, at 5:39 PM, bugzilla@redhat.com wrote:

        Please do not reply directly to this email. All additional
        comments should be made in the comments box of this bug.


        https://bugzilla.redhat.com/show_bug.cgi?id=54231

This enhancement request is STILL VALID.
YES it is verified against the current Bugzilla code base.
And  YES the original opener of the request is still around and still cares.
Comment 3 David Lawrence 2008-08-18 17:57:11 EDT
The code/functionality is there in Bugzilla for doing this as well as submitting new bugs through email. Problem is getting buy in from IS/IT to allow bug mail to be delivered to a server that has access to the Bugzilla database or to create an email -> XMLRPC gateway that can do the same from anywhere. Also there is the issue of security/authentication which I am not entirely sure the upstream has perfected yet. We do not want it where anyone can forge the From: header to allow a comment or bug to be created as someone completely different.

We are looking into this though. In the meantime there is also the XMLRPC api for submitting bugs which allows anyone to create simple command line clients for Bugzilla without having to always go to the web UI.

Dave
Comment 4 wdc 2008-08-21 17:28:58 EDT
Cool.  Thanks for the update.
Comment 5 Kevin Baker 2008-11-21 14:43:10 EST
*** Bug 467514 has been marked as a duplicate of this bug. ***
Comment 6 David Lawrence 2009-01-22 11:57:51 EST
On Thu, Jan 22, 2009 at 11:49:13AM -0500, David Lawrence wrote:
> > Kevin Baker wrote:
>> >> On Wed, Jan 21, 2009 at 10:22:27PM -0500, David Lawrence wrote:
>> >>   
>>> >>> There is a Bugzilla report for this RFE but it has not been given   
>>> >>> priority in a while.
>>> >>> We would need to take another look at it as time allows.
>>> >>>
>>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=54231
>>> >>>     
>> >>
>> >> I spoke with Schick about it. The main objection is the huge amount of
>> >> spam bugzilla would be subject too and hence degraded performance.
>> >>
>> >>   
> >
> > That and the fact we don't have a secure mechanism for verifying that  
> > the email was sent from
> > whom it says it was. Anyone can forge a From: line and add comments to  
> > bugs posing as someone
> > else.
Comment 7 David Lawrence 2009-01-22 12:51:41 EST
Various useful links:

Documention on how to configure procmailrc for receiving email on the server:
https://bugzilla.mozilla.org/show_bug.cgi?id=267022

Allow unregistered users to submit bugs via email:
https://bugzilla.mozilla.org/show_bug.cgi?id=36341

Use of issued tokens to allow email submissions (i like this):
https://bugzilla.mozilla.org/show_bug.cgi?id=419203

The token would work as follows as I understand it:

1. A user sends a bug change of any kind (create/append/edit) to the email gateway of Bugzilla. 
2. Bugzilla checks that the email contains a valid token for the user specified in the From: header.
3. If the token is valid it allows the submission to happen.
4. If the token is missing or invalid, it emails back an email to the user with a token that can used. This essential verifies the From: person is who they say they are.
5. The user resubmits their change using the newly issued token.
6. The tokens are set to expired after a admin determined amount of time.
7. The user never has to the website to get a token.

Dave
Comment 8 David Lawrence 2009-01-22 12:53:24 EST
8. This blocks spam from being added to Bugzilla. Bugzilla will parse the letter and if it doesn't look like a valid bug email, then /dev/null. Also if it is a valid email but not a valid token, then a token is issued and the email is /dev/null. 

Dave
Comment 9 Anton Arapov 2009-02-27 06:08:05 EST
guys, any thoughts, whether you will be working on this RFE or not?
Comment 10 David Lawrence 2009-02-27 12:11:38 EST
(In reply to comment #9)
> guys, any thoughts, whether you will be working on this RFE or not?

It is slated to be worked on but has taken a back seat to some other requests recently. We will be starting a new on this request very soon now. We have to do some things along with GIT to allow this to happen as they have to enable
email delivery to the Bugzilla webapps as well as get bugzilla@redhat.com set up on the spam filters system.

Dave
Comment 11 Alasdair Kergon 2009-04-24 18:49:27 EDT
Ideas:

(1) Tokens are either in a custom header or the first line of the message (a la majordomo).

(2) The standard bugmail sent by bugzilla contains a header with the token, so you can configure your mailer to retain that header and simply reply to the message in the normal way.  (Bugzilla could additionally validate that the from address, subject line with bug number and the token match.)  But we already have a header which does what we need - In-Reply-To, since the server is in control of the message-id.  (It does perhaps get logged in more places than we might wish though.)

(3) Or we could just ask people wanting to use this facility to upload their GPG key and require people to sign their messages.
Comment 12 David Lawrence 2010-08-25 17:41:18 EDT
Red Hat has now upgraded to Bugzilla 3.6 and this bug will now be reassigned to that version. It would be helpful to the Bugzilla Development Team if this bug is verified to still be an issue with the latest version. If it is no longer an issue, then feel free to close, otherwise please comment that it is still a problem and we will try to address the issue as soon as we can.

Thanks
Bugzilla Development Team
Comment 14 Simon Green 2012-04-30 23:25:42 EDT
Red Hat Bugzilla won't be developing this enhancement, but will consider adding it if upstream Bugzilla do so.
Comment 15 Simon Green 2012-05-10 09:19:43 EDT
*** Bug 522914 has been marked as a duplicate of this bug. ***
Comment 18 Jason McDonald 2013-11-20 03:24:07 EST
While I'm not philosopgically opposed to this RFE, I can foresee that there would be significant infrastructure and behavioural issues to overcome in addition to getting an acceptable version of the feature into the upstream Bugzilla.

For example:

* We'd need to prevent malicious attempts to spam the system with large numbers of emails, to chew through all the available database storage by submitting very large comments, or to fill up available log storage with messages the attacker knows will be rejected but logged.

* We'd need to prevent the feature from adversely impacting overall system performance, e.g. by running it on a separate machine(s) to the web server(s).

* We'd need to figure out how to avoid the spurious unnecessary quoting of previous comments that blights the RT system.

* We'd need to figure out what to do when a user tries to comment on a bug that they don't have privileges to comment on via the Web UI. For example, sending them a rejection email could actually leak information if we're not careful.

* As Alasdair points out, we'd need to figure out what to do about private comments.

* If allowing new bugs to be filed by email, how would we ensure that mandatory fields are provided (e.g. Classification/Product/Component)?


I'm also yet to be convinced that the productivity gain this feature would enable would outweight the cost of implementing the feature.  If this feature would save users 30 seconds per comment, how many times would the feature have to be used before that saving would outweigh the development and infrastructure cost of the various pieces of the solution?
Comment 19 Eduardo Habkost 2013-11-20 07:47:56 EST
(In reply to Jason McDonald from comment #18)
> I'm also yet to be convinced that the productivity gain this feature would
> enable would outweight the cost of implementing the feature.  If this
> feature would save users 30 seconds per comment, how many times would the
> feature have to be used before that saving would outweigh the development
> and infrastructure cost of the various pieces of the solution?

While I agree that it would be interesting to have more evidence that the gains outweight, the gains are not measured in "seconds not spent", but in "useful information that could be in Bugzilla but it is not there", because the extra clumsy steps required to just add a small comment to a bug inhibits the sharing of information on Bugzilla. People end up just using private e-mail or mailing lists to comment about bugs. (Which is not necessarily a bad thing, in some cases: this may help reduce the level of noise on BZ comments)

Note You need to log in before you can comment on or make changes to this bug.