I just tried security@wikipedia.org and it does not appear that email forwards to security@wikimedia.org so we should do that too.

In T182812#3835360, @Bawolff wrote:

I just tried security@wikipedia.org and it does not appear that email forwards to security@wikimedia.org so we should do that too.

Nevermind, gmail just didn't display it because it detected the email came from my account, so i got confused

The exim alias file for wikipedia.org (in private repo) _does_ have this line though:

21 security:   security@wikimedia.org

Does it really not work?

gotcha @Bawolff! i wrote that before i saw your reply.

regarding the wmflabs.org address, there is

security@wmflabs.org

It also forwards to security@wikimedia.org

The MX for tools.wmflabs.org is not the same as for wmflabs.org though.

That's handled by mail.tools.wmflabs.org and that must be configured somewhere else (by cloud people).

tools.wmflabs.org isn't a relay that is in production, so it is not (and cannot be) a "trusted" relay. This means that e.g. Gmail will consider all aliased spam to originate from tools.wmflabs.org, which would affect its reputation and possibly mark those emails as spam. Aliasing between different administrative domains has dangers and should be avoided -- I think it'd be preferrable to just communicate that security@wikimedia.org is the canonical place to report security issues.

According to https://wikitech.wikimedia.org/wiki/Help:Toolforge#Email if a user were to sign up with the username "security", then mail to security@tools.wmflabs.org would reach them. I don't see that username blocked via https://wikitech.wikimedia.org/wiki/MediaWiki:Titleblacklist

Easiest would probably have someone register that account and set the email address to security@wikimedia.org

I created https://tools.wmflabs.org/admin/tool/security and added some folks to the maintainer list. I think a ~/.forward can be added there bounce emails around as needed. By default it should email to the maintainers list.

In T182812#3835599, @bd808 wrote:

I created https://tools.wmflabs.org/admin/tool/security and added some folks to the maintainer list. I think a ~/.forward can be added there bounce emails around as needed. By default it should email to the maintainers list.

I thought tool email addresses were like tools.security@tools.wmflabs.org ? Doesn't it need to be an actual shell user with the name security?

In T182812#3835642, @Legoktm wrote:

I thought tool email addresses were like tools.security@tools.wmflabs.org ? Doesn't it need to be an actual shell user with the name security?

Hmmm... that may be true. Something like security.maintainers@tools.wmflabs.org would work, but I'm not sure if just security@tools.wmflabs.org does or not.

Our exim magic is not something that I have read through carefully. I think that there is a fall through so that uid=security would win if it existed, but that the rules then fall back to looking for uid=tools.security next via the tool_forward_specific and tool_forward_general processing in mail-relay.exim4.conf.erb

In T182812#3835642, @Legoktm wrote:

I thought tool email addresses were like tools.security@tools.wmflabs.org ? Doesn't it need to be an actual shell user with the name security?

Hmmm... that may be true. Something like security.maintainers@tools.wmflabs.org would work, but I'm not entirely sure if just security@tools.wmflabs.org does or not.

Our exim magic is not something that I have read through carefully. I think that there is a fall through so that uid=security would win if it existed, but that the rules then fall back to looking for uid=tools.security next via the tool_forward_specific and tool_forward_general processing in mail-relay.exim4.conf.erb

From: legoktm@
To: security@tools.wmflabs.org
Subject: Test - T182812

Please comment on https://phabricator.wikimedia.org/T182812 if this
email was successfully received.

Let's see if it worked :)

I already got emails to that address...

Please comment on https://phabricator.wikimedia.org/T182812 if this email was successfully received.

I think I was already getting mail for this address though so nothing may have changed.

Received: from mx1001.wikimedia.org (mx1001.wikimedia.org. [208.80.154.76]) by mx.google.com with ESMTPS id r125si2426005qkb.269.2017.12.13.16.51.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 16:51:10 -0800 (PST)
Received: from [10.68.16.27] (port=49957 helo=mail.tools.wmflabs.org) by mx1001.wikimedia.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from <legoktm@member.fsf.org>) id 1ePHjx-0001RP-DF; Thu, 14 Dec 2017 00:51:09 +0000
Received: from mx1.riseup.net ([198.252.153.129]) by mail.tools.wmflabs.org with esmtp (Exim 4.82) (envelope-from <legoktm@member.fsf.org>) id 1ePHjv-00020g-HT for security@tools.wmflabs.org; Thu, 14 Dec 2017 00:51:07 +0000

I wonder if we have an alias that routes this to the same group as tools.admin/root mails?

You can use exim4 -bt foo@example.org to test how/where exim4 would deliver a specific address (if at all).

Also, note that even with direct aliasing to specific people, what I stated above for domain/MX reputation still holds true -- Gmail won't have mail.tools.wmflabs.org in its trusted relay list, and would thus consider all of the emails passing through (including all spam) to be originated by tools.wmflabs.org.

$ exim4 -bt security@tools.wmflabs.org
...
bdavis@wikimedia.org
    <-- admin.maintainers@tools.wmflabs.org
    <-- tools.admin@tools.wmflabs.org
    <-- root@tools.wmflabs.org
    <-- security@tools.wmflabs.org
  router = dnslookup, transport = remote_smtp
  host mx1001.wikimedia.org [2620:0:861:3:208:80:154:76] MX=10
  host mx1001.wikimedia.org [208.80.154.76]              MX=10
  host mx2001.wikimedia.org [2620:0:860:2:208:80:153:45] MX=50
  host mx2001.wikimedia.org [208.80.153.45]              MX=50
...

So... security@ is aliased to root@ which is in turn aliased to tools.admin@. This is all done in /etc/aliases on tools-mail.tools.eqiad.wmflabs and seems not to be puppetized.

$ exim4 -bt sal@tools.wmflabs.org
sal@tools.wmflabs.org is undeliverable
$ exim4 -bt sal.foo@tools.wmflabs.org
bdavis@wikimedia.org
    <-- sal.foo@tools.wmflabs.org
  router = dnslookup, transport = remote_smtp
  host mx1001.wikimedia.org [2620:0:861:3:208:80:154:76] MX=10
  host mx1001.wikimedia.org [208.80.154.76]              MX=10
  host mx2001.wikimedia.org [2620:0:860:2:208:80:153:45] MX=50
  host mx2001.wikimedia.org [208.80.153.45]              MX=50
...
$ exim4 -bt bd808@tools.wmflabs.org
bdavis@wikimedia.org
    <-- bd808@tools.wmflabs.org
  router = dnslookup, transport = remote_smtp
  host mx1001.wikimedia.org [2620:0:861:3:208:80:154:76] MX=10
  host mx1001.wikimedia.org [208.80.154.76]              MX=10
  host mx2001.wikimedia.org [2620:0:860:2:208:80:153:45] MX=50
  host mx2001.wikimedia.org [208.80.153.45]              MX=50

If there was no global alias, @Legoktm is correct that an LDAP user with uid=security would get the messages. Using a bare tool name is undeliverable, but <toolname>\..* is delivered to the tool maintainers by default and customizable via a ~/.forward.<tail> in the tool's homedir.

The /etc/aliases file not being in Puppet is annoying, but unsurprising. The Toolforge mail host was known to us to be a snowflake. We manually upgraded it from Precise to Trusty in the last round of OS migrations because we did not have time to properly ensure that we could build a replacement from scratch.

• T96884: Document email setup
• T96967: Make tools-mail redundant

Whatever happened to this? Still alive as an issue?

Change 456280 had a related patch set uploaded (by BryanDavis; owner: Bryan Davis):
[operations/puppet@production] toolforge: Forward security@tools.wmflabs.org to security@wikimedia.org

https://gerrit.wikimedia.org/r/456280

In T182812#3835406, @faidon wrote:

tools.wmflabs.org isn't a relay that is in production, so it is not (and cannot be) a "trusted" relay. This means that e.g. Gmail will consider all aliased spam to originate from tools.wmflabs.org, which would affect its reputation and possibly mark those emails as spam. Aliasing between different administrative domains has dangers and should be avoided -- I think it'd be preferrable to just communicate that security@wikimedia.org is the canonical place to report security issues.

If I understand this comment, @faidon is saying that the patch I just proposed at https://gerrit.wikimedia.org/r/456280 is a bad idea. If so I'll abandon it.

To add some context to the current situation -- most of the email sent to security@tools.wmflabs.org is:

• from openbugbounty.org
• about a volunteer maintained tool hosted on tools.wmflabs.org

I believe OBB just sends emails to a bunch of default email addresses (security@, admin@, webmaster@, abuse@), so those emails would never reach security@wikimedia.org without forwarding. Currently this generally results in a phabricator ticket being opened by one of the recipients (although I don't think we have a process for who does that, so it is quite possible that reports slip through the cracks)

One thing that I'm unsure of is whether emails about security issues in volunteer-maintained tools should end up at security@wikimedia.org or not.

I'm not familair with openbugbounty.org, but looking at their website, it seems like they do allow you to register different domains and recipient email addresses etc. Wouldn't that work for this purpose?

Also, if these are for volunteer-maintained tools hosted on tools.wmflabs.org, would an alias to security@wikimedia.org be the right destination anyway? It sounds to me like this may need separate recipients than production's security@.

In any case, as far as production goes, I don't object in creating such an alias. My main worry is Toolforge-related, and specifically that tools.wmflabs.org will inadvertently forward a lot of spam to @wikimedia.org/Gmail, especially given security@ is a common spam target, and that it will affect the email reputation for the whole tools.wmflabs.org domain. This would affect both this alias and every other email originating by this mailserver, which may be marked as spam or rejected altogether. It may or may not happen, and it may happen at any random point in time (depending on the volume of spam, and Gmail's algorithm, both unknown quantities). If it does, it will be a hard problem to fix -- email reputation issues usually are. It's a risk that already exists somewhat, but would be amplified by this; in general it's a risk that the Toolfoge team should weight against the benefits and other alternatives and make a decision on. (There are also smaller production risks as well, such as the address space or the ASN getting a bad reputation, but I doubt it'll come to that. Preferrably this would happen after Toolforge moves to its new address space.)

More broadly: cross-domain aliasing is considered a bad practice, and is increasingly discouraged and/or blocked across the industry (e.g. DMARC), and can result in backscatter due to the email system's store-and-forward approach. Production wouldn't block such flows right now, but it may in the future. I wouldn't recommend doing this kind of aliasing in general, but it's ultimately Toolforge admins' decision :)

Change 456280 abandoned by BryanDavis:
toolforge: Forward security@tools.wmflabs.org to security@wikimedia.org

Reason:
https://phabricator.wikimedia.org/T182812#4543622

https://gerrit.wikimedia.org/r/456280

We could have security@tools.wmflabs.org go to the Toolforge admins (I think by including tools.admin in the security tool), which is a larger/growing group now, and leave it to their discretion on whether to forward it onwards to the full security@wikimedia or move it into Phabricator, etc.?

We could have security@tools.wmflabs.org go to the Toolforge admins

+1

In T182812#4840433, @chasemp wrote:

We could have security@tools.wmflabs.org go to the Toolforge admins

+1

That is the current configuration:

In T182812#3836326, @bd808 wrote:

tools-mail.tools:/etc/exim4
bd808$ grep security /etc/aliases
security: root

Double checked:

$ ssh tools-mail-02.tools.eqiad.wmflabs
$ grep security: /etc/aliases
security: root
$ grep root: /etc/aliases
root: tools.admin

Sounds like we can close this then as either 'resolved' or technically 'rejected' i guess.