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.

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:

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.

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 otrs-admins@lists.wikimedia.org

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.

In T74109#1956329, @Ata wrote:

OTRS is being localised on Transifex.
Am I right that it will be upgraded to 5.0 including translations present there on February 3rd?

Rescheduled for February 3 at 0800 UTC.

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.

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

I just thought a visualization may help. I do see that there was a great amount of activity overnight.

In T121030#1867607, @Rdicerb wrote:

Hmmm - @Moushira, I'm not in OTRS and don;t have a clear idea of the systems, thought I have worked in support ticket queues. Is there a batch answering tool in OTRS so that multiple issues can be responded to and closed at the same time? Thinking on how to scale it.

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?

In T94358#1808298, @pajz wrote:

Has been fixed in the latest OTRS 4 and OTRS 5 versions, according to the OTRS development team (see upstream report), hence depends on T74109.

In T118545#1804325, @Tgr wrote:

Ok, I realize that is not a technical problem by why on Earth do people go around and mark closed-successful tickets as spam? That means we are losing permissions for accepted images, which is very troublesome to put it mildly...

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.

And more specifically, I (and others) report slow logins and delays when loading certain queues.

Thanks, @Matthewrbowker.

@Qgil A new patch still needs to be created, likely for OTRS v 5 which is what we plan to upgrade to.

In T74109#1756437, @MartinK wrote:

Imho for volunteers like us the key benefit of OTRS Version 5 is the mobile ready user interface. Being able to Prozess some Tickets while commuting would realy increase our productivity.

Therefore: +1 for a direkt upgrade to OTRS5.

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.

Please also add otrs-listadmin@wikimedia.org as a list moderator but send the administrator password there as well. This is standard for all Official OTRS Wikimedia mailing lists.

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 <info-nl@wikimedia.org> (which is what is in the header of messages sent via that form) the info-nl queue.

In T101052#1357693, @cscott wrote:

This is probably a new issue caused by the RESTBase migration (T93292). cc'ing @GWicke.

Could you make this bug more concrete, please? Give me a specific uncomplicated page on a specific private wiki, and I can probably figure out what's going on.

In T101018#1329955, @Jgreen wrote:

I'm not sure I understand. Presently administrators can log in and view system logs but there's a limit on how far back they go, is it just that you want to extend how far back the viewable logs go?

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.

Any status update here? Has this been incorporated into the software by OTRS? (Meaning - once we upgrade ([T74109]) we should have these capabilities?)

In T95954#1205878, @Jalexander wrote:

In T95954#1205079, @csteipp wrote:

In the meantime, it sounds like the functionality OTRS wiki is looking for can be done with a (large and constantly updating..) set of whitelisted pages?

Patrick and other admins: Do you think this would be a good interim solution? (does it meet the goals for now?) Though a bit more cumbersome I and others can certainly help to keep the list up to date. I think the most important question is if the documentation pages would work still on otrs-wiki but public.

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.

In T88402#1065947, @Krenair wrote:

What would MediaWiki actually gain from creating a queue in OTRS?

In T56755#1051229, @Keegan wrote:

Let's do this at the Wikimania 2015 hackathon. I just need someone or two that knows Perl and is wiling to dig into OTRS's code.

In T88402#1014061, @Qgil wrote:

@Varnent, I see that this is not the first time you have this idea about MediaWiki and OTRS: https://meta.wikimedia.org/wiki/Talk:OTRS#MediaWiki_OTRS (January 2013) :)

Couldn't this be directly related to T87217: Make OTRS sessions IP-address-agnostic?

In T87217#989866, @Krenair wrote:

One of the OTRS admins, Operations team members, or maybe @csteipp, should set the priority on this. I get the impression that it's not Low.

I will concur with Krenair above - the number of such reports have dropped significantly since around the time the bug was filed.

In T78840#854518, @Krenair wrote:

I imagine this is WMF Analytics' area?

In T1180#847579, @Qgil wrote:

About offensive avatars, I wonder whether the Phabricator etiquette and the Friendly Space Policy could help.

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?

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.

Will be fixed with next upgrade (T74109)

In T76062#792953, @jeremyb-phone wrote:

talk to me first before releasing details about this or upstreaming.

reduced so far to 2014112810004236

A stable v4 has finally been released (Nov. 25).

In T899#792113, @yuvipanda wrote:

I'd like to think of tokens as barnstars, and hence useful :)