z-push 2.3.7beta0+43 + kopano 8.3.0-1024 + empty mails
-
We have quite a few of those too on our test server to prepare for migration.
Were able to track some of them down in the zcp 7.2 and zarafa-connector live setup. And for all of those the issue was problems with some of the attachments. They were not openable in Outlook via connector. Or via webapp/deskapp.
Seems to be some new behaviour of Outlook via ActiveSync versus Connector. Via ActiveSync nothing about the mails is displayed at all. Via Connector all the correct data was displayed only the attachments gave error upon trying to open.
Easy way to replicate/test this is change the attachment path to an empty folder. Delete the ost file. Restart kopano and Resync. All mails with attachments will show up as empty mails.
Obviously that “behaviour” should get fixed. No sense in not displaying plenty of usable data just because one attachment is faulty.
Plus a tool that lists or deletes or moves all such messages to a specific folder.
-
Hello and many thanks for your answer!
You put me into the right direction. If a mail has an attachment, but can’t read it the mail will only be displayed with an empty daten and noting else.
In our test installation i did not transfer all the active attachements, too, so all mails with attachments are empty when using z-push connection. If i forward an empty mail including (the missing) attachment to myself i will have another undisplayable mail. If i remove the attachment while forwarding the mail is ok.
Regards an again many thanks for your help.
-
good find
I guess a workaround is better than nothing. But we got 40-ish accounts with maybe a 100’000 mails. Not really practical for us :-/
-
Hello,
i’ve doublechecked it right now. Send a new mail with attachment is ok, after removing attachment the mail is empty. Using zarafaclient all seems to be ok.
As we have about 120 accounts, 80 gb mailboxes, 260.000 mails and more than 400.000 attachments this is only the evidence of the problem, resending without attachment is no solution.
I will open a support ticket for that.
-
@RemoStrotkamp said in z-push 2.3.7beta0+43 + kopano 8.3.0-1024 + empty mails:
Obviously that “behaviour” should get fixed. No sense in not displaying plenty of usable data just because one attachment is faulty.
Yeah, this sounds quite obvious, but it isn’t.
I’ve said it before and I will again: Outlook over ActiveSync is completely different technology! You can’t compare apples to bananas and expect them to taste the same.
Forget what you know about Outlook with the MAPI connector, it does not apply!Outlook (via ActiveSync) requests the full RFC822 message to parse and display it locally. These emls are generated with im2inet (libvmime) and to do this the attachment must be available to be included. If the attachment data is not available im2inet fails (as it can’t generate the eml) and therefore Outlook fails because it doesn’t receive any usable data.
We could look if we could change im2inet behaviour so it still generates an incomplete (and therefore broken) eml if no attachment data is available.
But then still, if you “restore attachments on your server” they will not be magically available in outlook. It would need to be fully resynchronized. -
Hello Sebastian,
thank you for this short explanation. So missing attachment must lead to empty mail.
Regards
-
Can I give my vote to changing im2inet to give back what is available?
-
Quick question: When you do a full backup of your accounts with kopano-backup at loglevel 5 do you as well have a lot of errors of the form:
2017-06-02 12:29:15,943 - backup - ERROR - could not serialize attachment
2017-06-02 12:29:15,944 - backup - ERROR - Traceback (most recent call last):
File “/usr/lib/python2.7/site-packages/kopano/item.py”, line 674, in _dump
msg = att.OpenProperty(PR_ATTACH_DATA_OBJ, IID_IMessage, 0, MAPI_DEFERRED_ERRORS)
File “/usr/lib/python2.7/site-packages/MAPICore.py”, line 407, in OpenProperty
return _MAPICore.IMAPIProp_OpenProperty(self, ulPropTag, USE_IID_FOR_OUTPUT, ulInterfaceOptions, ulFlags)
MAPIErrorNoAccess: MAPI error 80070005 (MAPI_E_NO_ACCESS) -
kopano-backup -O /tmp -l 5
2017-06-02 12:52:29,746 - backup - ERROR - could not serialize attachment
2017-06-02 12:52:29,747 - backup - ERROR - Traceback (most recent call last):
File “/usr/lib/python2.7/dist-packages/kopano/item.py”, line 680, in _dump
data = _utils.stream(att, PR_ATTACH_DATA_BIN)
File “/usr/lib/python2.7/dist-packages/kopano/utils.py”, line 156, in stream
stream = mapiobj.OpenProperty(proptag, IID_IStream, 0, 0)
File “/usr/lib/python2.7/dist-packages/MAPICore.py”, line 294, in OpenProperty
def OpenProperty(self, *args): return _MAPICore.IMAPIProp_OpenProperty(self, *args)
MAPIErrorNotFound: MAPI error 8004010F (MAPI_E_NOT_FOUND) -
thanks a bunch. I have very few of the MAPI_E_NOT_FOUND as well. Most of mine are the MAPI_E_NO_ACCESS types.
I’d be rather surprised if there weren’t significant overlap between the empty mails because of attachments in Outlook via KOE and kopano-backup throwing errors too.
Opened a ticket. I hope I will get them to send me a changed line 686 of item.py so it returns
backup - ERROR - could not serialize attachment: PATH2ATTACHMENT.Path of the problematic attachment would be very useful info to follow the rabit hole.
-
@RemoStrotkamp
A ticket to make im2inet more fault tolerant has been created: https://jira.kopano.io/browse/KC-704
