Named properties in PS_INTERNET_HEADERS don't go back to named properties when recieved.

  • Thread starter Thread starter Vandal
  • Start date Start date
V

Vandal

If I add a named string property to the PS_INTERNET_HEADERS space, I
can see it got a X-header header on the recieved message in
PR_TRANSPORT_MESSAGE_HEADERS.

However the recieved doesn't have a named MAPI property for my X-
header? The goal is I need this X-header property to be presevered on
replys, if it doesn't get made into a MAPI property when recieved then
it will be lost on the reply.

Does anyone know why named properties get created for all the other X-
headers except mine?
 
Are the emails staying within an Exchange organization? If not then I
wouldn't expect the MAPI property to remain, only the x-header. Within an
Exchange organization you shouldn't see the transport headers since the
email never went over the Internet, but the MAPI property should be
preserved.
 
Are the emails staying within an Exchange organization? If not then I
wouldn't expect the MAPI property to remain, only the x-header. Within an
Exchange organization you shouldn't see the transport headers since the
email never went over the Internet, but the MAPI property should be
preserved.
Click to expand...

No, the emails are getting sent over the internet from an Exchange
2003 server to a SendMail server and retrieved via POP3 to an Outlook
2007 client.

Below is the contents of PR_TRANSPORT_MESSAGE_HEADERS on the recieved
email (addressses removed):

Return-Path: <[email protected]>
X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on
xxxxx.xxxxxxxxx.com
X-Spam-Level:
X-Spam-Status: No, score=-2.0 required=8.0
tests=AWL,DK_POLICY_SIGNSOME,
HTML_MESSAGE,KAM_RPTR_PASSED,KAM_RR_NEGATIVE,MIME_HTML_MOSTLY
autolearn=disabled version=3.1.4
Received: from xxxxx.xxxxxxxxx.xxxxxxx (xxxxxx.xxxxx.com
[206.239.6.43])
by xxxxx.xxxxxxxxx.com (8.13.6/8.13.6) with ESMTP id l930otNs030722
for <[email protected]>; Tue, 2 Oct 2007 20:50:56 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C80557.747FF271"
Content-class: urn:content-classes:message
Subject: test
Date: Tue, 2 Oct 2007 20:50:54 -0400
Message-ID:
<[email protected]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: test
Thread-Index: AcgFV3KuHBmCOscPS8O5+ckL8lEqMg==
From: "XXXX XXXX" <[email protected]>
x-teststring: TestString
To: <[email protected]>
X-RelayRegistry-Debug: xxxxx.com.by.206.239.6.43.relayregistry.org
X-RelayRegistry: Passed - verified.relayregistry.org. 600 IN A 0.0.0.0
X-KAM-Reverse: Passed - Reverse DNS of xxxxx.xxxx.com/206.239.6.43
X-Scanned-By: MIMEDefang 2.63 on 63.216.184.8
Status:

In the above I can see my test X-Header named "X-TESTSTRING" made
through Exchange and over the internet successfully. Looking at the
IMessage for the recieved email I can see that Outlook automatically
generated named string properties in the PS_INTERNET_STRINGS space for
all the X-headers shown above except the one I added. The only thing
that looks like it might be a problem is that Exchange converted my
property name to lower case for some reason, it had a property name of
"X-TESTSTRING" when it was added. The issue with this is that email
replies won't carry on my X-Header as expected because there won't be
a PS_INTERNET_STRINGS property generated for it.
 
Why would you expect that an outgoing x-header would be preserved and
maintained by the receiving system on a reply? The recipient would need to
be running Outlook also or some other mail software that can be set to
provide the x-header and so return a reply with that header. You can't
control what happens on the other end.

Case sensitivity in x-headers is not important according to the RFC that
governs that.




Vandal said:
No, the emails are getting sent over the internet from an Exchange
2003 server to a SendMail server and retrieved via POP3 to an Outlook
2007 client.

Below is the contents of PR_TRANSPORT_MESSAGE_HEADERS on the recieved
email (addressses removed):

Return-Path: <[email protected]>
X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on
xxxxx.xxxxxxxxx.com
X-Spam-Level:
X-Spam-Status: No, score=-2.0 required=8.0
tests=AWL,DK_POLICY_SIGNSOME,
HTML_MESSAGE,KAM_RPTR_PASSED,KAM_RR_NEGATIVE,MIME_HTML_MOSTLY
autolearn=disabled version=3.1.4
Received: from xxxxx.xxxxxxxxx.xxxxxxx (xxxxxx.xxxxx.com
[206.239.6.43])
by xxxxx.xxxxxxxxx.com (8.13.6/8.13.6) with ESMTP id l930otNs030722
for <[email protected]>; Tue, 2 Oct 2007 20:50:56 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C80557.747FF271"
Content-class: urn:content-classes:message
Subject: test
Date: Tue, 2 Oct 2007 20:50:54 -0400
Message-ID:
<[email protected]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: test
Thread-Index: AcgFV3KuHBmCOscPS8O5+ckL8lEqMg==
From: "XXXX XXXX" <[email protected]>
x-teststring: TestString
To: <[email protected]>
X-RelayRegistry-Debug: xxxxx.com.by.206.239.6.43.relayregistry.org
X-RelayRegistry: Passed - verified.relayregistry.org. 600 IN A 0.0.0.0
X-KAM-Reverse: Passed - Reverse DNS of xxxxx.xxxx.com/206.239.6.43
X-Scanned-By: MIMEDefang 2.63 on 63.216.184.8
Status:

In the above I can see my test X-Header named "X-TESTSTRING" made
through Exchange and over the internet successfully. Looking at the
IMessage for the recieved email I can see that Outlook automatically
generated named string properties in the PS_INTERNET_STRINGS space for
all the X-headers shown above except the one I added. The only thing
that looks like it might be a problem is that Exchange converted my
property name to lower case for some reason, it had a property name of
"X-TESTSTRING" when it was added. The issue with this is that email
replies won't carry on my X-Header as expected because there won't be
a PS_INTERNET_STRINGS property generated for it.
Click to expand...
 
Back
Top