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 -----
(reason: 550 5.1.1 User unknown)
----- Transcript of session follows -----
550 5.1.1 RedactedUsername <>... User unknown
Final-Recipient: RFC822; @pedlfaster.pedlr.com
Diagnostic-Code: SMTP; 550 5.1.1 User unknown
Last-Attempt-Date: Sun, 8 Mar 2009 14:57:33 -0400
---------- Forwarded message ----------
From: WikiAdmin <email@example.com>
Date: Sun, 8 Mar 2009 14:57:33 -0400
Subject: LyricWiki page User talk:RedactedUsername has been created by SomeOtherUser
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:
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_password: [redacted for privacy]
user_token: dcacc[some hex chars redacted here]66b7a573c
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