Closed Bug 321105 Opened 19 years ago Closed 16 years ago

Attachments appear in message body using when reading messages using MAPI

Categories

(Thunderbird :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: eetasoft, Unassigned)

Details

(Whiteboard: closeme 2008-09-04)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: version 1.0.7 (20050923)

When I get messages using MAPI client in FoxPro, attachment count is zero.
Message body contains attachments in encoded form. Thus it is not possible to get attached file exact contents easily. This problem does not occur when Outlook Express is MAPI client

Reproducible: Always

Steps to Reproduce:
1. Place unread a message with attached file to Inbox
2. Run the following code in Microsoft Visual FoxPro (probably occurs with other MAPI client also):

local oMAPI, vmess
oMAPI = newobject( 'cusMAPI','mapimail.vcx' )
vmess =oMAPI.ReadMail( '', '', .t., '', '' )
if m.vmess< 1
  messagebox('no msg')
  RETURN
  endif

oMAPI.GetFirstMessage()
cResult = subs( oMAPI.GetSubject(), len('#xxxx#')+1 )
? oMAPI.GetSubject()
? omapi.getbodytext()

oMAPI.GetAttachmentCount()
MESSAGEBOX( ' attachment count ' + TRANSFORM(oMAPI.GetAttachmentCount() ) )

This code uses free MAPIMAIL class from http://nbcsoftware.nbcwebservices.com/download/Freeware/mapimail.zip
Actual Results:  
1. Message body contains also attached file.
2. "attachment count 0" message will appear.

Expected Results:  
Attached file cannot be inside message body.

"attachment count 1" message must appear.
I think you need to contact the developers of the MAPIMAIL class.  They can then pass this upstream to mozilla if there is a problem.
MAPIMAIL is very simple open source wrapper to MSMAPI OLE control (few lines on Foxpro source code). It is used only for repro creation. I can create repro without using MAPIMAIL class at all.

The issue is that it is not possible to read attached files using Thunderbird MAPI implementation (messages appear in unencoded form in message body, MAPI attachment count is zero). This does not depend on the MAPIMAIL class.
If you need I can create executable file which reproduces this and upload it somewhere.
Could reproduce this issue with SM 1.1 and C language sample "simple.cli" from old Win32 Platform SDK:

Reproducible: Always

Steps to Reproduce:
1. Open MAPI session with MAPILogon()
2. Call MAPIReadMail(hSession, hWnd, msgid, 0, 0, &pMsg) with the msgid of some existing large message with at least one attached file.
3. Examine returned message structure.

Actual Results:
pMsg->nFileCount and pMsg->lpFiles are 0.
The raw mail text including MIME headers appears in pMsg->lpszNoteText
This text is truncated to ~64K.

Expected Results:
Attachments should appear as temp files with names in pMsg->lpFiles.
At least, message should not be truncated.


According to ConvertBodyToMapiFormat(), the message truncation is intentional for some reason:-)
http://lxr.mozilla.org/seamonkey/source/mailnews/mapi/mapihook/src/msgMapiImp.cpp#746
"... int kBufLen = 64000; // I guess we only return the first 64K of a message."

Attachment handling for MAPIReadMail() is not implemented at all.
The flags MAPI_BODY_AS_FILE and MAPI_SUPPRESS_ATTACH have no effect.

This affects both TB and SM, suggest to change Product/Component to Core/MailNews:Simple MAPI. Related: Meta Bug 108275.
Related: Bug 369401
Reporter, does the issue still occur in the latest supported 2.0.0.x / Shredder trunk nightlies?

(1.5.0.x is now end-of-life and the latest supported 2.0.0.x is 2.0.0.16)
Whiteboard: closeme 2008-09-04
Assignee: mscott → nobody
RESO INCO due to lack of response to last comment. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
We can reproduce the described behavior also in version 10.0.2 of Thunderbird... it is unable to get the attachments while accessing Thunderbird with MAPI
You need to log in before you can comment on or make changes to this bug.