Bug #13274

Messy links in CAC email notifications

Added by Matt Gold over 1 year ago. Updated over 1 year ago.

Priority name:
Category name:
Email Notifications
Target version:
Start date:
Due date:
% Done:


Estimated time:


Hi Ray,

We're seeing an issue where emails forwarded with embedded links to CAC groups result in emails where the URLS appear in full. This can be problematic when those URLs are long, as is the case for the GC system, which adds Proofpoint spam prevention info to each link. I've attached a few screenshots and original emails to this message:

1. Original email (screenshot + raw content)
2. Commons email notification (screenshot + raw content)

Is there any way to improve this situation that you can think of? The issue is that the Commons email notifications become almost unreadable with the long links.

original-email-screenshot.png (120 KB) original-email-screenshot.png Matt Gold, 2020-09-02 09:35 PM
original-email-raw-content.eml (10.1 KB) original-email-raw-content.eml Matt Gold, 2020-09-02 09:35 PM
cac-notification-screenshot.png (226 KB) cac-notification-screenshot.png Matt Gold, 2020-09-02 09:35 PM
cac-notification-email-raw-content.eml (23.1 KB) cac-notification-email-raw-content.eml Matt Gold, 2020-09-02 09:35 PM
Screen Shot 2020-09-08 at 12.43.56 PM.png (96 KB) Screen Shot 2020-09-08 at 12.43.56 PM.png email--clicked-forward-but-not-sent Matt Gold, 2020-09-08 12:45 PM


#1 Updated by Boone Gorges over 1 year ago

I'd like Ray to chime in as well, but I'd say that there's no real way around this. What appears to be happening is that the Forward feature in the mail client (whether the web client or some mail application on a device) is getting its content from the plaintext version of the email. And ProofPoint injects its wrappers directly into the text of the email, which means that if you're forwarding from a GC address, the long URLs are actually in the email content. The whole thing - ProofPoint URL injection and forwarding - happens well after the Commons has sent the email.

One thing worth mentioning is that this probably only surfaces in cases where the mail client uses plaintext content for forwarding. This may be configurable on a per-client basis, and it is not the default behavior for some clients, so it's likely that this is not a super widespread issue.

#2 Updated by Matt Gold over 1 year ago

Hi Boone -- following our discussion of this during the dev call, I'm attaching a screenshot of what I see when I click "forward" in my email client. As you'll see, the links are still embedded -- it looks exactly like the original email I received in my inbox.

I am using Gmail through the web interface on the Chrome browser

#3 Updated by Boone Gorges over 1 year ago

Thanks, Matt. This info helps to narrow it down a bit. It sounds like maybe this is something that RBE can handle more gracefully.

#4 Updated by Raymond Hoh over 1 year ago

  • Target version set to 1.17.8

Got distracted with other things and missed this one. Apologies!

RBE parses the plain-text content of the email before posting it to bbPress. Combine that with how ProofPoint changes the content of the email and you get the messy output in the forums and emails. Switching over to HTML email parsing would involve refactoring parts of RBE, which would take longer.

However, it is possible to filter the output on the frontend and also in group email blasts. I have a fix on production, which changes the ProofPoint content from the following:

Build: October – December 2020
Launch: 4 December 2020 at 1:00-2:00pm (EST) – Register here


Build: October – December 2020
Launch: 4 December 2020 at 1:00-2:00pm (EST) – Register here

( is a hyperlink to the Zoom webinar. The sample above can be seen at

As you can see, I've changed the long ProofPoint URL to only the domain of the actual link instead of the full URL ( However, let me know if we would prefer the full URL to be displayed, or if we want to add something to the link to denote that it is a link. For example, (LINK -

#5 Updated by Matt Gold over 1 year ago

that's really awesome, Ray! Thank you! As long as it is clear it is a URL, I would say that we don't need to include "LINK"

#6 Updated by Raymond Hoh over 1 year ago

  • Status changed from Assigned to Resolved

Thanks for the feedback, Matt.

I've committed the change, which is already live on production:

#7 Updated by Matt Gold over 1 year ago

Amazing. Thanks, Ray!!

Also available in: Atom PDF