Some tickets in stewards otrs queue (e.g. 2019090610003434) apparently come from addresses from a @mw[number].eqiad.wmnet domain
Description
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Validate user inputted email address | mediawiki/extensions/ContactPage | master | +8 -1 |
Related Objects
Event Timeline
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) "wiki@wikimedia.org" string(36) "no-reply-notifications@wikipedia.org" string(36) "no-reply-notifications@wikipedia.org"
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.
@Vituzzu: If this is still a problem, could you please provide an example email address in a non-public Phabricator Paste? Thanks.
I went through a series of examples and I think the reason is pretty odd: this happens when an invalid address is put in "your email address" field in special:contact
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
Change 656525 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/extensions/ContactPage@master] Validate user inputted email address
Change 656525 merged by jenkins-bot:
[mediawiki/extensions/ContactPage@master] Validate user inputted email address
Patch merged, taavi asked if this was a problem more than a year ago and no one raised anything. Closing as resolved, but re-open if there's still something to do here