Because email has been used in a wide range of ways in the past, including some where genuine email passes through relays which add random crap to the end of them. The same applies with email headers: you can't sign all of them, because random headers will be added in-flight. The parameter is a hack to prevent such relays from completely breaking it.

But I agree, it should've never been used in the first place because it completely undermines the whole concept of signing email. There should be a very clear separation between signed and unsigned.

Because every server an email passes through will at least add its own Received header, and every antispam, DLP and antivirus crap appliance in the chain adds another one or more.

Usually, you have 1-3 Received header from the sending email organization (record I've seen is five - three ordinary mailservers and two for AV and DLP crap), then you got Proofpoint adding 2-3 layers, and then MS Exchange or whatever adding 4-6...

That's why the sender only signs those headers he himself is aware of and sent out.

Oh, and then you got the even worse cases, email servers actually modifying the body to add "Inspected by <Bullshit Snakeoil>" footers.

Presumably because RFC822 is a legacy format and there are weird implementations out there that do things (e.g. something as simple as adding a header or signature!) that would mutate data used in a signature. This allows you to carve out a spot for the insecure stuff you can't otherwise get rid of.

Obviously it also carves out a spot for an attacker to put their own stuff in, and thus relies on downstream parsing to not get fooled[1]. Which is terrible security design in a from-scratch system. But with legacy stuff... there often isn't a choice. Security is just hard.

[1] The article isn't clear, but the closest to a root cause bug in this particular instance is actually that the mail client is validating the signature, but failing to recognize that there is unsigned data being presented to the user as part of the message. That's a tall order for client code, but that's where this particular design put the responsibility.