Blank Email in Preview Pane

Hello,
I'm running RHEL4 and the Network Edition. I installed the Outlook connector and have noticed on a few emails the message body is blank in the preview pane. However, if I login and view the email the message body appears just fine. Any thoughts?
Thanks

Also does anyone know if the 4.5 version of Zimbra will fully support calendar/contact sharing in Outlook? Most of my users use Outlook 2000/2002 and some 2003 so this is going to be quite an issue. And the AJAX web browser GUI , although very nice, is memory and CPU intensive in IE or FF.

In version 4.0.3 there was a bug where if there was an error while downloading a message, the side effect would be a blank message in your inbox. Can you consistantly reproduce the behavior? If so, enable logging and inspect it to see if any messages fail to be downloaded (you should see an error message right after the message contents).

4.5 is slated for full delegate access (sharing contacts, calendar, mail, and managing someone elses calendar).

How do I enabled logging once the ZCS Connector has been installed? I do recall seeing a logging option available during the installer. I look through Outlook-->Options--> Com Add-Ins for some options but didn't find any pertaining to logging of the ZCS Module.
Thanks again

It's the Outlook logging you need to enable.

Thanks phoenix,
I forwarded myself the email that shows up blank in my Outlook via the web mail Gui. I then opened outlook and downloaded the message and closed outlook. The forwarded message didn't appear in the preview pane either.

Sam here is the output of the log file.

2006.11.14 10:42:46 <<<< Logging Started (level is LTF_TRACE) >>>>
2006.11.14 10:42:46 Zimbra Collabration Server: Synch operation started (flags = 00000031)
2006.11.14 10:42:46 Zimbra Collabration Server: StartImport(flags = 00000000, max msg = ffffffff): full items
2006.11.14 10:42:46 Zimbra Collabration Server: UploadItems: 0 messages to send
2006.11.14 10:42:47 Starting the Spooling Cycle
2006.11.14 10:42:47 MAPI XP Call: FlushQueues, hr = 0x00000000, ulFlushFlags = 0x0000001c
2006.11.14 10:42:47 Starting the Simplified Transfer Cycle
2006.11.14 10:42:47 FINISHED MAPI TASK
2006.11.14 10:42:47 Zimbra Collabration Server: ReportStatus: RSF_COMPLETED, hr = 0x00000000
2006.11.14 10:42:47 EXECUTING EndSession MAPI TASK
2006.11.14 10:42:47 Starting the Simplified Transfer Cycle
2006.11.14 10:42:47 Finishing the Spooling Cycle, Error code = 0x00000000
2006.11.14 10:42:47 FINISHED MAPI TASK
2006.11.14 10:42:47 Zimbra Collabration Server: ReportStatus: RSF_COMPLETED, hr = 0x00000000
2006.11.14 10:42:47 Zimbra Collabration Server: Synch operation completed
2006.11.14 10:44:27 Zimbra Collabration Server: Synch operation started (flags = 00000031)
2006.11.14 10:44:27 Zimbra Collabration Server: StartImport(flags = 00000000, max msg = ffffffff): full items
2006.11.14 10:44:27 Zimbra Collabration Server: UploadItems: 0 messages to send
2006.11.14 10:44:27 Starting the Spooling Cycle
2006.11.14 10:44:27 MAPI XP Call: FlushQueues, hr = 0x00000000, ulFlushFlags = 0x0000001c
2006.11.14 10:44:27 Starting the Simplified Transfer Cycle
2006.11.14 10:44:27 FINISHED MAPI TASK
2006.11.14 10:44:27 Zimbra Collabration Server: ReportStatus: RSF_COMPLETED, hr = 0x00000000
2006.11.14 10:44:27 EXECUTING EndSession MAPI TASK
2006.11.14 10:44:28 Starting the Simplified Transfer Cycle
2006.11.14 10:44:28 Finishing the Spooling Cycle, Error code = 0x00000000
2006.11.14 10:44:28 FINISHED MAPI TASK
2006.11.14 10:44:28 Zimbra Collabration Server: ReportStatus: RSF_COMPLETED, hr = 0x00000000
2006.11.14 10:44:28 Zimbra Collabration Server: Synch operation completed
2006.11.14 10:44:37 Zimbra Collabration Server: Synch operation started (flags = 00000001)
2006.11.14 10:44:37 Zimbra Collabration Server: UploadItems: 1 messages to send
2006.11.14 10:44:37 EXECUTING Put MAPI TASK
2006.11.14 10:44:37 Starting the Spooling Cycle
2006.11.14 10:44:37 MAPI XP Call: FlushQueues, hr = 0x00000000, ulFlushFlags = 0x0000001a
2006.11.14 10:44:37 Starting the Simplified Transfer Cycle
2006.11.14 10:44:37 Sending one message
2006.11.14 10:44:37 Progress: Sending message 'FW: [001 #ABT-81217-938]: DNS Request' (size 4.04 KBytes)
2006.11.14 10:44:39 MAPI XP Call: SubmitMessage, hr = 0x00000000
2006.11.14 10:44:39 MAPI XP Call: EndMessage, hr = 0x00000000
2006.11.14 10:44:39 Sending done, Error code = 0x00000000
2006.11.14 10:44:39 FINISHED MAPI TASK
2006.11.14 10:44:39 Zimbra Collabration Server: ReportStatus: RSF_COMPLETED, hr = 0x00000000
2006.11.14 10:44:39 Zimbra Collabration Server: Synch operation completed
2006.11.14 10:44:58 Zimbra Collabration Server: Synch operation started (flags = 00000031)
2006.11.14 10:44:58 Zimbra Collabration Server: StartImport(flags = 00000000, max msg = ffffffff): full items
2006.11.14 10:44:58 Zimbra Collabration Server: UploadItems: 0 messages to send
2006.11.14 10:44:58 Starting the Spooling Cycle
2006.11.14 10:44:58 MAPI XP Call: FlushQueues, hr = 0x00000000, ulFlushFlags = 0x0000001c
2006.11.14 10:44:58 Starting the Simplified Transfer Cycle
2006.11.14 10:44:58 FINISHED MAPI TASK
2006.11.14 10:44:58 Zimbra Collabration Server: ReportStatus: RSF_COMPLETED, hr = 0x00000000
2006.11.14 10:44:58 EXECUTING EndSession MAPI TASK
2006.11.14 10:44:59 Starting the Simplified Transfer Cycle
2006.11.14 10:44:59 Finishing the Spooling Cycle, Error code = 0x00000000
2006.11.14 10:44:59 FINISHED MAPI TASK
2006.11.14 10:44:59 Zimbra Collabration Server: ReportStatus: RSF_COMPLETED, hr = 0x00000000
2006.11.14 10:44:59 Zimbra Collabration Server: Synch operation completed
2006.11.14 10:45:00 Resource manager terminated

Of course, I should have given you this link for enabling logging in Outlook. I always forget that one. :o I'm not sure if it provides any more detail/info than you've already got as I'm not an outlook user.

yup, indeed we want the ZCO logs which can be enabled with ZcoLogCtl as describe here

http://wiki.zimbra.com/index.php?tit...ooting_Options

Hello,

We're noticing a very critical problem today, where a user is getting "attachments" (It's in quotes for a reason -- I'll explain in a minute) and while the paperclip icon appears in the index view of the Inbox, there is no link when viewing the e-mail, nor anything in the body of the message.

What I noticed in the "show original" view is that the message itself has a content-type of "application/pdf" rather than "multipart/mixed" as I'd expect to see with an "attachment." So, after all the SMTP headers, where the body of the message should start, there begins the base64 encoding without any use of boundaries as in a multipart/mixed e-mail. Zimbra somehow cannot view this e-mail, nor offer an interface for the user to view the attachment. I tried some things like having the user forward the e-mail in-line, and as an attachment, and in the latter test, I'd get an attachment link that would open up an exact duplicate of the previous window. (I had 3 or 4 windows that I could have kept replicating, had I been bored enough. :)

My questions are:

1. Are these e-mails violating any SMTP standards?

2. How the heck are these people sending e-mails this way? I can't seem to duplicate this method of sending a file...

I could send someone at Zimbra (via e-mail) the source of one of the e-mails, but I'd rather not post it in the forums.

--Brian

p.s. We're running ZCS Enterprise 4.0.4 on CentOS 4.4. I logged the user in/out, used shift-reload, Duplicated the symptoms in both Internet Explorer and Firefox, deleted their session cookies before a shift-reload/login, etc. One thing to note, is that Lotus Notes 5.0.12 is the MX for this domain, and is configured to forward users' e-mails to Zimbra for those who have been migrated to Zimbra. (btw, Lotus Notes is "...not go[ing] quietly into the night.") The more I try to migrate people from Lotus Notes, the more I hate it. Now, with this latest Zimbra funkiness, it hurts our credibility on how moving to Zimbra is a "good" thing. I believe zimbra is a good thing, but we don't need end-users starting to question the new system.

edit: Oops, I just now realized this was in the "Outlook Connector" section. (I replied thorugh a list of search hits on "blank body") Obviously, if you got this far down the post, it has nothing to do with the Outlook Connector. Sorry about that.

Quote:

---

Originally Posted by bjared

What I noticed in the "show original" view is that the message itself has a content-type of "application/pdf" rather than "multipart/mixed" as I'd expect to see with an "attachment." So, after all the SMTP headers, where the body of the message should start, there begins the base64 encoding without any use of boundaries as in a multipart/mixed e-mail. Zimbra somehow cannot view this e-mail, nor offer an interface for the user to view the attachment.

---

The emails are valid, though the only MUA I've seen that promotes message attachments to the top level in that manner is the one (gnus?) that runs inside of emacs.

This bug is fixed in 4.5. If you download the beta from sourceforge, you'll be able to verify this for yourself. 4.5 is expected to be released in non-beta mode in January.

Quote:

---

Originally Posted by dkarp

This bug is fixed in 4.5. If you download the beta from sourceforge, you'll be able to verify this for yourself. 4.5 is expected to be released in non-beta mode in January.

---

Actually, I take that back. If your messages had a

Code:

---

Content-Disposition: attachment; filename="whatever.pdf"

---

MIME header, they'd be displayed properly. (This was bug 689.) Without an accurate Content-Disposition header, the client isn't sure what to do with the file.

I'd suggest filing this as a bug in bugzilla.