Pleasure. ;-)

Steps to reproduce: I can't tell you, since this is an incoming email. I have included possibly all the information required to look it up (except the specific timestamp, 2018-10-18 19:49:57 CET) in the mailserver logs, but obviously I do not have any further information on a mail I neither originated nor received. :-) It's from wikipedia, and judging by the sender it may have been generated from something on huwiki, so my educated guess was email-to-a-registered-user-from-the-website.

Sent from Wikipedia may possibly mean pressing the "email to this user" link when looking at a userpage.

My inspection was looking at the mailserver logs of the local mailserver, and quoting it back to you.

Your steps to see the same? Well, first, you have to break into my mailserver.... :-) Jokes aside, possibly turn on sender callout verification on any mailserver (if it's exim, I can't tell you about others) and try to send a message (email) to that server from the wikipedia web UI. But may be tad easier to go to mx1001 and grep the logs for the unique-looking sender string.

Steps to reproduce: I can't tell you, since this is an incoming email.

In that case, less passive voice would be helpful for more clarity. For example I have no idea who did regarding "Upon inspection this has been observed" and such.

Sorry for being unclear, it wasn't intentional. There was a report of missing mail sent from Wikipedia (wikipedia posted a notice to the user that an email has been sent and the email never have been arrived) and I started inspecting mailserver logs for unusual traffic from anything wikipedia related around the same timeframe.
If anyone really want to do anything about it I can spend time and testing on it [basically sending mail myself and correlate with logs], but not before, since unfortunately my time is a scarce resource.

It is still not fixed, but I have a recent sample.

User:SQL sent me an email through enwp. I have got the notification from MediaWiki successfully:

2019-08-06 17:35:02 1hv1UI-00FwiI-3k <= wiki-enwiki-7r7-pvtna1-JbvUAv8+HzPFWKwQ@wikimedia.org H=wiki-mail-eqiad.wikimedia.org [2620:0:861:3:208:80:154:91] P=esmtps X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=no S=2671 M8S=0 DKIM=wikimedia.org id=enwiki.5d499e192ee2a9.58525783@en.wikipedia.org 
2019-08-06 17:35:03 1hv1UI-00FwiI-3k => grin (grin@*.hu) <grin@*.hu> F=<wiki-enwiki-7r7-pvtna1-JbvUAv8+HzPFWKwQ@wikimedia.org> P=<wiki-enwiki-7r7-pvtna1-JbvUAv8+HzPFWKwQ@wikimedia.org> R=db_local T=db_home S=2813 QT=5s DT=0s

But not the email itself:

2019-08-06 17:34:34 H=wiki-mail-eqiad.wikimedia.org [2620:0:861:3:208:80:154:91] sender verify fail for <wiki-enwiki-7r7-pvtn9a-YeDiem/fyN6r5B/W@wikimedia.org>: mx1001.wikimedia.org [2620:0:861:3:208:80:154:76] : SMTP error from remote mail server after RCPT TO:<wiki-enwiki-7r7-pvtn9a-YeDiem/fyN6r5B/W@wikimedia.org>: 550 Administrative prohibition

Which shows that wiki-enwiki-7r7-pvtna1-JbvUAv8+HzPFWKwQ@wikimedia.org was accepted just fine while wiki-enwiki-7r7-pvtn9a-YeDiem/fyN6r5B/W@wikimedia.org results a perm error 550 Administrative prohibition, specifically by mx1001.wikimedia.org.

To me that looks like the email was rejected by the final destination server. Do you know which software is used on your mail server? Exim?

You are wrong, it was rejected by, as I have mentioned several times, by mx1001.wikimedia.org [2620:0:861:3:208:80:154:76]. What you are seeing is the rejection based on the rejection of mx1001. The important part is:

• mx1001.wikimedia.org [2620:0:861:3:208:80:154:76] : SMTP error from remote mail server after RCPT TO:<wiki-enwiki-7r7-pvtn9a-YeDiem/fyN6r5B/W@wikimedia.org>: 550 Administrative prohibition

Which means, mx1001 got RCPT TO:<wiki-enwiki-7r7-pvtn9a-YeDiem/fyN6r5B/W@wikimedia.org> and answered by 550 Administrative prohibition. (Yes, it's got EHLO and MAIL FROM too.)

Believe me, I am in close proximity with mail servers and SMTP for the last few decades. If you really feel the need to get all the tech details I can provide you, but it will not help the problem at all; instead of looking at the log of mx1001 and see what have triggered the 550, or how actually the recipient handling looks up the machine-generated reply address, and why the first one the gives 220 and the other 550.

In the meantime I try to find it in the puppet repo, but I'd appreciate a pointer if you'd find it faster.

Hmm, the problem is possibly here:

mwverpbounceprocessor:
		driver = pipe
		command = /usr/bin/curl -H 'Host: <%= @verp_post_connect_server %>' <%= @verp_bounce_post_url %> -d "action=bouncehandler" --data-urlencode "email@-" -o /dev/null

but I am not yet familiar with this API.