locked
MailFlow Custom Headers RRS feed

  • Question

  • Hello, 

    I need to track specific messages that go through my Exchange Server. I have created a transport rule and have managed to mark those messages adding a custom header (X-MG-OU). The messages are then delivered to users' inbox and I can see the custom header using OWA.

    Those messages are then beeing sent to another e-mail server (non Exchange) and when they go through the send connector, my custom header is beeing stripped out and thus, I can't trace them anymore.

    I have created a custom send connector that mathes those messages and have tried a couple of articles about header firewall permissions but with no luck. I think there's no provissioning for Custom Headers.

    I would appreciate any help!

    Thanks

    Wednesday, May 6, 2020 6:55 PM

All replies

  • Are you sure the send connector is stripping them or the receiving server instead?
    Wednesday, May 6, 2020 7:58 PM
  • Hi,

    I created a message header with mail flow rule in my test environment. I tried to send a message to my Gmail account. The custom header is not removed.

    Here is the transport rule I created:

    When check the message header, the custom header field exists:

    Do you have several sender connectors in your organization? You can use message tracking log to see which sender connector is used:

    Get-TransportService|Get-MessageTrackingLog -MessageSubject <subject> -Sender <sender address> |sort-object Timestamp|fl timestamp,EventID,Source,Recipients,connectorid

    Please use the following command to make sure "Ms-Exch-Send-Headers-Routing" permission is assigned to your sender connector:

    Get-SendConnector <sender connector name> | Get-ADPermission|where {$_.ExtendedRights -like "ms-Exch-Send-Headers-Routing"} |fl User,ExtendedRights

    Here is the settings for my sender connector:

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Thursday, May 7, 2020 6:47 AM
  • @Andy David, Yes, I am sure because when I submit the message using telnet at target server, the header remains untouched.

    Thanks




    Thursday, May 7, 2020 12:50 PM
  • @Lydia Zhou, thanks for your reply!

    I was reproducing the rule as you showed me and indeed the sent emails keep the header I set.

    Though in my case we are not talking about simple outgoing e-mails but about incoming ones that are forwarded to an external E-mail in addition to the local delivery, using mailbox features (Mail Flow / Delivery Options / Forward to:)

    So, messages are delivered in an exchange local mailbox and then forwarded to an external email.  The local copy keeps the header applied by the transport rule but it's beeing stripped when sent outside.

    Also, I checked the connector's ExtendedRights settings and they concur to yours.

    Looking forward to your reply.

    Regards

    Thursday, May 7, 2020 1:24 PM
  • Does the transport rule I provided have the same issue when forward messages to external users?

    Does this issue only occur when the original message is sent from external senders? 

    If so, you can try to add the message as an attachment instead of forwarding it directly.

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Friday, May 8, 2020 7:35 AM
  • Hi Lydia Zhou,

    Yes the connector you suggested has the same behaviour. 

    The issue occurs both on internal & external messages.

    The items cannot be forwarded as attachments because it's not support by the Delivery Options functionality.

    Any suggestion?

    Regards

    Friday, May 8, 2020 1:47 PM
  • I test again with "delivery options > Enable forwarding" you mentioned in my environment. The custom message header still exists:

    According to the different results, the message header may be removed by some agent or anti-spam software. Please check if you have any third-party software in your organization, which can scan your messages and male some modification. You can disable them temporarily, then test again.

    You also can set to forward to other email address, check if the message header issue is caused by the recipient domain.

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Tuesday, May 12, 2020 6:22 AM
  • Just checking in to see if above information was helpful. If you have any questions or need further help on this issue, please feel free to post back.

    Regards, 

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Monday, May 18, 2020 8:58 AM
  • Dear Lydia,

    Thank you for all your efforts. Though I am really fraustrated and I can't manage to make this function to work... I can't say why it works for you!
    I wanted to avoid any possible inteference from firewalls and proxies between the two systems so I gave it a try on Office365.
    I used the same functionality (delivery options > Enable forwarding) and I have set every incoming message of a specific user to be also forwarded to an @outlook.com email address.
    In addition, I 've created a transport rule to add a custom header on the incoming messages of that particular user.
    Well, the result's that the message in the Office365 mailbox has my custom tag in the header in contrast to the @outlook.com forwarded message where the tag's gone!
    Maybe I should find another profession...
    Any ideas?
    Regards

    Telemachos Koumartzakis

    Sunday, June 7, 2020 6:47 PM
  • The antispam and security configurations of recipient's organization may also modify the message header. If available, try to send messages to different domains to contrast the message header.

    Also, you can just test to send outbound messages directly instead of forwarding to avoid more uncertain factors.

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Tuesday, June 9, 2020 8:35 AM