Hi! I've been a Wikimedia contributor since 2007. While on Phab you'll usually find me working on OTRS related bugs in my capacity a Wikimedia OTRS administrator. In addition to that, I am an administrator on the English Wikipedia and am regularly available on IRC.
Jan 29 2017
These "non-working" email addresses are actually used for internal mail sorting within the system. While you may not be able to directly email these addresses, if they appear in CC fields of inbound mail they are routed to appropriate queues. These were strategically set up over time for this purpose.
Jul 6 2016
Just to confirm this issue, I am an administrator on the OTRS interface. Despite having access to the same queue, I get the same error as Josve05a. The OTRS system log shows the following:
Jun 3 2016
We do not use these customer notifications as there is no reason to. It only causes confusion on the customer end and provides them of no useful information.
May 21 2016
I have to assume this needs upstream? Can somebody more technically proficient look into that?
Alex (or his manager) can request access for an OTRS account by emailing us at email@example.com
Feb 5 2016
The salutation gap was fixed with the upgrade to v 5.0.6 (T74109: Upgrade OTRS to a more recent stable release). The ability to add manual line breaks was also added so I've fixed the signature gaps on all responses.
Feb 4 2016
Jan 22 2016
Jan 20 2016
Rescheduled for February 3 at 0800 UTC.
Jan 15 2016
I only closed it (and as invalid) as it was not a bug. I did not mean to imply it was not helpful, as I'm sure it was when you created the ticket - and perhaps now that we're discussing it again. ;-) If you feel there is benefit in it open, please do. I'm just cleaning up the OTRS board.
Fixed in most recent version, scheduled upgrade this month. see T74109
Per @akosiaris OTRS upgrade to version 5.0.x has been scheduled for 28 January 2016 and is expected to last 6-8 hours, beginning at 0800 UTC. Agents have been notified.
Increasing the row limit has been helpful enough.
I'm going to close this now as I think it served its purpose and that phab is not really the best venue to discuss, plan or execute recruitment - unless it has been done for other projects? I would encourage those in the tech community to spread word that help is needed with OTRS inquiries relating to mobile issues.
Dec 12 2015
Perhaps - I don't see it as a feasible alternative to OTRS, unfortunately. We can probably end that part of the discussion.
As Pajz stated above, this was due to user error in the to: field. OTRS is quite sensitive to such things. :-)
Dec 10 2015
I just thought a visualization may help. I do see that there was a great amount of activity overnight.
Dec 9 2015
Dec 8 2015
It would appear that the original message was routed to the probably-spam queue by the software due to the content of the email. When the probably-spam queue was being manually reviewed, as we do, this ticket was accidentally moved to the junk queue.
Can you please provide an example or two so we can look into it?
Nov 16 2015
Nov 13 2015
This ticket would have been received back in May of this year. This error indicates that the ticket number is invalid or no longer valid. Long story short, the ticket was deleted - probably by a volunteer mistakenly labeling it as spam.
Nov 10 2015
And more specifically, I (and others) report slow logins and delays when loading certain queues.
Oct 30 2015
Oct 29 2015
@Qgil A new patch still needs to be created, likely for OTRS v 5 which is what we plan to upgrade to.
Oct 27 2015
Oct 21 2015
After discussion with another admin, it would appear that this is an isolated incident whereby the sender set the accounts mailing list to the reply-to field. They chose to do this, and we've not encountered any other such issues in the past so we do not anticipate many, if any other in the future.
The ticket had the accounts mailing list in its reply-to address (as noted in the plan-text email header). Why is that the case, I don't know. Looking in to it. However, in the future - please contact the OTRS admins before creating phabricator tasks. Not to mention some potentially sensitive issues that could be inadvertently released in a new task here, there are usually ways teh OTRS admins can rectify issues on our end, without the needs for WMF ops.
Sep 24 2015
Please also add firstname.lastname@example.org as a list moderator but send the administrator password there as well. This is standard for all Official OTRS Wikimedia mailing lists.
Jun 22 2015
Unless there's something within MediaWiki to do, I've made an adjustment within OTRS which should correct this issue. I've created a filter which should divert any mail sent to WikiAdmin~nlwiki <email@example.com> (which is what is in the header of messages sent via that form) the info-nl queue.
Jun 11 2015
Jun 2 2015
Jun 1 2015
May 28 2015
What are we going to do about email address-based password reset?
I think we should take blocked users off the list of users who email matches the reset request. If no unblocked accounts are still in the list, then the resetting user gets the standard response that no user accounts have that email.
I don't think we actually provide such an error? When I try resetting for completely nonsense email addresses (e.g. DoesNotActuallyExist@wikimedia.org), it pretends that it's sent an email.
May 27 2015
May 10 2015
May 8 2015
Any status update here? Has this been incorporated into the software by OTRS? (Meaning - once we upgrade ([T74109]) we should have these capabilities?)
Apr 17 2015
Apr 14 2015
Apr 12 2015
Apr 5 2015
So - the general feeling I'm getting from the above is that at the moment, most would like to continue using the existing methods of communication for correspondence of any sort regarding the MediaWiki software.
Feb 25 2015
Feb 21 2015
Feb 19 2015
Feb 10 2015
Feb 4 2015
Jan 31 2015
Couldn't this be directly related to T87217: Make OTRS sessions IP-address-agnostic?
Jan 22 2015
Dec 23 2014
I will concur with Krenair above - the number of such reports have dropped significantly since around the time the bug was filed.
Dec 17 2014
Dec 15 2014
Dec 7 2014
I think this is a useful ability, especially with regards to transclusions. If the box is removed, people won't know it exists. It may not look the best, but perhaps that can be looked at rather than simply removing it all together?
Dec 3 2014
Just an FYI - 4.0.2 came out today; along with the announcement that versions prior to 3.3 (including 3.2.14, which is what we're using at the moment) will no longer be supported.
Nov 30 2014
Nov 29 2014
Will be fixed with next upgrade (T74109)
Nov 28 2014
A stable v4 has finally been released (Nov. 25).