none
properly set transport headers property

    Question

  • I would like to understand the right way to set transport header property to be properly translated into x-header on send and from x-header back into property on receive. The value is unicode wstring, which may be international characters. The following is the code to set the header ...

    	ULONG GetTransportHeadersPropId( IMessagePtr msg, const wstring& prop_name )
    	{
    		if (msg)
    		{
    			try
    			{
    				struct __declspec(uuid("{00020386-0000-0000-C000-000000000046}")) INamedPropDummy;
    				MAPINAMEID namedId;
    				LPMAPINAMEID pID = &namedId;
    				namedId.lpguid = (LPIID)&__uuidof(INamedPropDummy);
    				namedId.ulKind = MNID_STRING;
    				namedId.Kind.lpwstrName = const_cast<LPWSTR>(&prop_name[0]);
    				const int MsgPropsNum = 1;
    				LPSPropTagArray propArray = NULL;
    				HRESULT hr = msg->GetIDsFromNames( 1, &pID, MAPI_CREATE, &propArray );
    				if ( SUCCEEDED(hr) )
    					return PROP_TAG( PT_UNICODE, HIWORD ( propArray->aulPropTag[0] ) );
    			}
    			catch (...)
    			{
    				ATLTRACE( "GetTransportHeadersPropId exception \n" );
    			}
    		}
    		return 0;
    	}
    
    	void SetTransportHeadersProperty( IMessagePtr msg, const wstring& prop_name, const wstring& prop_val )
    	{
    		if (msg)
    		{
    			try
    			{
    				CSetProp prop(1);		
    //				_bstr_t bstr_val(prop_val.c_str());
    				_bstr_t bstr_val(EwSMIMELib::EncodeMIMEString(prop_val).c_str());
    				
    				prop.AddProp( GetTransportHeadersPropId( msg, prop_name ), bstr_val );
    				HRESULT hr = msg->SetProps( prop, prop, NULL );
    			}
    			catch (...)
    			{
    				ATLTRACE( "SetTransportHeadersProperty exception \n" );
    			}
    		}
    	}
    

    In "SetTransportHeadersProperty" function if I set directly wide char string (commented out) x-header on send will get "????" in place of international characters and will work for ASCII. When receiving this e-mail x-header will be translated into property into same value  as x-header contain (in case of international languages - garbage).

    If I MIME encode the value before set (ex: =?UTF-8?B?0J3RgtCy0YvQsCAg0LLRi9C70LDQu9GL0LDQu9GL?=) The value in the property will be encoded and when message sent will be set as is into corresponding x-header, which is what I need. But here comes the questionable part ... When I receive this message with encoded x-header in "PR_TRANSPORT_MESSAGE_HEADERS" this x-header will be translated into corresponding property and this property will has already decoded content of original international string. So the same named transport property may contain MIME encoded content when I set it for sending and decoded content when I receive the message and trying to get the same property. This is weird when Outlook automatically decode the value on receive and doesn't do encoding on send.

    Am I doing something wrong? Thank you! 

     
    Thursday, May 01, 2014 9:15 PM

Answers

  • Hi Slava,

    Most probably you have the add-in installed on both ends. In that case you can encode the value, add it to the header and then decode it back on the other side without relying on the built-in mechanisms. Does it make sense? 

    Friday, May 02, 2014 12:05 PM

All replies

  • Why not skip the "?UTF8?" part? If you know how it is encoded, you can do decoding yourself.

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Friday, May 02, 2014 1:50 AM
  • Hi Slava,

    Most probably you have the add-in installed on both ends. In that case you can encode the value, add it to the header and then decode it back on the other side without relying on the built-in mechanisms. Does it make sense? 

    Friday, May 02, 2014 12:05 PM
  • Thank you Dmitry and Eugene for suggestion to handle value on my own on both receiving and sending part. I will do that, indeed. I just wanted to follow MIME specs and met this behavior.

    It still doesn't explain why Outlook handles properly MIME encoded value of x-header on receive and doesn't try to do that on send when value is UNICODE transport property and will be set as x-header into MIME. Strange, isn't it? Sounds like a bug to me.

    Thanks again guys, I'll mark one of your reply as an answer, they are both suggested the same, probably the only right way to deal with issue. I also would like personally say huge complements to Dmitry  (what Outlook developers can do without OutlookSpy) and Eugene (so much great answers from Outlook expert I used). Best regards.   

    Friday, May 02, 2014 1:45 PM