First, note that a great many enterprise use cases are total nonsense. But still: people want to be able to put messages into gmail from random other systems and have the "sent" label be applied, so they can treat it as a system of record.
I assume the use case is when email has been sent by the user, but not via Gmail. The external system can send the email to Gmail with the correct From header and have it filed along with other sent messages.
Even if that's the reason why, it's a pretty brain-dead way for them to implement it. If people want emails from a separate address that CC's Gmail on sending to be seen as sent, Gmail should have them show up like the normal emails that they are received but show a little button that asks if you want them to be seen as sent, and if you accept creates the filter to do so from that source (and shows it in filters so it can be removed later).
It's not like Gmail doesn't show "nudges" and other crap all over the place for stuff like this.
But it's implemented now in such a way that anyone can get an email in there by simply crafting the From address carefully. Out of the lesser of two evils, I know which one I would vote for.
Besides, since in the proposed solution the system is creating the filter, it could bypass checks that require the label not be sent. Just because it shows in filters, and it can be removed from filters by the user, doesn't mean it has to be able to be created through the normal filter mechanism. You still have a "system of record", if that's how we want to refer to this feature, it just requires a single initial setup step on the first received email that is intended to be kept as sent. That's entirely in line with how Gmail currently does things, such as allowing alternate From addresses (which requires an authorization step).
I'm on board with this style of thinking. After reviewing the comments with the linked tagging behavior it's clear that Google is ignoring the spirit of RFC 2822 3.6.2-3.6.3 in order to shoe-horn in a feature of some possible utility, at the expense of the average customer's security.
It's a bug that this can be forged by an outside attacker, even if it is a consequence of the implementation of a feature.
(In fact, it's a bug that defeats the central purpose of the “system of record” feature it’s been suggested that the underlying functionality exists to support, as trustworthiness is the essential point of a system of record.)
