Error handling TNEF object (Archiver and Outlook)
Posted: Fri Apr 07, 2006 9:33 am
Directly after my Scalix 10.0.1 upgrade last night on my home test machine, I found an interesting problem. I was trying to look at the properties of a email in Outlook that looked a bit funny (wrong timestamp), and got the following error:
The fact that this worked for all other emails in my mailbox indicated a problem with the message. I looked at the Scalix log and found the following:
The message was stuck in the Archiver Error Queue. If I used omqdump to examine the message I got
Up till now I've had the setting ARCH_TNEF_ENCODE set to TRUE in my general.cfg. I tested this by setting this to FALSE and re-submitting the message to the Archiver, and it archived it fine this time.
I later on got another message from the same person on the same mailing list, and this one works without an issue. This is obviously a problem with the specific message (maybe it got mangled along the way, or the server sending it out made a mistake).
My questions:
1) Is there any good reason to store the TNEF attachments in a mail archive? I thought I'd do it for completeness sake.
2) Would it be possible for Scalix to strip off a faulty TNEF attachment before it causes a problem deeper in a client/some other server component? Is this even a good idea, or am I looking in the wrong spot?
The .DLL file for the information service could not be found.
MAPI was unable to load the information service PSTPRX.DLL. Be sure the service is correctly installed and configured.
The fact that this worked for all other emails in my mailbox indicated a problem with the message. I looked at the Scalix log and found the following:
ERROR Archiver (Archiver ) 04.06.06
20:00:48
[OM.UX 1169] TNEF gateway: MAPI attachment level properties not found in
TNEF st
ream.
WARNING Archiver (Archiver ) 04.06.06
20:00:48
[OM.UX 1531] Error in decoding file
-> tnef_AddMAPIPropsData
<- tnef_AddMAPIPropsData
<- tnef_AddMAPIPropsAttribute
-> tnef_AddMAPIPropsAttribute
-> tnef_Checksum
<- tnef_Checksum
-> tnef_Checksum
<- tnef_Checksum
-> tnef_AddMAPIPropsData
<- tnef_AddMAPIPropsData
<- tnef_AddMAPIPropsAttribute
-> tf_ReadRecord
<- tf_ReadRecord:NO
-> tnef_getPastRendData
<- tnef_getPastRendData
<- /build/10.0.1.3/src/lib/tnef/tnef_encode.c:686[102,1531]
The message was stuck in the Archiver Error Queue. If I used omqdump to examine the message I got
Msg File = ~/data/000002e/000v2mg
Access Count = 1
TF File = ~/data/000002e/000v2lf
Priority = Normal
TF Info Flags = 0
Filter Route =
Attach File #1 = ~/data/000002f/000v2mh
Attach File #2 = ~/data/000002f/000v2mi
Attach File #3 = ~/data/000002f/000v2mj
HEADER (DN) 3 0 0 0 0x8400 0x1 0 0x0 0x0 0x0 0x0 0x0 "\
multipart/mixed;boundary=\"----=_NextPart_000_0014_01C65A6A.1A833F00\""
CREATE_DATE (DN) 2006/4/7 09:38.38+480
MSG_INT_ID (DN) 0 "AJEHJACFPNAEAKCDDDBCCEIPCBAA.giovanni(u)brillantes\
(a)sandz.com" "AJEHJACFPNAEAKCDDDBCCEIPCBAA.<SNIPPED>"
SUBJECT (DN) "[linux-lvm] error in compiling lvm module" "" "IA5"\
"" ""
CREATOR (DN) 0 0 0 0 0 0 "S=linux-lvm-bounces/OU1=internet/OU\
2=tnef/DDT1=RFC-822/DDV1=linux-lvm-bounces@redhat.com/INTERNET-ADDR=linux-lvm-\
bounces@redhat.com" "" ""
P2_ORIGINATOR (DN) 0 0 0 0 0 0 "S=<SNIPPED>/OU1=internet/\
OU2=tnef/DDT1=RFC-822/DDV1=<SNIPPED>" "" ""
MSG_OBJECT_FILE (DN) 3146 0 "inetMessageHeader"
MSG_OBJECT_DATA (DN) 0x1 1 0 <hex data not displayed>
MSG_CLASS (DN) "IPM.Note"
MSG_OBJECT_FILE (DN) 1139 0 "MAPI.ObjectProperties"
MSG_OBJECT_DATA (DN) 0x1 1 0 <hex data not displayed>
MSG_MAPI_PROPS_INFO (DN) 0 1 0 884
MSG_MAPI_PROPS_DATA (DN) 0x1 1 0 <hex data not displayed>
MSG_MAPI_USER_PROPS_INFO (DN) 0 0 0 45
MSG_MAPI_USER_PROPS_DATA (DN) 0x1 1 0 <hex data not displayed>
CONTENT_FILE (DN) 1166 1166 0x2 -1 0 "[linux-lvm] error in compilin\
g lvm module" "" "" "" "" "IA5" "" "" "" ""
CONTENT_FILE (DN) 1167 1167 0x0 -1 0 "[linux-lvm] error in compilin\
g lvm module" "" "" "ISO8859_1" "" "" "" "" "" "" "" "" "text/plai\
n;charset=\"iso-8859-1\"" "" "" ""
CONTENT_OBJECT_FILE (DN) 83 0 "inetContentHeader"
CONTENT_OBJECT_DATA (DN) 0x1 1 0 <hex data not displayed>
CONTENT_FILE (DN) 1167 1167 0x0 -1 0 "[linux-lvm] error in compilin\
g lvm module" "" "" "IA5" "" "" "" "" "" "" "" "" "text/plain; cha\
rset=\"us-ascii\"" "inline" "" ""
CONTENT_OBJECT_FILE (DN) 127 0 "inetContentHeader"
CONTENT_OBJECT_DATA (DN) 0x1 1 0 <hex data not displayed>
RECIPIENT (DN) 0x60 0 1 "" "" "<SNIPPED>"
****
Up till now I've had the setting ARCH_TNEF_ENCODE set to TRUE in my general.cfg. I tested this by setting this to FALSE and re-submitting the message to the Archiver, and it archived it fine this time.
I later on got another message from the same person on the same mailing list, and this one works without an issue. This is obviously a problem with the specific message (maybe it got mangled along the way, or the server sending it out made a mistake).
My questions:
1) Is there any good reason to store the TNEF attachments in a mail archive? I thought I'd do it for completeness sake.
2) Would it be possible for Scalix to strip off a faulty TNEF attachment before it causes a problem deeper in a client/some other server component? Is this even a good idea, or am I looking in the wrong spot?