399010 - email_in mails "not a valid user" error notifications to spammers with invalid email addresses

Status: NEW

(Bugzilla :: Incoming Email, defect)

Description

[fedor ezeev]

User-Agent:       Opera/9.23 (Windows NT 5.0; U; en)
Build Identifier: 3.02

Bugzilla should have option "NOT email error notification to invalid users"

Reproducible: Always

Steps to Reproduce:
1. Spammer send to bugzilla an email
Actual Results:  
Bugzilla sends him a reply.

Expected Results:  
Bugzilla should have option "NOT email error notification to invalid users". And if this option is enabled - bugzilla should not send such kind of emails.

I've got a VERY big /var/spool/mqueue, all filled with nondelivered replies of this kind.

Comment 1

[Max Kanat-Alexander]

You can just disable email to them using editusers.cgi.

Comment 2

[Max Kanat-Alexander]

Oh wait, I see what you mean. You want email_in to not send an error to somebody if they're not a valid user. Or at least, an option to do that.

Okay, we should express this as a problem instead: Bugzilla responds to spammers with invalid email addresses and tells them they're not a valid user.

Comment 3

[fedor ezeev]

By the way. Bugzilla must check a validity of user BEFORE any other checks and even before any other mail parsing.
Otherwise, Bugzilla will be send an errors message, like in Bug 399004, to spammers too.

Comment 4

[fedor ezeev]

Attachment: my own solution for this bug

This is a hacky patch. There is no new option in Bugzilla, just exit if user is invalid.

Comment 5

[Frédéric Buclin]

Fedor, you mean the error is thrown when parsing the email, right? Because if the user is invalid, then email_in.pl already won't call post_bug.cgi/process_bug.cgi.

If that's what you are talking about, I think your fix is correct. But in this case, we should remove the check at the end of the script as you won't be able to alter the reporter field when bug 419188 will be fixed.

Comment 6

[Max Kanat-Alexander]

If we implement this, we also need to implement confirmation for successful changes or newly-filed bugs, or people could not realize that their change never happened. The confirmations should be a user preference. (And should be done in a separate bug, one I think is already filed.)

Comment 7

[Frédéric Buclin]

(In reply to comment #6)
> If we implement this, we also need to implement confirmation for successful
> changes or newly-filed bugs, or people could not realize that their change
> never happened.

Yes, I agree. This would be good to have. When I entered wrong labels on landfill, and saw no changes, I first thought Gmail was slow at sending my email.


 The confirmations should be a user preference. (And should be
> done in a separate bug, one I think is already filed.)

A user pref is indeed useful as some users may already get normal bugmail for changes they did, and wouldn't want to get another notification. But I cannot find the bug you are talking about. Maybe not filed yet.

Comment 8

[fedor ezeev]

(In reply to comment #5)
> Fedor, you mean the error is thrown when parsing the email, right?
If my memory doesn't lies to me - no. Error on parsing the email is described in Bug 399004

> Because if the user is invalid, then email_in.pl already won't call
> post_bug.cgi/process_bug.cgi.
Yeah, becourse it breaks on this line:
my $user = Bugzilla::User->new({ name => $username })
    || ThrowUserError('invalid_username', { name => $username });

And this line sends an "invalid username" error report to spammer. Spammer is happy :)

I think, that in some cases an "invalid username" error report may be useful. For example, internal Bugzilla's installation in some huge organisations. There is no worldwide emails, but there is invalid usernames (new employee).

So, I think, that Bugzilla should have a system option for this.

> But in this case, we should remove the check at the end of the script as you > won't be able to alter the reporter field when bug 419188 will be fixed.
Unfortunately, I'm not authorized to access this bug.

Comment 9

[fedor ezeev]

(In reply to comment #7)
> But I cannot find the bug you are talking about. Maybe not filed yet.
Done. Bug 422345

Comment 10

[Frédéric Buclin]

The Bugzilla 3.0 branch is now locked to security bugs and dataloss fixes only. This bug doesn't fit into one of these two categories and is retargetted to 3.2 as part of a mass-change. To catch bugmails related to this mass-change, use lts081207 in your email client filter.

Comment 11

[Frédéric Buclin]

Bugzilla 3.2 is restricted to security bugs only. Moreover, this bug is either assigned to nobody or got no traction for several months now. Rather than retargetting it at each new release, I'm clearing the target milestone and the bug will be retargetted to some sensible release when someone starts fixing this bug for real (Bugzilla 3.8 more likely).