Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: CORS for email #7

fstanis opened this issue Jul 31, 2019 · 3 comments


Copy link

@fstanis fstanis commented Jul 31, 2019

As discussed in our previous working group meeting, we'd like to propose a standardized CORS for emails.

This proposal is meant to eventually supersede and deprecate Gmail's CORS Headers in Security requirements.


The same-origin policy exists in browsers to ensure that websites can't access resources on different origins unless access is explicitly granted via CORS headers.

However, all emails will have the same origin - the email client. This means that an email sent from could make requests to the same server as an email sent from by default.


The idea behind this proposal is to allow the server in question a mechanism to reject requests not coming from a sender they trust.


This proposal doesn't include a mechanism to guarantee the request was made from within an email client. Specifically, like CORS on the web, an HTTP request made from outside the web browser can set the origin to an arbitrary value in a way that's transparent to the server.



When an email makes a request via amp-form, amp-list or any other component that would normally be subject to CORS, the request must contain the AMP-Email-Sender header, set to the email address of the sender.




In response, the server may verify that AMP-Email-Sender is an email sender they trust. If not, the server may respond with 403 Forbidden, in which case the email client rejects the request.

If the request has been verified, the server is expected to include the AMP-Email-Allow-Sender in response. This header may be set to either:

  • A single email address the server allows, which must match AMP-Email-Sender.
  • * to allow all email senders to use the endpoint (only recommended for testing purposes).



The server should appropriately respond to a preflight request (OPTIONS) that contain the Access-Control-Request-Headers: AMP-Email-Sender header. The email client is not guaranteed to issue preflight requests, however.

The server may also include Access-Control-Allow-Origin to allow email playgrounds to use the endpoint via normal CORS mechanisms. The email clients are expected to ignore this header, unless stated otherwise in their documentation.

The server should not normally expose AMP-Email-Allow-Sender to the client via Access-Control-Expose-Headers: AMP-Email-Allow-Sender, as the checks for this header happen on the server-side of the email client.

Next steps

After a review from members of the working group, this proposal will be moved to be part of the documentation.


This comment has been minimized.

Copy link

@fstanis fstanis commented Jul 31, 2019

@cathyma123, @zhangsu, @kaewka and @latrekc: please review when you have the time.


This comment has been minimized.

Copy link

@yonghuang18 yonghuang18 commented Sep 18, 2019

The only concern I have is the transition. How do we smoothly transition to the new CORS without failing the existing AMP emails where the publisher has updated their CORS?


This comment has been minimized.

Copy link

@fstanis fstanis commented Oct 18, 2019

Initially, email clients that support old CORS should support both new and old.

Since these requests are made by the proxy controlled by an email client, they can easily log how many users switched to the new spec and potentially also remind those that haven't to do so.

But for a period of time, email clients that support some non-standard form of CORS may need to keep it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.