Open
Bug 36341
Opened 25 years ago
Updated 3 years ago
Allow unregistered submissions through email
Categories
(Bugzilla :: Incoming Email, enhancement, P4)
Bugzilla
Incoming Email
Tracking
()
NEW
People
(Reporter: barnboy, Unassigned)
References
Details
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);
< }
< }
<
Comment 1•25 years ago
|
||
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.
Comment 2•25 years ago
|
||
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?
Comment 3•25 years ago
|
||
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.
Reporter | ||
Comment 4•25 years ago
|
||
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?
Blocks: 36379
Reporter | ||
Comment 5•25 years ago
|
||
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?
Assignee: tara → seth
Comment 6•25 years ago
|
||
I'm fine taking this. Life is a little busy until end of next week, but I'll
make this happen after that.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 7•24 years ago
|
||
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.
Updated•24 years ago
|
Target Milestone: --- → Future
Updated•23 years ago
|
Severity: trivial → enhancement
Updated•23 years ago
|
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
Updated•22 years ago
|
Whiteboard: bug_email
Updated•22 years ago
|
Blocks: bz-email-in
Comment 8•22 years ago
|
||
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 :-)
Comment 9•22 years ago
|
||
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.
Comment 10•21 years ago
|
||
*** Bug 222749 has been marked as a duplicate of this bug. ***
Summary: bug_email.pl cannot accept unregistered submissions → allow unregistered submissions through email (bug_email.pl)
Comment 11•20 years ago
|
||
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
Updated•19 years ago
|
No longer blocks: bz-email-in
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•18 years ago
|
Target Milestone: Future → ---
Comment 12•17 years ago
|
||
Max, is that still something we would accept for email_in.pl? I'm personaly not a fan of anonymous inputs.
Comment 13•17 years ago
|
||
(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.
Assignee: seth → incoming.email
Status: ASSIGNED → NEW
Component: Bugzilla-General → Incoming Email
OS: Solaris → All
Priority: P3 → P4
Hardware: Sun → All
Summary: allow unregistered submissions through email (bug_email.pl) → Allow unregistered submissions through email
Whiteboard: bug_email
You need to log in
before you can comment on or make changes to this bug.
Description
•