Change Details

These queued changes are adjacent and likely make sense to execute together: See PHI54, PHI175. These issues are covered by T10448, which is likely the largest change here. That has a bunch more stuff attached to it. See T12677. Currently, you can only configure a single outbound pathway for mail. This has caused delivery issues in the production cluster on a handful of occasions. We should upgrade this to allow configuration of zero or more mailers which can failover. We should evaluate adding Postmark support and consider making it our primary outbound mail pathway given Mailgun's uneven handling of the security incident described in T13037. This is purely upstream-motivated and doesn't solve any customer needs, except that customers love it when we change configuration and always ask for more compatibility breaks. See PHI291. An install is interested in a way to mark security changes as sensitive so that they don't send details via email (e.g., "when tags include: security; take action: mark mail as sensitive"). Instead, users would receive a placeholder message without any content, just a link to the web UI ("This message is about a sensitive object, click to see the content: ..."). See PHI178 and PHI126. See T12689. When users resign from a revision, they should not receive mail about it even if they're a member of a non-resigned package or project. This requires propagating mail recipients deeper into the stack, and retaining richer recipient information. Subscriptions should be upgraded to support a stronger "unsubscribe" which can get you out of indirect subscriptions via projects/packages/etc. These probably mostly go down the same pathway. See PHI125. Mail attachments are stored in JSON, and fail when they are not UTF8. Attachments should be stored in Files instead. See T4776. We don't tell you that someone took you off the recipient list for an object. This isn't a huge deal, but is a meaningful policy concern and inconsistent with how we do things in other cases. We should plug up this hole. See T12491. We send errors to unverified addresses, but this is inconsistent with other mail policy. See T9141. Although this probably won't be exhaustive, these changes can rename "MetaMTA" to "Mail" where it's easy to test. --- Scope creep: See T12630. This may be an easy bug to fix. See T11138. Maybe this is also a real bug? See T12404. Breaking our dependency on PHPMailer would be great, but this is probably a good chunk of work and not realistic to get into scope until we learn about at least 3-4 more RCE vulnerabilities. See T7477. This may also be outside of reasonable scope but describes a general infrastructure improvement. --- Errata: **Thread-Topic**: Some applications currently generate a Thread-Topic like `D123 Flub the blubber`. This was because I believed mail clients were likely to show the value of this header to users in some cases when I originally wrote the logic. However, I now believe that no client shows this value to users or expects it to contain a human-readable thread description or subject. More modern applications generate either `D123: PHID-DREV-xxx` or just `PHID-DREV-xxx`, and have for many years without feedback from users about unusual client behavior. I believe the only real constraint on this field is that it must retain the same unique value across all messages in an object's discussion thread. That is, this field is a bit more like a `Thread-Unique-ID` than a `Thread-Topic`. The verbose `Thread-Topic` values are not appropriate for transmission with the "Must Encrypt" flag, because they may disclose sensitive information (`D234 Fix issue where any user account accepts password "hunter2"`). The monogram topics generally are, although it's slightly questionable because some objects (like repositories and projects) have monograms which can occasionally disclose information, and monograms are not completely immutable (repositories and projects are also examples here). The PHID-only values are appropriate for all objects and completely stable. We should probably change all applications to use PHIDs as thread topics and remove the `originalTitle` field from Differential, Maniphest, and Ponder. This will cause a one-time threading break for clients. Initially, I am keeping this header out of the "Must Encrypt" whitelist until we can make these changes. This may cause some threading issues for "Must Encrypt" messages, but they should generally resolve once we can whitelist `Thread-Topic`. **To/Cc Headers**: If `metamta.one-mail-per-recipient` is disabled, real recipients will be disclosed in the mail headers. If we don't address this directly, the documentation should be updated to include this caveat. And: - Proper escaping (or, at least, reasonable mangling-into-safety) for `"Real Name Full of Weird Symbols" <local@domain.com>` addresses. - Postmark inbound support. - In HTML mail, mail stamps in the body could be styled small and pale. There should be a little more whitespace underneath, too. - Postmark inbound CIDR ranges.

These queued changes are adjacent and likely make sense to execute together: See PHI54, PHI175. These issues are covered by T10448, which is likely the largest change here. That has a bunch more stuff attached to it. See T12677. Currently, you can only configure a single outbound pathway for mail. This has caused delivery issues in the production cluster on a handful of occasions. We should upgrade this to allow configuration of zero or more mailers which can failover. We should evaluate adding Postmark support and consider making it our primary outbound mail pathway given Mailgun's uneven handling of the security incident described in T13037. This is purely upstream-motivated and doesn't solve any customer needs, except that customers love it when we change configuration and always ask for more compatibility breaks. See PHI291. An install is interested in a way to mark security changes as sensitive so that they don't send details via email (e.g., "when tags include: security; take action: mark mail as sensitive"). Instead, users would receive a placeholder message without any content, just a link to the web UI ("This message is about a sensitive object, click to see the content: ..."). See PHI178 and PHI126. See T12689. When users resign from a revision, they should not receive mail about it even if they're a member of a non-resigned package or project. This requires propagating mail recipients deeper into the stack, and retaining richer recipient information. Subscriptions should be upgraded to support a stronger "unsubscribe" which can get you out of indirect subscriptions via projects/packages/etc. These probably mostly go down the same pathway. See PHI125. Mail attachments are stored in JSON, and fail when they are not UTF8. Attachments should be stored in Files instead. See T4776. We don't tell you that someone took you off the recipient list for an object. This isn't a huge deal, but is a meaningful policy concern and inconsistent with how we do things in other cases. We should plug up this hole. See T12491. We send errors to unverified addresses, but this is inconsistent with other mail policy. See T9141. Although this probably won't be exhaustive, these changes can rename "MetaMTA" to "Mail" where it's easy to test. --- Scope creep: See T12630. This may be an easy bug to fix. See T11138. Maybe this is also a real bug? See T12404. Breaking our dependency on PHPMailer would be great, but this is probably a good chunk of work and not realistic to get into scope until we learn about at least 3-4 more RCE vulnerabilities. See T7477. This may also be outside of reasonable scope but describes a general infrastructure improvement. --- Errata: **Thread-Topic**: Some applications currently generate a Thread-Topic like `D123 Flub the blubber`. This was because I believed mail clients were likely to show the value of this header to users in some cases when I originally wrote the logic. However, I now believe that no client shows this value to users or expects it to contain a human-readable thread description or subject. More modern applications generate either `D123: PHID-DREV-xxx` or just `PHID-DREV-xxx`, and have for many years without feedback from users about unusual client behavior. I believe the only real constraint on this field is that it must retain the same unique value across all messages in an object's discussion thread. That is, this field is a bit more like a `Thread-Unique-ID` than a `Thread-Topic`. The verbose `Thread-Topic` values are not appropriate for transmission with the "Must Encrypt" flag, because they may disclose sensitive information (`D234 Fix issue where any user account accepts password "hunter2"`). The monogram topics generally are, although it's slightly questionable because some objects (like repositories and projects) have monograms which can occasionally disclose information, and monograms are not completely immutable (repositories and projects are also examples here). The PHID-only values are appropriate for all objects and completely stable. We should probably change all applications to use PHIDs as thread topics and remove the `originalTitle` field from Differential, Maniphest, and Ponder. This will cause a one-time threading break for clients. Initially, I am keeping this header out of the "Must Encrypt" whitelist until we can make these changes. This may cause some threading issues for "Must Encrypt" messages, but they should generally resolve once we can whitelist `Thread-Topic`. **To/Cc Headers**: If `metamta.one-mail-per-recipient` is disabled, real recipients will be disclosed in the mail headers. If we don't address this directly, the documentation should be updated to include this caveat. And: - Proper escaping (or, at least, reasonable mangling-into-safety) for `"Real Name Full of Weird Symbols" <local@domain.com>` addresses. - Postmark inbound support. - In HTML mail, mail stamps in the body could be styled small and pale. There should be a little more whitespace underneath, too. - Postmark inbound CIDR ranges. - Maybe a "roles"/"disabled" option to let you disable mailers but keep them configured, or let you use a mailer for inbound-only.

These queued changes are adjacent and likely make sense to execute together: See PHI54, PHI175. These issues are covered by T10448, which is likely the largest change here. That has a bunch more stuff attached to it. See T12677. Currently, you can only configure a single outbound pathway for mail. This has caused delivery issues in the production cluster on a handful of occasions. We should upgrade this to allow configuration of zero or more mailers which can failover. We should evaluate adding Postmark support and consider making it our primary outbound mail pathway given Mailgun's uneven handling of the security incident described in T13037. This is purely upstream-motivated and doesn't solve any customer needs, except that customers love it when we change configuration and always ask for more compatibility breaks. See PHI291. An install is interested in a way to mark security changes as sensitive so that they don't send details via email (e.g., "when tags include: security; take action: mark mail as sensitive"). Instead, users would receive a placeholder message without any content, just a link to the web UI ("This message is about a sensitive object, click to see the content: ..."). See PHI178 and PHI126. See T12689. When users resign from a revision, they should not receive mail about it even if they're a member of a non-resigned package or project. This requires propagating mail recipients deeper into the stack, and retaining richer recipient information. Subscriptions should be upgraded to support a stronger "unsubscribe" which can get you out of indirect subscriptions via projects/packages/etc. These probably mostly go down the same pathway. See PHI125. Mail attachments are stored in JSON, and fail when they are not UTF8. Attachments should be stored in Files instead. See T4776. We don't tell you that someone took you off the recipient list for an object. This isn't a huge deal, but is a meaningful policy concern and inconsistent with how we do things in other cases. We should plug up this hole. See T12491. We send errors to unverified addresses, but this is inconsistent with other mail policy. See T9141. Although this probably won't be exhaustive, these changes can rename "MetaMTA" to "Mail" where it's easy to test. --- Scope creep: See T12630. This may be an easy bug to fix. See T11138. Maybe this is also a real bug? See T12404. Breaking our dependency on PHPMailer would be great, but this is probably a good chunk of work and not realistic to get into scope until we learn about at least 3-4 more RCE vulnerabilities. See T7477. This may also be outside of reasonable scope but describes a general infrastructure improvement. --- Errata: **Thread-Topic**: Some applications currently generate a Thread-Topic like `D123 Flub the blubber`. This was because I believed mail clients were likely to show the value of this header to users in some cases when I originally wrote the logic. However, I now believe that no client shows this value to users or expects it to contain a human-readable thread description or subject. More modern applications generate either `D123: PHID-DREV-xxx` or just `PHID-DREV-xxx`, and have for many years without feedback from users about unusual client behavior. I believe the only real constraint on this field is that it must retain the same unique value across all messages in an object's discussion thread. That is, this field is a bit more like a `Thread-Unique-ID` than a `Thread-Topic`. The verbose `Thread-Topic` values are not appropriate for transmission with the "Must Encrypt" flag, because they may disclose sensitive information (`D234 Fix issue where any user account accepts password "hunter2"`). The monogram topics generally are, although it's slightly questionable because some objects (like repositories and projects) have monograms which can occasionally disclose information, and monograms are not completely immutable (repositories and projects are also examples here). The PHID-only values are appropriate for all objects and completely stable. We should probably change all applications to use PHIDs as thread topics and remove the `originalTitle` field from Differential, Maniphest, and Ponder. This will cause a one-time threading break for clients. Initially, I am keeping this header out of the "Must Encrypt" whitelist until we can make these changes. This may cause some threading issues for "Must Encrypt" messages, but they should generally resolve once we can whitelist `Thread-Topic`. **To/Cc Headers**: If `metamta.one-mail-per-recipient` is disabled, real recipients will be disclosed in the mail headers. If we don't address this directly, the documentation should be updated to include this caveat. And: - Proper escaping (or, at least, reasonable mangling-into-safety) for `"Real Name Full of Weird Symbols" <local@domain.com>` addresses. - Postmark inbound support. - In HTML mail, mail stamps in the body could be styled small and pale. There should be a little more whitespace underneath, too. - Postmark inbound CIDR ranges. - Maybe a "roles"/"disabled" option to let you disable mailers but keep them configured, or let you use a mailer for inbound-only.