[GH-ISSUE #140] Is there a reason for the current Content-Security-Policy header setup?

kerem commented

2026-03-15 12:31:19 +03:00

Owner

Originally created by @soullivaneuh on GitHub (Jul 11, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/140

I just migrated from MailHog to your project (nice one BTW!), and I am struggling with an issue: The google font I usually load from my html mail content are not loaded anymore, triggering this kind of error:

Content Security Policy: The page’s settings blocked the loading of a resource at https://fonts.googleapis.com/css2?family=Inter:wght@100;200;300;400;500;600;700;800;900&display=swap (“style-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at https://fonts.googleapis.com/css?family=Fira+Code&display=swap&subset=latin-ext (“style-src”).

After some investigation, I figure out a Content-Security-Policy header is set on this application:

> http --headers :8025                                                                                                      
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Encoding: gzip
Content-Length: 359
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; frame-src 'self'; img-src * data: blob:; font-src 'self' data:; media-src 'self'; connect-src 'self' ws: wss:; object-src 'none'; base-uri 'self';
Content-Type: text/html; charset=utf-8
Date: Tue, 11 Jul 2023 08:24:50 GMT
Referrer-Policy: no-referrer

This is not the case of MailHog:

> http --headers :8025
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Tue, 11 Jul 2023 08:25:49 GMT
Transfer-Encoding: chunked

I assume this come from that.

Font loading from Google Font is used for our mails from a moment without issue on the mail client we tested so far.

Is that a mistake or is it intended? If intended, may you please give us an explanation of why?
In a more general way, are you aware about some best practices concerning the external font loading on emails?

Thanks!

Originally created by @soullivaneuh on GitHub (Jul 11, 2023). Original GitHub issue: https://github.com/axllent/mailpit/issues/140 I just migrated from MailHog to your project (nice one BTW!), and I am struggling with an issue: The google font I usually load from my html mail content are not loaded anymore, triggering this kind of error: ``` Content Security Policy: The page’s settings blocked the loading of a resource at https://fonts.googleapis.com/css2?family=Inter:wght@100;200;300;400;500;600;700;800;900&display=swap (“style-src”). Content Security Policy: The page’s settings blocked the loading of a resource at https://fonts.googleapis.com/css?family=Fira+Code&display=swap&subset=latin-ext (“style-src”). ``` After some investigation, I figure out a `Content-Security-Policy` header is set on this application: ``` > http --headers :8025 HTTP/1.1 200 OK Accept-Ranges: bytes Content-Encoding: gzip Content-Length: 359 Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; frame-src 'self'; img-src * data: blob:; font-src 'self' data:; media-src 'self'; connect-src 'self' ws: wss:; object-src 'none'; base-uri 'self'; Content-Type: text/html; charset=utf-8 Date: Tue, 11 Jul 2023 08:24:50 GMT Referrer-Policy: no-referrer ``` This is not the case of MailHog: ``` > http --headers :8025 HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Date: Tue, 11 Jul 2023 08:25:49 GMT Transfer-Encoding: chunked ``` I assume this come from that. Font loading from Google Font is used for our mails from a moment without issue on the mail client we tested so far. Is that a mistake or is it intended? If intended, may you please give us an explanation of why? In a more general way, are you aware about some best practices concerning the external font loading on emails? Thanks!

kerem

2026-03-15 12:31:19 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-15 12:31:35 +03:00

Author

Owner

@axllent commented on GitHub (Jul 11, 2023):

I'm glad to hear you like Mailpit! Firstly, yes, (as you have noticed) Mailpit is very security and privacy-focused with regards to script execution as well as remote data loading. MailHog does not have any security policies, so allows loading of anything (potentially even inline and remote JavaScript which could be very dangerous). Some of these security policies are documented in the wiki. Given that HTML emails load directly in the web browser, and that I have no idea or control over what HTML emails are going into Mailpit (eg: spam trap), it only made sense to "lock down" what content can and can't be loaded and/or run within the HTML viewer to protect the user. This is in line with one of the largest email providers (Gmail), not to mention many of the others, and was ultimately what I am trying to replicate - what you see in Mailpit is more-or-less what you will see when viewing the email on any email client.

Fonts is a contentious topic - there are only a handful of email clients and web services that properly support remote web fonts, and many (eg: Gmail) actively do not support it at all. If you are relying on web fonts for email styling, then you also should also be aware that a large percentage of your users probably don't see them - they will see your fallback font if you have one, or otherwise Times New Roman in many cases. My rule of thumb is simply don't use web fonts in emails.

With that said however, remote images are supported in Mailpit of course, which in itself is probably just as much of a privacy concern as fonts, so this is probably something I could add/allow. Unfortunately it's often not just a web font, but also remote CSS too, which raises some other potential concerns (in my opinion).

Can you tell me how you are loading web fonts in your emails? Ideally a working example would be very useful for me to test with.

@axllent commented on GitHub (Jul 11, 2023): I'm glad to hear you like Mailpit! Firstly, yes, (as you have noticed) Mailpit is very security and privacy-focused with regards to script execution as well as remote data loading. MailHog does not have any security policies, so allows loading of anything (potentially even inline and remote JavaScript which could be very dangerous). Some of these security policies are documented in the [wiki](https://github.com/axllent/mailpit/wiki/UI-security-policies). Given that HTML emails load directly in the web browser, and that I have no idea or control over what HTML emails are going into Mailpit (eg: spam trap), it only made sense to "lock down" what content can and can't be loaded and/or run within the HTML viewer to protect the user. This is in line with one of the largest email providers (Gmail), not to mention many of the others, and was ultimately what I am trying to replicate - what you see in Mailpit is more-or-less what you will see when viewing the email on any email client. Fonts is a contentious topic - there are only a handful of email clients and web services that properly support remote web fonts, and many (eg: Gmail) actively do not support it at all. If you are **relying** on web fonts for email styling, then you also should also be aware that a large percentage of your users probably don't see them - they will see your fallback font if you have one, or otherwise Times New Roman in many cases. My rule of thumb is simply don't use web fonts in emails. With that said however, remote images are supported in Mailpit of course, which in itself is probably just as much of a privacy concern as fonts, so this is probably something I could add/allow. Unfortunately it's often not just a web font, but also remote CSS too, which raises some other potential concerns (in my opinion). Can you tell me how you are loading web fonts in your emails? Ideally a working example would be very useful for me to test with.

kerem commented

2026-03-15 12:31:40 +03:00

Author

Owner

@soullivaneuh commented on GitHub (Jul 11, 2023):

I back, thanks for the quick and complete answer!

After reading your notes and your wiki, I did a double check on my gmail sample and it seems you are right, the font are not loaded either.

In fact, it a bit more tedious to understand: We do not have the same behavior at gmail, meaning the Content Security Policy error, because gmail simply get rid of any content I put on my <head> block before rendering the email. 🙃

So the bug I reported since I move from MailHog is not a bug but more a revelation of a problem we had from a time now.

There is nothing more to do for my personal case. I let the issue open if you want to go further with the web font loading feature, but feel free to close it!

Thanks.

@soullivaneuh commented on GitHub (Jul 11, 2023): I back, thanks for the quick and complete answer! After reading your notes and your wiki, I did a double check on my gmail sample and it seems you are right, the font are not loaded either. In fact, it a bit more tedious to understand: We do not have the same behavior at gmail, meaning the Content Security Policy error, because gmail simply get rid of any content I put on my `<head>` block before rendering the email. :upside_down_face: So the bug I reported since I move from MailHog is not a bug but more a revelation of a problem we had from a time now. There is nothing more to do for my personal case. I let the issue open if you want to go further with the web font loading feature, but feel free to close it! Thanks.

kerem commented

2026-03-15 12:31:45 +03:00

Author

Owner

@axllent commented on GitHub (Jul 11, 2023):

At work we always use an emogrify plugin to inline all CSS directly into the html element styles. This means that a) there is no requirement for anything in the head, and b) there are no external requirements, other than images. This gives us best results on all platforms.

I'm still on the fence regarding allowing remote CSS/fonts though, as it's not really my job to enforce that just because Gmail does this, but then I also want to protect the Mailpit users. I'll leave this open for now and give it more thought. I'd still be keen on an example email from you though.

@axllent commented on GitHub (Jul 11, 2023): At work we always use an emogrify plugin to inline all CSS directly into the html element styles. This means that a) there is no requirement for anything in the head, and b) there are no external requirements, other than images. This gives us best results on all platforms. I'm still on the fence regarding allowing remote CSS/fonts though, as it's not really my job to enforce that just because Gmail does this, but then I also want to protect the Mailpit users. I'll leave this open for now and give it more thought. I'd still be keen on an example email from you though.

kerem commented

2026-03-15 12:31:50 +03:00

Author

Owner

@gitgrub commented on GitHub (Jul 16, 2023):

Better keep things secure/local.

@gitgrub commented on GitHub (Jul 16, 2023): Better keep things secure/local.

kerem commented

2026-03-15 12:31:55 +03:00

Author

Owner

@axllent commented on GitHub (Jul 17, 2023):

I do agree. In relation to the original request though, I have started on a whole new piece of functionality which validates a HTML message's email client support (for various common email programs & webmail). The validation tests both HTML and CSS support, and the validator needs to download any linked stylesheets in order to determine the usage & support. It's a big piece of code as there are many moving parts, however I will also have to consider the option of disabling the web UI functionality entirely with a startup flag as not everyone may want that. Lots to do, lots to consider.....

@axllent commented on GitHub (Jul 17, 2023): I do agree. In relation to the original request though, I have started on a whole new piece of functionality which validates a HTML message's email client support (for various common email programs & webmail). The validation tests both HTML and CSS support, and the validator needs to download any linked stylesheets in order to determine the usage & support. It's a big piece of code as there are many moving parts, however I will also have to consider the option of disabling the web UI functionality entirely with a startup flag as not everyone may want that. Lots to do, lots to consider.....

kerem commented

2026-03-15 12:32:00 +03:00

Author

Owner

@axllent commented on GitHub (Jul 30, 2023):

@soullivaneuh In relation to a new feature I have added (HTML check), remote CSS and fonts are now enabled by default.

I did hear you @gitgrub, so this can be disabled via --block-remote-css-and-fonts if you really do not want it. All changes in the latest release (v1.8.0). I'm closing this ticket as complete, but feel free to reopen it if you have any issues, thanks.

@axllent commented on GitHub (Jul 30, 2023): @soullivaneuh In relation to a new feature I have added (HTML check), remote CSS and fonts are now enabled by default. I did hear you @gitgrub, so this can be disabled via `--block-remote-css-and-fonts` if you really do not want it. All changes in the latest release (v1.8.0). I'm closing this ticket as complete, but feel free to reopen it if you have any issues, thanks.

Rows
Columns

[GH-ISSUE #140] Is there a reason for the current Content-Security-Policy header setup? #95