Some tickets in stewards otrs queue (e.g. 2019090610003434) apparently come from addresses from a @mw[number].eqiad.wmnet domain
I presume it's from apache@mw[number].eqiad.wmnet?
As that sounds like it's taking the default for $wgPasswordSender as per the docs...
/** * Sender email address for e-mail notifications. * * The address we use as sender when a user requests a password reminder, * as well as other e-mail notifications. * * Defaults to "apache@$wgServerName" (in Setup.php). */ $wgPasswordSender = false;
But it shouldn't be...
> var_dump( $wgPasswordSender, $wmgNotificationSender, $wgNotificationSender ); string(18) "email@example.com" string(36) "firstname.lastname@example.org" string(36) "email@example.com"
Any idea when this started?
It's a different string. Namely in this case is a wrongly encoded Cyrillic string. This ticket contains users' IP (similarly previous ones) so I'm not inclined to move it in a queue you can access. Instead we can apply a security policy and I'll paste it here.
@Vituzzu The easiest way would be to create a private paste (https://phabricator.wikimedia.org/paste/edit/form/45/) and add @Reedy or Security-Team as the subscribers.
Although at this stage, I think reedy just wants the email addresses that they are coming from and not the full email entry in OTRS.
Thanks for the testing/narrowing.
I imagine it's probably not as odd as you might think. I'm guessing, when it gets into the pear MAIL code... if the address is invalid it falls back to the hostname in some form or another.
The fix would presumably be running the value from "Your email address:" through something like Sanitizer::validateEmail() and throw an error if it's not valid
email validation is hard, as per the docs for the function
* Note that this validation doesn't 100% match RFC 2822, but is believed * to be liberal enough for wide use. Some invalid addresses will still * pass validation here.
It's probably good enough for our purposes