Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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 firstname.lastname@example.org could make requests to the same server as an email sent from email@example.com 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
In response, the server may verify that
If the request has been verified, the server is expected to include the
The server should appropriately respond to a preflight request (
The server may also include
The server should not normally expose
After a review from members of the working group, this proposal will be moved to be part of the amp.dev documentation.
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.