bug_email.pl will refuse to allow you to enter any bugs if you are not already a registered user. We've whipped up a quick patch to allow users to contribute bugs if they are not already registered with the system -- bug_email.pl now automatically emails them back with a username and password, then files their bug for them. This has the potential for abuse, so we added the variable $Allowall which, if set to 0, doesn't allow this behavior (should probably be the default). Diff follows: ------------------------------------------- 77d76 < require "CGI.pl"; 88d86 < my $Allowall = 1; 191,199d188 < < #This allows a non registered user to submit bugs. < if($Allowall){ < if(!findUser($Name)){ < my $T_password = InsertNewUser($Name, $Name); < MailPassword($Name, $T_password); < } < } <

I really like this idea. However, due to the abuse potential, I think if you have this turned on, any new bugs should automatically go into the Pending Bugs access groupset (not the product/category, just that groupset), so that they need to be "released" if you call it that by the owner before they'll be visible to the public. Of course, not everyone likes that idea, but the ability should be there so you can configure it that way.

This is an interesting idea. I kinda like it. It seems that bugzilla has two modes of operation, potentially, as a developer collaboration tool (you need an account, you have accountability) and as an open bug receiver, like gnats. Maybe we should think about seperating out those two aspects a little bit?

Also, allowall and variables like that should Params(). If someone wants to change the assignment, I can take this and integrate it into bug_email.

I've added this as a block for 36379, which was a related change we made to support command-line options specifying product & component it goes into. I'm not sure you need to sandbox them into only a "PENDING" groupset -- if we make the changes suggested in 36379, you can specify the defaults from which email alias it gets it. It works well -- we have a "general" component to each product which these dump into, and the distribution list responsible for maintaining that queue has whoever's on duty go over it, with 7 different queues feeding different product/component combinations. I'll see about integrating these two features into Params() so it can be a cleaner implementation. Is it better to attach a unified diff to a bug report, or some alternate method of submission?

Seth: I'm pretty slow working on this, and am not quite sure how to work this into params -- heck, I'm still learning Perl. I'm assigning it to you -- let me know how I can help. What are the chances of integrating the command-line options specified in bug #36379?

I'm fine taking this. Life is a little busy until end of next week, but I'll make this happen after that.

Hmm, just though of something else to take into consideration with this... if someone uses a phony email address to submit a bug... an account gets issued to that phony address, the password email (and hence, the bug submission receipt) get bounced. They come back to the bugs address. A new account is issued to MAILER-DAEMON@somewhere.net and the bounce notice is filed as a bug report. The password email and receipt for this bug report get mailed back to MAILER- DAEMON@somewhere.net, which bounces, and you get the picture. That's the current situation with bounces as far as I can tell. Heck, there's potential for that now with the "sorry, you're not allowed to post here" email it currently generates. We're all damn lucky no one's run into someone mailing that address with a phony return yet. What a way to jam up your mailer with all those emails to MAILER-DAEMON@somewhere.net that say "sorry, you're not allowed to post here". :) So anyway, the reason I'm bringing this up here... bug_email.pl should make an attempt to screen out bounces. If the bounce can be determined to be from a "new password" email, then the associated account should be deleted, possibly even along with any bugs that were filed under it. With the exception of the bug that was submitted in creating the account, perhaps existing users should be required to include their bugzilla password in the email in order to submit or change bugs. This would help prevent someone from "spoofing" someone elses identity in posting a comment to a bug. Right now, whoever's name I stick on the From line in my email is who Bugzilla says it's from, and there's no authentication done. Including the password in an email isn't much less secure than submitting it via the webform, so the security of the password itself shouldn't be an issue.

CCing Dan Berlin, who from stuff I've seen around, I know is actually using the bug_email stuff. I'd appreciate any input or fixes you'd be willing to provide on these bugs :-)

We actually use a severely hacked up bug_email.pl (or will, since we haven't finished the conversion yet). I say "hacked up", because it has to parse incoming GNATS emails (gcc's that have send-pr included, etc), and transform them into bugzilla bugs. It's a bastardized merge of my gnats2bz.pl rewrite and bug_email.pl. That said, we do allow unregistered submissions from anyone (including phony addresses). The fact that it may come from a broken address doesn't necessarily make the reported bug bad. Any bounce messages from emailing them the username/password are ignored in two ways. 1. They wouldn't be valid GNATS input, and thus, the parser would error out on it, rather than insert a new bug with the bounce message. Of course, this will stop being a screen once we drop support for all versions that could send us bugs in gnats format, at which time i'll move us to a normal bug_email.pl 2. The password mails are sent from a non-existent address, (and even if they weren't, god knows i wouldn't have them send from the address of the bug parser. That's just asking for pain) so if something bounced, the bounce mail wouldn't be accepted. The mails state that they are coming from an invalid address, so only amazingly slow people, or computers, would send email back to that address.

*** Bug 222749 has been marked as a duplicate of this bug. ***

We have our own implementation of an email interface which would auto-create an account if one didn't already exist (only for emails from our domain). This caused us some administrative headaches when people would cc or assign a bug to an invalid username. That invalid username would then get an account generated, which we would then have to go clean up manually. We already solved the issue of bounces by simply having a set of known bad addresses that would simply result in an error message sent to the admin account, rather than creating a bounce. However, to clean up the issue of auto-creating accounts, we added a usermap feature, which is similar to an aliases file. It maps all of the available username in our company to the actual usernames. This allows us to now assign a bug to an alias like "Todd.Stansell" and it will automatically get mapped to "tjs". This also gives us a complete set of possible names that are allowed to be auto-created (this includes all of our internal mailing lists). I know this isn't useful for sites that allow logins from any domain, but for corporations that use Bugzilla strictly as an internal bug tracking interface, this is a useful feature. I just thought this might be a useful feature to keep in mind for the email interface (and actually, the way we implemented it, it's used by the web interface as well). Todd

Max, is that still something we would accept for email_in.pl? I'm personaly not a fan of anonymous inputs.

(In reply to comment #12) > Max, is that still something we would accept for email_in.pl? I'm personaly not > a fan of anonymous inputs. Yes, we might allow it, but it's not a very high priority item. We'd probably do it by creating a user called "email user" or something like that.