Images broken in emails due to Discourse being behind a private firewall

When a user sends an email, the avatar and attachments are broken. Avatars are default with their first name initial being the avatar.

So I notice the image links aren’t attached to the emails, it’s just copying the direct URL from my discourse server which is behind a firewall.

Do the emails not actually properly attach? Sounds like I might have to setup S3 if there isn’t any other option.

S3 fixed the image links but now the s3 files are publicly accessible

Avatars still aren’t being sent through emails correctly for my discourse which is behind a firewall.

It appears as.

Any update on this? Anyone else notice the image links are broken on my last post?

If your server is behind a firewall, the only way an email client will be able to load them is if the network connection is able to access the server.

This is the unfortunate reality of HTML email.

That’s not try because the links are broken in the emails and I can access the forums from this computer. Google Apps puts some sort of CDN link in front of the image urls and Google can’t talk to my discourse server.

Why isn’t discourse emails setup properly to attach images to emails rather than using links from a server that’s behind a firewall.

If this is something that can’t be fixed by the Discourse team, what are my options? I already moved files to s3, can I setup my server to put avatars in s3 as well?

or can we disable Avatars in emails?

1 Like

Because inline images in HTML emails are not sent as attachments, they’re sent as <img src="..."> references that must be addressable network resources. Doing such might be possible (?) but it is by no means would be a standard solution.

Google might have a way to avoid caching in their clients; I’m not sure but some searching would turn up a method if it exists.

So switching to S3 will fix the actually files but not the avatars?

I would imagine so, but remember, if you’re storing things on S3, those are publicly available, so you should consider the security risk if your internal server hosting something sensitive (particularly topic attachments!).

I think Discourse caches all profile photos, even those served up by Gravatar, so not sure how you could resolve that other than by using a different email client. :slight_smile:

Yeah I’m aware of those risks, I’ll have to bring it up with the rest of my team to see if we need to consider killing off file uploads.

There is an option to disable caching uploaded avatars but my issue is the letter avatars that are default. Can discourse provide any insight on disabling avatars in emails or assistance with getting avatars working?

Is your external system avatars enabled site setting enabled? I don’t use this myself so can’t say exactly how it works, but I’d assumed that would load the letter-based avatars from some external CDN that runs…

A quick Google search came up with this result; which I assume you’ve already read and tried?

“Set up an image URL proxy whitelist”

1 Like

I actually haven’t, I’ll check this out thanks.

As for the external system, I do have it checked but the URL is still an internal link URL.

1 Like

Right, by default for self-installs it sets the letter avatar urls to /letter_avatar_proxy which nginx proxies to so that the server IP is revealed instead of all your visitors’. (Though note that the IPs are not stored or logged anyways.)

You can switch by changing the url format to replace /letter_avatar_proxy/ with .

I updated the url format and the avatars in emails are still trying to download the avatar image from my server rather than discourse.

The Avatar proxy still doesn’t seem to be working when I change it to

If there could be an option to disable the avatars in the emails, that would fix this issue too.

Is there an update on this?

It’s annoying that custom avatars uploaded don’t show up in emails since Discourse is behind a firewall.

I had a Discourse behind a firewall, but our users emails were behind the same firewall, so everything woked just fine.

You have a peculiar case, where Discourse itself is in a “safe place” but you send this safe content to the internet over e-mails. Looks like a good use case for Secure Email Mode.