Last modified: 2011-07-24 11:41:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 17866 - Email notifications being sent out to users without email addresses and who aren't confirmed.
Email notifications being sent out to users without email addresses and who a...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Email (Other open bugs)
1.13.x
All All
: Low normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 1932
  Show dependency treegraph
 
Reported: 2009-03-08 21:39 UTC by Sean Colombo
Modified: 2011-07-24 11:41 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sean Colombo 2009-03-08 21:39:18 UTC
I've been seeing numerous emails bounce back that didn't have an email address in the "to" field of the message.  Further inspection shows that the example user I chose has neither has an email address set up, nor do they have a stale field saying that they had confirmed their email address previously.

Most of these bounce-backs in the past few days have been notifications to new users about "Welcome" messages on their talk pages.


Example for a user created today who bounced an email back:
(The username isn't actually 'RedactedUsername', but that's been substituted in the data)


Bounced back email:
  ----- The following addresses had permanent fatal errors -----
RedactedUsername <>
   (reason: 550 5.1.1 User unknown)

  ----- Transcript of session follows -----
550 5.1.1 RedactedUsername <>... User unknown

Final-Recipient: RFC822; @pedlfaster.pedlr.com
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 5.1.1 User unknown
Last-Attempt-Date: Sun, 8 Mar 2009 14:57:33 -0400


---------- Forwarded message ----------
From: WikiAdmin <webmaster@lyricwiki.org>
To: RedactedUsername<>
Date: Sun, 8 Mar 2009 14:57:33 -0400
Subject: LyricWiki page User talk:RedactedUsername has been created by SomeOtherUser
Dear RedactedUsername,


The LyricWiki page User talk:RedactedUsername has been created on
12:57, 8 March 2009 by SomeOtherUser, see
http://lyricwiki.org/User_talk:RedactedUsername for the current version.

This is a new page.

Editor's summary: Welcome, RedactedUsername!

Contact the editor:
mail: http://lyricwiki.org/Special:EmailUser/SomeOtherUser
wiki: http://lyricwiki.org/User:SomeOtherUser

There will be no other notifications in case of further changes unless
you visit this page.
You could also reset the notification flags for all your watched pages
on your watchlist.

            Your friendly LyricWiki notification system





And the info in the database:
mysql> select * from wiki_user where user_name='RedactedUsername' \G;
*************************** 1. row ***************************
                 user_id: [redacted]
               user_name: RedactedUsername
          user_real_name: 
           user_password: [redacted for privacy]
        user_newpassword: 
              user_email: 
            user_options: quickbar=1
underline=2
cols=80
rows=25
searchlimit=20
contextlines=5
contextchars=50
disablesuggest=0
ajaxsearch=0
skin=
math=1
usenewrc=0
rcdays=7
rclimit=50
wllimit=250
hideminor=0
highlightbroken=1
stubthreshold=0
previewontop=1
previewonfirst=0
editsection=1
editsectiononrightclick=0
editondblclick=0
editwidth=0
showtoc=1
showtoolbar=1
minordefault=0
date=default
imagesize=2
thumbsize=2
rememberpassword=1
enotifwatchlistpages=0
enotifusertalkpages=1
enotifminoredits=0
enotifrevealaddr=0
shownumberswatching=1
fancysig=0
externaleditor=0
externaldiff=0
showjumplinks=1
numberheadings=0
uselivepreview=0
watchlistdays=3
extendwatchlist=0
watchlisthideminor=0
watchlisthidebots=0
watchlisthideown=0
watchcreations=0
watchdefault=0
watchmoves=0
watchdeletion=0
variant=en
language=en
searchNs0=1
            user_touched: 20090308185738
              user_token: dcacc[some hex chars redacted here]66b7a573c
user_email_authenticated: NULL
        user_email_token: 
user_email_token_expires: NULL
       user_registration: 20090308163239
       user_newpass_time: NULL
          user_editcount: 3
1 row in set (0.00 sec)
Comment 1 Sean Colombo 2009-03-08 21:47:59 UTC
After looking at trunk, there is a call to $targetUser->isEmailConfirmed() inside of UserMailer::actuallyNotifyOnPageChange() which should fix this.

The version that produced this error was 1.13.2 (adding to ticket).
Comment 2 Philippe Verdy 2009-10-12 03:32:47 UTC
See also my comment in critical bug 19161 (related to automatic account creation). There are privacy concerns, and something to implement to apply the privacy user preferences globally on all wiki sites just visited by a user with a validated SUL account (because now wa can have hundreds of accounts on wikis that we have just visited without thinking about setting our own preferences.

Note that with SUL, not only the privacy parameters should be propagated, but most probably the user's locale parameters too (the prefered language, user's prefered time format, and user's local timezone). Propagating the site presenation parameters (as as the skin name if something else than Monobook, or user's signature) is much less essential.
Comment 3 Philippe Verdy 2009-10-12 03:35:28 UTC
This bug, anyway, should not have the status "normal" but should be CRITICAL ! Sending ANY emails (except the small email validation request) to non validated addresses is considered as spamming, and this can be the cause of Wikimedia sites to be considered as a source of spams.
Comment 4 Bawolff (Brian Wolff) 2010-11-13 06:36:33 UTC
>After looking at trunk, there is a call to $targetUser->isEmailConfirmed()
>inside of UserMailer::actuallyNotifyOnPageChange() which should fix this.

Hmm, well that is true, this just happened to me on trunk (on translatewiki) so I don't think thats actually the case. It's ironic how in this situation emails are sent to the user, but the user is not allowed to disable the emails until their email is confirmed.
Comment 5 John Mark Vandenberg 2011-05-31 13:40:09 UTC
I think this bug is about enotif messages somehow being *sent* without a to: field.
If so, it isnt SPAM as the local mail server will reject these emails.  If a lot of these emails are being sent out, the net-admins will want a resolution, and it may be critical.
Comment 6 Mark A. Hershberger 2011-07-07 19:13:02 UTC
Think this is fixed in r91668

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


Navigation
Links