Page MenuHomePhabricator

Email notifications being sent out to users without email addresses and who aren't confirmed.
Closed, ResolvedPublic

Description

Author: sean

Description:
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)


Version: 1.13.x
Severity: normal

Details

Reference
bz17866

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:32 PM
bzimport added a project: MediaWiki-Email.
bzimport set Reference to bz17866.
bzimport added a subscriber: Unknown Object (MLST).

sean wrote:

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).

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.

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.

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.

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.