And the result seems fine!

You should have received an email, from domain revi.wiki, Subject: Testing testing one two three one two three.

Sorry for the delay, gone.

Note that the proposal specifically mentions "mimic Korean Wikipedia's Draft NS settings", so I copied kowiki's settings where not specirfied by kowikisource community consensus.

<korean speaker hat on> Consensus LGTM </korean speaker hat off>.

I guess relaying outbound only with WMF infra now and experimenting with inbound+outbound later would be better way (keeping status quo while making DMARC pass)…

In T378285#10270193, @revi wrote:

Option 1 seems… to have conflicting info: they say "no SMTP relay" but they have an EAP program which practically seems to be the… SMTP relay. I think it's up to you to figure out which is true (and what path to go).

In T380009#10335562, @Ruthven wrote:

Hi,
I've got the information that someone wrote to permissions-it@wikimedia.org on 15/11/2025-08-08 12:20 and got an "unreachable address" message.

In T380009#10332939, @eoghan wrote:

We had a quick chat with ITS today where they disabled the change that caused the routing to change, and it did cause gmail to start returning 550 for unknown addresses again, so we have confirmed their change was what caused this to start behaving differently.

In T380009#10328760, @Platonides wrote:

In T380009#10326074, @eoghan wrote:

So the issue is coming from the vrts_aliases.py cron job. Something has changed in how gmail is responding to emails here and claiming they're valid. I'm going to try see if we can change that to ignore the gmail check

OIT?

It seems like it's entire @wikimedia.org that is refusing to route to VRTS. My test email to oversight-ko-wp@wikimedia.org also bounced with P71054 (again, acl-otrs-admin + WMF-NDA).

I can definitely say it did not work that way yesterday: there was an incoming info-ko@wikimedia.org ticket at 2025-08-08T02:04:08Z.

Additionally, it appears to be routed via Google., which perhaps has never been correct.

(Adding SRE and infra-foundations based on tasks at Mail.)

Spam. User disabled.

At least I realized I did something wrong and closed the browser before everyone got removed, but looks like those with email A to somewhere in K got... nuked.

Just to be clear, using wikimediats.zendesk.com isn't a problem by itself; using wikimedia.org in From: header without proper/inadequate authorization (according to internet standards around anti-spam control) is the problem.

Updated description to state DKIM failures, too.

Possibly because "Gmail doesn't do SPF or DMARC checks on incoming messages from the IP addresses you specify in the setting."? support.google.com

Heh! Didn't notice that — I was just reading the subject and descriptions (lol).

Anyway I think possible solutions would be…

In T378285#10268269, @jhathaway wrote:

Thanks @revi, perhaps the From: header has changed since T272750,

revi archived this panel. Sat, May 4, 22:01

(For the record: I don't do PAWS for a sensitive rights such as delete.py — especially that I was a steward at that moment I preferred doing almost everything on my device — but yeah can't repro now)

I believe I've moved everything I want.

I treat revibot, -i, -ii all to be same stuff so merging into one. Gotta attempt fix asap.

I'll probably need to copy and upload the current tc-rc version, but seems like fixing T320006: Migrate revibot from Toolforge GridEngine to Toolforge Kubernetes is more pressing for me, so hold on for some moment.

(Sorry for the long delay in response)

My circumstances (at present) do not allow me to do much non-mobile work (there's a long story but I do not wish to be logged perpetually in phab logs) so if it needs to be shut down, so be it, and if someone has spare time to do that, that's also fine.

Yeah, [8701d83f-51e1-4140-967e-42ade58b0294] 2025-08-08 08:38:44: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" for trying to add oversight on testwiki. But since I can modify my rights for confirmed at metawiki, it seems it is about modifying cross-wiki user rights.

The problem with it is, as I said on the ML, when Wikimedia network is down, there is simply no way to send out the down notices, so it will be pretty useless for the purposes. So it has to be on other DC or hosted externally (ie. Some chapter).

(To be honest, I am very surprised that someone other than me was using the redirection, lol)

Was doing some cleanups for my now-defunct server (which was handling the redirect) and I forgot to do "publish" and went to bed.

See also T231937: Suppressing (or hiding) global accounts creates local blocks that can get out of sync.

Possibly related: T224341: Locked account can receive password reset email.

IIRC mostly because the lock+suppression does not propagate the hidden status by default, and S uses local gadget to propagate the suppression status. Gadget doesn't really care what happens after the lock, and it can't know if they are unlocked/un-hidden later.

Echoing Martin:

Week 5, year 2021 exists at ????:???/2021? ?5?.