@robert.bernhard I think this is working as expected.  the idea was to have some sort of identifier which allow end user to differentiate which headers are coming from where and hence the prefix.

@Rishi Then i would say it is not a good design and i will explain why:

• Custom Properties are used to carry certain information along with the message.
  (Similar to http header fields)
  That means you must be able to set what is agreed in your enterprise or with your systems
  you integrate with.
• Prefixing any property with jms.header does not make sense as nobody will have
  a standard property defined with jms.header in front.
  Even if you have multiple pipelines 1 publisher with streamsets as JMS producer and another as JMS consumer would get cascading jms.header.jms.header….

Option 1:
Just cut off the prefix of jms.header and just use a signal that this property should be published.
Sure that can not be done anymore as it would break backwards compatibility with the ones who 
already use current prefix.
Maybe: jms.header.skip could be used which then removes this part.

Option 2:
Best would be more flexibility to tell which headers to publish and consumer by just providing the
names and not making use of this prefix. That event supported with wild cards or regex to support
best flexibility.

I hope my explanation makes sense.

Example:

custom.property1
custom.property2
custom.property3

Quick Win:
Set on publisher:
jms.header.skip.custom.property1
Set on message:
custom.property1

Option 2:

Jms Headers to Publish/Consume:

Attribute
custom.property1
custom.property3
*.company.*     

@robert.bernhard Thank you for detailed explanation. I will share this feedback with our product management team.