Current wmflabs.org TXT is v=spf1 mx ?all, with MX records pointing at the prod MXes - I doubt those prod MXes can handle inbound mail for labs right now so I wonder why they're there.
we should probably fix that

In T208281#4704984, @Krenair wrote:

I doubt those prod MXes can handle inbound mail for labs right now so I wonder why they're there.

although this happened and I have no idea why: https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/293057/ - do you remember @faidon?

Yes, this was because of T137160. wmflabs.org inbound emails are being handled by prod MXes right now, with only a handful of aliases being defined.

Thanks, had forgotten about that. So I guess we'd need to make mx-in servers too...

Not necessarily! For what we're currently doing -just aliasing a handful of aliases to a few people- I think it's fine as it is (but if the cloud admin team wants that separate for some reason, that's their call of course). We're not crossing any prod/WMCS barriers as it is, so I don't consider this a security issue.

If at some point in the future we want to do smarter things like dynamic lookups to OpenStack APIs or LDAP to route inbound emails to WMCS project owners or stuff like that (similar to what tools.wmflabs.org's MX does right now) then it would probably be a good idea to split it up to its own thing.

In T208281#4706016, @faidon wrote:

We're not crossing any prod/WMCS barriers as it is

I suppose we can infer from this that the private aliases entries for wmflabs.org don't send off to any other labs mail servers in a way that wouldn't be permitted to other random internet servers.

In T208281#4706016, @faidon wrote:

If at some point in the future we want to do smarter things like dynamic lookups to OpenStack APIs or LDAP to route inbound emails to WMCS project owners or stuff like that (similar to what tools.wmflabs.org's MX does right now) then it would probably be a good idea to split it up to its own thing.

Yeah.

So to me it sounds like we have to keep the MX record pointing at prod and set the SPF TXT record to:
v=spf1 mx ip4:185.15.56.18 ip4:185.15.56.19 ?all
(I don't think there's a way to include mx-out01/mx-out02 by name instead of IP without using MX?)

In T208281#4706209, @Krenair wrote:

So to me it sounds like we have to keep the MX record pointing at prod and set the SPF TXT record to:
v=spf1 mx ip4:185.15.56.18 ip4:185.15.56.19 ?all

Looks good to me

In T208281#4717077, @herron wrote:

In T208281#4706209, @Krenair wrote:

So to me it sounds like we have to keep the MX record pointing at prod and set the SPF TXT record to:
v=spf1 mx ip4:185.15.56.18 ip4:185.15.56.19 ?all

Looks good to me

Thanks, record updated.

Mentioned in SAL (#wikimedia-cloud) [2018-11-02T20:12:27Z] <Krenair> Updated TXT record for T208281 - just added the new mx-out IPs

Mentioned in SAL (#wikimedia-cloud) [2023-07-04T12:32:28Z] <taavi> configure DKIM signing for wmflabs.org and wmcloud.org on mx-out servers T208281