While testing on our development Domino 6.5.4 server, DAMO 6.5.5 works fine whereby app-specific data embedded into Outlook’s BillingInformation property (via our Outlook add-in) is retained correctly when sent to other Notes users.
However, while testing on our client’s Domino 6.5.4 server, the BillingInformation property appears to be filtered away.
Upon inspecting the Document properties using the Lotus Notes client, it seems that the $MAPIUnmappedProps field (which contains the BillingInformation property?) is missing.
Is it possible that the $MAPIUnmappedProps field is being stripped away by Domino server? Thus causing the BillingInformation property to go missing?
Subject: $MAPIUnmappedProps stripped away by Domino server?
Hi Jarrod,
-
First, DAMO also uses the $MAPIUnmappedProps field. Therefore, it may not be a good idea fro the add-ion to use this same field. Wouldn’t you be able to create your own field? $MAPIUnmappedProps2 for example?
-
Please explain how the process that succeeds differs from the process that fails. When the recipient gets the email, the field is there when (both users? ) on the test server but fails when production environment?
When DAMO is installed it uses an cache ( _.nsf) nsf file. Does this field exist in the Sent folder of the cache? On the Domino server, if you “tell router quit” and trap the email in the mail.box, does the field exist? In other words, where in the process does the field get removed?
Mike
Subject: RE: $MAPIUnmappedProps stripped away by Domino server?
Thanks Mike,
-
When accessing the BillingInformation property in Outlook, DAMO automatically stores this property in the $MAPIUnmappedProps field of the Note. I believe this field contains any set properties in Outlook that does not correspond to any common field in Notes?
-
On the test server, both the sent email and the received email contains the field (and Outlook is able to access the BillingInformation property via DAMO). However, in the production environment, this field is missing in the received email.
-
Unfortunately, I do not have direct access to our client’s production Domino server. In fact, the client themselves also do not have direct access to the server due to the stringent security policies in place.
-
Given the above constraint, at this present moment, I guess what I wish to confirm is whether a Domino server can be configured to strip away unknown/uncommon fields when routing emails, and if so, how is it done? So that I can emulate the conditions in our test environment.
-
Btw, while searching the forum, I stumbled across another post which mentioned the existence of $MAPIUnmappedProps causing problems with Plumtree, and asking if this field can be removed… sort of like the reverse of my situation.
Subject: RE: $MAPIUnmappedProps stripped away by Domino server?
Hi Jarrod,
This is only a suspicion but if you compared the total number of fields in the doc from the test environment to the same doc in the production environment, what do we see? A path to explore is that somewhere, the doc that failed may have hit a max of 256 fields resulting in the $MAPIUnmappedProps fled being stripped out.
I don’t know this for a fact but this is one place we need to look.
NotesPeek and Designer don’t provide an easy way to count the fields in a doc so it is probably necessary to suffer through counting the fields in the doc properties dialog.
Mike
Subject: RE: $MAPIUnmappedProps stripped away by Domino server?
Thanks, I’ve counted about 80 fields - so perhaps there’s some filtering going on at the Domino server end?
Subject: Another place to look …
Hi Jarrod,
Buried deep in the Server’s Configuration Doc (Config doc>>MIME tab>>Advanced tab>>Advanced Outbound Message Options) there is a field which instructs the Domino server to strip out certain fields. Is this the explanation?
Mike