Google has been rewriting the click target in gmail's web presentation for years. That is not the same, or even related, to changing the URL in the email itself (as presented by SMTP or IMAP).

I can confirm I'm seeing this -- I just noticed, searched Google, and ended up ... here.

I have an email generated by one of our internal systems with a link to it, fetched via IMAP using Apple Mail, and the link is edited to be like so:

https://www.google.com/url?q=<ORIGINAL-URL>&amp;source=gmail...

We're on GSuite Business, and under "Spoofing and Authentication", have "Apply future recommended settings automatically." enabled. Probably some other options, too. I happen to have "Advanced Protection Program" enabled for my account; so this may be happening because of that.

Given the phishing attempts I've seen in my career, having this as an opt-in option for certain users ... well, let's just say I've personally had users I would have had this turned this on for and we would all be happier. I can also see the privacy concerns.

Perhaps we'll learn more about the opt-in / opt-out details in the coming days, so that users can make the appropriate choices for themselves?

Can you confirm you account is actually set to "IMAP" and not "Google" in macOS? See my other comments in the thread where this only happens for me under that condition. Downloading the messages via pure IMAP produces unmodified links.

I can and have reproduced this for over a week now and have been hammering google & apple to fix it with no luck. Google says it's an Apple issue and Apple says it's a Google issue. The issue only appears to surface under specific use cases and always requires the user to have setup Mail.app on macOS or iOS with the gsuite account/user set to type "Google" vs. "IMAP". This seems to be the real pickle as all the following use cases below require this to be true for the link manipulation to occur. The same messages viewed in gmail.com or in Mail.app on macOS or iOS with the account type set to "IMAP" have their links left untouched.

- Sending a message from a gsuite account user to an external party DOES NOT show the issue

- Sending a message from an internal gsuite account user to another user in the same gsuite account + another user outside of the gsuite account DOES show the issue

- Sending a message from a gsuite account user to another gsuite user in the same account DOES NOT show the issue

- Sending a message from an external account into a gsuite account user DOES SHOW the issue (this might be tied to admin settings in G Suite > Settings for Gmail > Safety - still needs to be tested more)

- The same messages that DO SHOW the issue only show it in Mail.app on macOS & iOS when the gsuite user account is setup as "Google" vs. "IMAP". It DOES NOT show up in the GMAIL iOS app nor does it show up in the gmail.com web interface.

Google support has been effectively useless. Apple support has honestly done more to shed light on the issue. However, both companies are blaming the other and refusing to escalate to engineering or get on a call with the other company to sort this out together. Of course, Google support claims nobody else is reporting this, while Apple support alerted me to this thread. Super frustrating all around. If you are a Gsuite user please report this so I'm not yelling into the wind here. I can also confirm for my account the issue started on October 6, 2020.

Do you have a link to that twitter?

> Google seems to hide this via Javascript.

I'm like 200% sure Google can't "hide this via JavaScript" (whatever "this" means) in my native mail client if they have actually rewritten the URLs, which is the accusation here.

But you said in another comment that you couldn't reproduce the OP's accusation "including on webmail." Gmail has been rewriting links in the web interface for all users using JavaScript for years now.

Maybe my comment isn't clear when viewed in isolation, but I was (and I believe OP was) talking about rewriting href of a tags, or in the case of bare links, rewriting the text altogether. So adding a data-saferedirecturl attribute and using that in the click handler is entirely different. Btw the data-saferedirecturl attribute is not found in the email bodies when downloaded via IMAP. I didn't check Gmail's REST API but I assume someone else has checked that too with a client using that.

I mean, given the linked screenshots, the accusation is very clear, and no one has thus far reproduced anything close to that.

(Incidentally I'm no stranger to Google redirects. I don't use webmail normally, but I did write an extension to remove the redirects from Google SERP...)

> So adding a data-saferedirecturl attribute and using that in the click handler is entirely different.

The end result is the same. Gmail is rewriting url in their web interface. While there isn't enough evidence yet to decide whether they're attempting to do the same for IMAP, the fact that they do it in the web interface is undeniably true.

That is why I said "on gmail.com" which is Googles web interface. I don't use a local mail software.