First of all, this is not a "problem" which needs "modelling". This is just a syntax issue.
Secondly, why on earth would you even think of using a builder pattern for this? Is it perhaps because you read "Clean Code", where on page 35 the author classifies methods into four categories, depending on whether they accept zero, one, two, or the incredibly high number of three arguments, with four arguments being, presumably, unthinkable? Oh, never mind him, he was just being silly.
Things should be as simple as possible, but not simpler
Methods should accept as few arguments as possible, but not fewer than what they need to do their job.
The builder pattern is generally an overkill for messages, because what you usually want to do with a message is to instantiate it, fill it, and send it on its way using as few lines of code as possible. Ideally, just one line of code.
As a matter of fact, sending a message should look syntactically identical to placing a function call, and the fact that it does not look identical in most mainstream languages is a shortcoming of those languages. What we basically want to do is to place an asynchronous call. The fact that a message is to be used to achieve this is just an implementation detail which should be hidden from us, and the fact that we still have to waste our time dealing with implementation details like constructing, filling, and sending messages, (let alone defining and maintaining entire class hierarchies of messages,) just shows that languages still have a long way to go.
So, in lack of any better mechanisms, the task of instantiating, filling, and sending a message should not be any more complicated than this:
sendMessage( new MyMessage( 123, XYZ, configuration, metafile ) );
Of course, the
MyMessage class presumably extends some
Message class, (which you are for some reason thinking of as a
Header,) so the first statement of the constructor of
MyMessage will be as follows:
super( version, type );