Change Details

Ref T13065. `mailKey`s are a private secret for each object. In some mail configurations, they help us ensure that inbound mail is authentic: when you send you mail, the "Reply-To" is "T123+456+abcdef". - The `T123` is the object you're actually replying to. - The `456` is your user ID. - The `abcdef` is a hash of your user account with the `mailKey`. Knowing this hash effectively proves that Phabricator has sent you mail about the object before, i.e. that you legitimately control the account you're sending from. Without this, anyone could send mail to any object "From" someone else, and have comments post under their username. To generate this hash, we need a stable secret per object. (We can't use properties like the PHID because the secret has to be legitimately secret.) Today, we store these in `mailKey` properties on the actual objects, and manually generate them. This results in tons and tons and tons of copies of this same ~10 lines of code. Instead, just store them in the Mail application and generate them on demand. This change also anticipates possibly adding flags like "must encrypt" and "original subject", which are other "durable metadata about mail transmission" properties we may have use cases for eventually.

Ref T13065. `mailKey`s are a private secret for each object. In some mail configurations, they help us ensure that inbound mail is authentic: when we send you mail, the "Reply-To" is "T123+456+abcdef". - The `T123` is the object you're actually replying to. - The `456` is your user ID. - The `abcdef` is a hash of your user account with the `mailKey`. Knowing this hash effectively proves that Phabricator has sent you mail about the object before, i.e. that you legitimately control the account you're sending from. Without this, anyone could send mail to any object "From" someone else, and have comments post under their username. To generate this hash, we need a stable secret per object. (We can't use properties like the PHID because the secret has to be legitimately secret.) Today, we store these in `mailKey` properties on the actual objects, and manually generate them. This results in tons and tons and tons of copies of this same ~10 lines of code. Instead, just store them in the Mail application and generate them on demand. This change also anticipates possibly adding flags like "must encrypt" and "original subject", which are other "durable metadata about mail transmission" properties we may have use cases for eventually.

Ref T13065. `mailKey`s are a private secret for each object. In some mail configurations, they help us ensure that inbound mail is authentic: when youwe send you mail, the "Reply-To" is "T123+456+abcdef". - The `T123` is the object you're actually replying to. - The `456` is your user ID. - The `abcdef` is a hash of your user account with the `mailKey`. Knowing this hash effectively proves that Phabricator has sent you mail about the object before, i.e. that you legitimately control the account you're sending from. Without this, anyone could send mail to any object "From" someone else, and have comments post under their username. To generate this hash, we need a stable secret per object. (We can't use properties like the PHID because the secret has to be legitimately secret.) Today, we store these in `mailKey` properties on the actual objects, and manually generate them. This results in tons and tons and tons of copies of this same ~10 lines of code. Instead, just store them in the Mail application and generate them on demand. This change also anticipates possibly adding flags like "must encrypt" and "original subject", which are other "durable metadata about mail transmission" properties we may have use cases for eventually.