A piece of software of standard value and little note.
Thu, Jan 14
Recently smtp-relay.gmail.com stopped accepting email from our Phabricator instance because it turns out Phabricator was sending HELO localhost.localdomain instead of HELO smtp-relay.gmail.com when doing the SMTP connection.
Sep 15 2020
I've marked D21461 as resolving this, since the new errors surface the particulars:
Aug 13 2020
I think every other AWS interaction already uses v4, since D14978 (January 2016).
Oct 26 2019
I am running through GPG for the first time:
Sep 8 2019
Aug 12 2019
Jun 29 2019
This is sort of generically concerning to me:
Jun 19 2019
Jun 18 2019
Aha! This user very cleverly added firstname.lastname@example.org to their user account before they were disabled.
Apr 15 2019
Apr 14 2019
Mar 16 2019
Mar 14 2019
I also vaguely think some mailer API historically rejected mail with a "Message-ID" header with an actual error ("You can't set this header, we're going to set it for you.") rather than just ignoring/replacing it (maybe SendGrid?), but I might be misremembering or that behavior may have changed. We could still always set the header and drop it in the Adapter nowadays, this whole thing is just a nest of hornets and kicking it has pretty limited upside.
I was imagining keeping the Message-ID, while having the first email also include the same value for In-Reply-To — I completely agree that removing the Message-ID would not work out. If the first email always included both fields, thus referencing itself as a reply to itself, I suppose there could be MUAs that would go into infinite loops. So, maybe too risky.
I can imagine that cases like this may exist:
The only effect I can imagine of always setting the In-Reply-To would be to encourage threading where it's not currently happening, so removing the behavior and deleting all these little methods would be very attractive to me if it were my project. :)
There's probably some argument here for removing this behavior and assuming we can never generate a "Message-ID", but I'm hesitant to make changes like that since client threading is largely unknowable black magic which we can not test, and the current approach seems to generally produce acceptable results without an overwhelming amount of collateral complexity.
Feb 25 2019
A very mild point in favor of this feature is that we haven't seen any negative feedback or confusion, although I think you might be the first user to say they actually like/use it.
FWIW I appreciate and use the mute feature (though only occasionally)
Feb 15 2019
Jan 29 2019
Jan 21 2019
I believe D19969 has now fixed this, although I'm not entirely certain, since it was never reliably reproducible in production so there's no way to really test or verify it.
Jan 19 2019
D19968 got us closer here, but the link targets aren't actually rendering properly.
Jan 17 2019
Jan 16 2019
D19955 has how I think this likely breaks down, I'm not planning to touch it in this iteration since the badness, while bad, is mostly in a box (hopefully) until the next PHPMailer CVE. All yours!
When I was messing around with SMS sending last week, I put a rough cut of this together that is capable of sending an SMS using SNS, which has almost the same API as SES: D19982. I can tackle this unless you're already in the middle of it.
Jan 15 2019
(I'm not 100% sure that D19972 fixes this completely, but it appeared to locally. In the future, "Mail Stamps" should include this information in a more reliable format, although they do not currently include transaction information. See T13069.)