Last modified: 2011-07-24 11:41:00 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)
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.
Think this is fixed in r91668