Bug 54231
| Summary: | RFE: Ability to append comments via Email | ||
|---|---|---|---|
| Product: | [Community] Bugzilla | Reporter: | wdc |
| Component: | Bugzilla General | Assignee: | Simon Green <sgreen> |
| Status: | CLOSED UPSTREAM | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.6 | CC: | agk, anton, ebaak, ehabkost, jmcdonal, kbaker, mschick, pzijlstr, sgreen, t.chrzczonowicz |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-05-01 03:25:42 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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 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.
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 Cool. Thanks for the update. *** Bug 467514 has been marked as a duplicate of this bug. *** 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.
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 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 guys, any thoughts, whether you will be working on this RFE or not? (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 set up on the spam filters system. Dave 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. 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 Red Hat Bugzilla won't be developing this enhancement, but will consider adding it if upstream Bugzilla do so. *** Bug 522914 has been marked as a duplicate of this bug. *** 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? (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) |
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!