I think that's true from the IETF side of things, but practically speaking
that's rarely what happens. What arrives at an ingress MTA contains all kinds
of insane things, and in my experience the choice to reject them outright puts
huge pressure on customer service facilities that nearly always results in
demands for more relaxed software. And since that turns it into a business
case, the pressure usually wins.
More like "almost always". I estimate we average one complaint that turns out
to be message maformation every week or two, and it's been this way for almost
two decades. But despite the fact we as a matter of policy *always* push back
saying "fix the actual problem", I can't recall more than a handful of cases
where this resulted in the actual problem being tracked down and fixed.
Workarounds are a lot easier than, say, getting a printer manufacturer
to update their firmware so it doesn't produce this content-type header:
context-type: 'image/tiff'
(Yes, that's an actual example from a few weeks back, and also note that while
it is clearly maformed, it's syntactically legal.)
Additionally, the various options we provide for stricter message checking are
among the few options we've implemented that AFAIK are essentially never used
by anyone, ever.
So given that reality, this work seems to make sense to have out there,
rather than allowing widely varied choices about how to handle this case or
that one that result in weak ingress security all around.
I agree, although I suspect getting consensus on this is going to be difficult.
Ned