Hello,

fundraising@ is in Google

fundraising@wikimedia.org
  router = ldap_account, transport = remote_smtp
  host aspmx.l.google.com [173.194.204.27]

The following more or less related aliases exist in exim:

 91 #Wikicontribute alias
 92 wikicontribute: donate
 93 # rt-1573
 94 paypalGC:   donate
...
101 # rerouting these for the fundraiser to not overload OTRS
102 #donation:  info-en
103 #donations: info-en
104 #donate:    info-en
105 donation:   fundraising
106 donate:     fundraising
107 donations:  fundraising
...

The exim alias file is mailed to officeit@wikimedia.org automatically once every week so that you can look these up yourself.

We would love it if you could move those over to OIT as part of T122144.

Other fundraising related aliases have been moved or removed in:

T128647, T127489, T127488

Cheers,

Daniel

jimmy@ and katherine@ are in Google:

jimmy@ has been removed from our side as an urgent request from JKrauska back in 2016 in T123315.

jimmy@wikimedia.org
  router = ldap_group, transport = remote_smtp
  host aspmx.l.google.com [172.217.197.26]

katherine@wikimedia.org
  router = ldap_account, transport = remote_smtp
  host aspmx.l.google.com [209.85.144.26]

jimmy@wikipedia.org is an alias for jimmy@wikimedia.org on our side (if you can add it on your side instead, please let us know). same for katherine@wikipedia.org -> katherine@wikimedia.org

Thank you @Dzahn and @JGulingan

@Dzahn the origin of this Task is from a conversation between Donor Services and OIT. We have a persistent issue that I'd appreciate your input on, as well a question - and sorry if these may be kind of noob-y questions.

The issue is related to large fundraising email sends that originate from the jimmy@wikimedia.org Google Group. That the address is a Google Group rather than a 'full/real' Gmail address is problematic for a couple of reasons, but the most acute one is that when we send fundraising emails from it, a portion of donor responses do not route to donate@wikimedia.org (and thus to Donor Services' Zendesk instance) but rather they go to the fundraising@wikimedia.org spam filter. We had to manually recover and forward ~600 valid donor responses from that spam folder the week before last, which doesn't really scale and we'd love to avoid this scenario in the future. The email team checked all their metrics & settings, and couldn't find any reason why that particular send would behave that way.

I'm not sure how to interpret the exim info you provided, so what I'm wondering is if you see any aliases or forwards that might account for donor responses to jimmy@wikimedia.org emails routing to fundraising@wikimedia.org?

fundraising@ seems to forward to donate@ properly when the spam filter does not snag things (I just tested it), we're just wondering why the responses route through there at all, and would love if possible to cut out the middle man.

The larger question is that I'm interested in deprecating both the fundraising@wikimedia.org and the problemsdonating@wikimedia.org email addresses, to streamline workflows - are there any other aliases or forwards that you can see related to those addresses? Or, if there are any suggestions or documentation from Ops' perspective about deprecating email address, please let me know. Thank you for any input you can offer!

In T252932#6150527, @MBeat33 wrote:

Hi @MBeat33,

i will reply inline.

The issue is related to large fundraising email sends that originate from the jimmy@wikimedia.org Google Group. That the address is a Google Group rather than a 'full/real' Gmail address is problematic for a couple of reasons

We are not in control of the Google side of things and I don't know the effects of a Google group vs. a "full" gmail inbox, so that is a question for OIT. What I do know though that OIT apparently has to buy "mail-only" licenses for that kind of thing.

but the most acute one is that when we send fundraising emails from it, a portion of donor responses do not route to donate@wikimedia.org

I don't know why this is the case, from our perspective jimmy@wikimedia is sent to Google and from there it's under the control of OIT. There is nothing in our config related to jimmy@ with the exception that jimmy@wikipedia gets forwarded to jimmy@wikimedia.

As a side note I am wondering if faking mail to come from Jimmy instead of from something like "Wikipedia Donor Services" is really such an advantage for fundraising results. I have seen cases where people thought legit fundraising mail was fake. But that is more curiosity on my side.

(and thus to Donor Services' Zendesk instance) but rather they go to the fundraising@wikimedia.org spam filter.

From our perspective fundraising@ is sent to Google. In our "rejectlog" I don't see any entries related to fundraising@. In our "mainlog" i see a hand full of "fundraising@wikimedia.org <donate@wikimedia.org>" mails being delivered to Google and like one that was blocked, but this looks like normal background noise.

We had to manually recover and forward ~600 valid donor responses from that spam folder the week before last, which doesn't really scale and we'd love to avoid this scenario in the future.

This sounds like you are talking about a spam folder in Google. So that means the mail already arrived on the Google mail servers and it's already past our infrastructure. I am just guessing but reasons for mail being downrated as potential spam could be the part that it looks like trying to fake mail from jimmy@ with a different return address. A "regular" gmail account would probably have less of that issue.

The email team checked all their metrics & settings, and couldn't find any reason why that particular send would behave that way.

"email team" means OIT here, right? I guess it is something to escalate on the Google side since this is about sending out from a Google group and the spam filters of Google, afaict. It is sending _from_ jimmy@ and not from donate@ , right?

I'm not sure how to interpret the exim info you provided

The format is:

<alias>: <remote address>

So for example the following line:

donation: fundraising

means that mail to donation@wikimedia.org is being forwarded ("aliased") to fundraising@wikimedia.org.

A line like this:

#donate: info-en

means it is commented out with the #, so it will do nothing.

So the summary is that donate@, donation@ and donations@ all forward to fundraising@ and that is on the Google servers, not ours anymore.

so what I'm wondering is if you see any aliases or forwards that might account for donor responses to jimmy@wikimedia.org emails routing to > fundraising@wikimedia.org?

No, i don't . In particular we deleted the jimmy@wikimedia.org part on our side back in 2016 by request from JKrauska of OIT after they created the Google group for it. The ticket for that was T123315. (This would only be different if people actually reply to donate@ and not to jimmy@).

fundraising@ seems to forward to donate@ properly when the spam filter does not snag things (I just tested it)

mail to fundraising@ is sent to Google, if there is a forward to donate@ it must be on the side of the Google group, it's not in exim. In fact in exim it's the other way around, mail to donate@ is forwarded to fundraising@ which is forwarded to Google. If Google then forwards it to donate@ again that sounds like a circle.

we're just wondering why the responses route through there at all, and would love if possible to cut out the middle man.

We would love to remove aliases from our side too! There is an ongoing effort since 2015 to move most mail aliases away from us and over to OIT. See the epic ticket T122144 with all its subtasks.

So if you can have OIT add donate@wikimedia.org, donation@wikimedia.org, donations@wikimedia.org (these forward to fundraising@wikimedia.org) and wikicontribute@wikimedia.org, paypalGC@wikimedia.org (these forward to donate@wikimedia.org) as aliases to the Google group (or whatever is needed) we would be more than happy to simply delete them from our side. All we need is to be told when it's ready and we can remove them. This should hopefully simplify things for all involved.

The larger question is that I'm interested in deprecating both the fundraising@wikimedia.org and the problemsdonating@wikimedia.org email addresses

fundraising@ has already been mentioned above. Regarding problemsdonating@ please see the ticket T127488 where we removed that on our side back in 2017 and the fundraising team as well as OIT was involved in the discussion. specifically in T127488#3414307 you can see how a Google group was created with several aliases that we used to have on our side before that.

to streamline workflows - are there any other aliases or forwards that you can see related to those addresses?

The only aliases related to fundraising@ are the ones where fundraising@ is the target. (donate@, donation@, donations@wikimedia.org)

The entire alias file for wikimedia.org is being emailed automatically once a week to the OIT team.

Then there is the same in wikipedia.org (donate@, donation@, donations@wikipedia.org are forwarded to fundraising@wikimedia.org).

Finally I see one special case, that is giving@wikipedia.org is forwarded to giving@wikimedia.org. Then giving@wikimedia.org is then sent to Google.

Again, we are more than happy to remove those. They just need to be added on the Google side and then we need to be told when it's ready.

Or, if there are any suggestions or documentation from Ops' perspective about deprecating email address, please let me know.

Either they can simply be deleted and users will get an error from the Google mail servers that mail is not deliverable or you can keep everything as is and just filter them in Google or they could be "blackholed" on the exim side where they would be silently discarded. I am not aware of anything special beyond that.

Thank you @Dzahn for the substantial update. I really appreciate it and am learning this is a pretty layered question. I am meeting with Josephine tomorrow to see if we can push forward any of the steps to simplify these emails.

if faking mail to come from Jimmy instead of from something like "Wikipedia Donor Services" is really such an advantage for fundraising results

I believe the email team has metrics that show a gain in email open rates when the fundraising emails come from a firstname@ address rather than a thing@.

"email team" means OIT here, right?

By this I mean the Advancement creative email team, who make sure that the emails we send do not set off any spam alarms from ISPs and email clients.

nothing in our config related to jimmy@ with the exception that jimmy@wikipedia gets forwarded to jimmy@wikimedia.

Thank you so much for confirming that, and for checking the rejectlog for stray fundraising@ emails - this is really helpful to know.

reasons for mail being downrated as potential spam could be the part that it looks like trying to fake mail from jimmy@ with a different return address. A "regular" gmail account would probably have less of that issue.

Really good point, I am going to advocate for not using Google Groups going forward, as it has some other issues including redacting the middle of each responding donor's email address.

Thank you also for showing me how to read the exim's, and for pointing out the other Tasks where fundraising related aliases moved or removed.

I am thinking this Task & broader conversation may also inform the Foundation's rebranding efforts. If we need to change a lot of the addresses from which we send fundraising emails and by which donors reach out to us, I'd love all stakeholders to learn from this constellation of tickets. Thanks again!

@MBeat33 You're welcome and it sounds good to me. Should we keep this ticket open for more discussion with additional stakeholders or should we close it as it answered the original question?

@MBeat33 @JGulingan

We would still like to remove the following from our config:

donate@wikimedia.org, donation@wikimedia.org, donations@wikimedia.org ( forward to fundraising@wikimedia.org)

wikicontribute@wikimedia.org, paypalGC@wikimedia.org (forward to donate@wikimedia.org)

Would it be possible to add these in Google instead? It should also make debugging things easier for you as it removes the exim part of this entirely.

Hi All,

Just to clarify, IT does not manage donate@. Can you clarify if this points to Fundraising's zendesk email?

It would look similar how techsupport@ is an alias for our zendesk ticketing system too.

donate@ is an address that is set up as a support address in Zendesk, so anything sent to it goes to the DS team

In T252932#6174068, @JGulingan wrote:

Just to clarify, IT does not manage donate@. Can you clarify if this points to Fundraising's zendesk email?

Yea, so far it's managed by SRE. That's why we are asking you to _start_ managing it so that we can remove it from our side as part of T122144. Can you create it with aliases donation@ and donations@ and forward it to fundraising@ ?

It would look similar how techsupport@ is an alias for our zendesk ticketing system too.

While techupport@ is under our control and directly points to zendesk, donate@ does not. It is merely an alias for fundraising@ which is under your control.

If you could handle techsupport@ on your side as well that would be great.

In T252932#6174074, @MBeat33 wrote:

donate@ is an address that is set up as a support address in Zendesk, so anything sent to it goes to the DS team

That must be fundraising@. donate@ is not pointing to Zendesk, it is merely an alias for fundraising@ which is handled on the Google side.

@JGulingan: Could you please answer the last comment(s)? Thanks in advance!

@JGulingan ping

Advancement stakeholders are talking about email address processes currently, fyi, so this task remains relevant.

The issue with the misrouting of the jimmy@ email replies has been solved by forwarding them all to donate@ rather than to me, so the whole team can field them.

We're still working on the issue of the fundraising@ spam folder grabbing too many valid donor responses, and may have followup questions to come.

Thanks @Dzahn We are working this quarter to come up with a strategy for Q3 to mitigate the fundraising@ spam folder issue. There are a few stakeholders involved so Q3 is when we'll have capacity to act on this.

boldy merging into T297915 based on T297307#7577554