You are right, 8 parameters -all of them strings- make the constructor a candidate for a code review.
Consider some of the next points.
Essential attributes first
Look at the message model and guess what attributes are essential to initialize a valid instance. Reduce the number of arguments to the essential. Add setters for the rest.
If all 8 attributes are required and read-only, there's not too much to do here.
Encapsulation
Consider encapsulating related parameters. For example, a, b and c might go together within a new class. It will just reduce the number of arguments but is not going to make it simpler necessarily. However , It might contribute to express better the model and the code reuse.
Use creational patterns
Instead of initializing messages directly, do It from factories or builders.
Arrays
If none of the above works for you, try with array of parameters. Given the lack on meaningful param's names, it is probably the simplest solution.
Inheritance
With the time you will realise that messages are excellent candidates for inheritance. Segmenting messages by attribute generates a little overhead because you will find yourself often asking for the type if(message.getType() == ...).