Z-push application type content-type of an email
-
Hi @egoitzau ,
that sounds strange. Which version of z-push and Kopano are you using? Are you by chance on Univention?
-
Hi!
2.4.4 and using backend Imap. I see is a decode issue… Sorry Univention?
I think the problem by the way is at Z-push core. In /include/mimeDecode.php at decode(). It does not handle there any application/________ content-type. All works fine if you have a multipart message with boundaries… because that is handled at the code… but not when talking about a mail which is directly a content-type application and where no multipart exists. Was just for knowing if you knew about it (for confirming it is this way) and for trying to implement…
Thanks mate!
-
Forget what said before… I’m tracing the code… it seems something at build_mime_message() … looking…
-
I think the problem is at imap backend in GetMessage in the part if (isset($message->parts) line 1389 more or less (I have entered echos and so…)…
It seems not to be picking the attachment…
It just happens with Android or Nine app… not with iOS Apple mail…
Any help very appreciated
-
Hi mates!!
It seems to be an Android issue… (Gmail app, even Nine)
Can be seen a Content-Type of Application/ms-powerpoint-1.2 as the only content of the mail when using other backends (like Kopano) from the Gmail app of Android?.
If I snoop all the traffic sent between a working mail app and non one… the conversation is exactly the same and the attachments are sent…
Cheers
-
Have made some more investment on this issue. It seems it only happens in Android (not iOS Apple mail or Nine, not Outlook in Windows) and with Gmail app or Nine… both fail. It seems to be something of Android. I have checked the live traffic and compare the ios with the Android traffic and can say the attachment is sen’t by Z-Push to Android or iOS the same way (and the traffic in headers, attachment end and so… seems exactly the same… or very very similar)… even I have tried disabling provisioning (for seeing if it could help). No way…
Has anyone ever suffered something like this?. I could send the email to some email address you give me in order to try to see if this is a Z-push issue or the backend one…
Any option (although have not seen) been able to be modified in Android?? for some more debugging?. Have even tried a Virtualbox x86 Android machine with 8.1 but no way too…
Anyone who could give me a hand please?.
Cheers!
-
It is possible that this is an issue with the mime parser as suggested in one of your first posts. There are several different ways an email can be synchornized via ActiveSync, e.g. iOS doesn’t care much about the parsed and transmitted fields in the standard sync. These are just used for displaying the mail list. When you visualize the entire mail the full rfc822 is requested and parsed on the phone.
@egoitzau said in Z-push application type content-type of an email:
I think the problem by the way is at Z-push core. In /include/mimeDecode.php at decode(). It does not handle there any application/________ content-type. All works fine if you have a multipart message with boundaries… because that is handled at the code… but not when talking about a mail which is directly a content-type application and where no multipart exists.
This could be an issue in this library. It’s an external lib used to handle the parsing for the imap backend. You could check if this is handled correctly in newer versions of the lib.
PRs fixing this (or other issues) are welcome.Cheers,
Sebastian -
Hi @Sebastian !
I have the 2.4.5 version… so the most newer one…
we have tried with another ActiveSync server and the same Android phone… and the message is received, although I’m not really sure… about the fact that the server running another different active sync service (Domino Traveler) hasn’t modified nothing on that email… so the situation… perhaps was not exactly the same and for instance the Content-Transfer-Encoding could have become binary instead of base64 in this Domino server.
Going to try to see the problem :) ,
Cheers! -
Anyway Sebastian… if in the conversation between the server (Z-Push) and the clients, Android and iOS, you see same traffic passed do you still think a mime issue could be??. The attachment is being passed properly (seems at least) to both clients…
-
Is needed to say too…
I have had the message in plain text file and the testing env in terms of receiving the email, has been achieved with a sendmail address < file command. So the message being the same and being able to modify it slightly for debugging. I have seen the message, the only way I have been able to received though Z-push in the Android device… is just converting it to multipart but using in one of the parts exactly the same content-type and everything… (just converting to multipart…) :
Previously (not received the attachment) :
Content-Type: application/x-mspowerpoint.12;
name=“JefeDeVentas_USER =?UTF-8?B?R1JBTkFET19tacOpcmNvbGVzLnBwdHg=?=”
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=“JefeDeVentas_USER =?UTF-8?B?R1JBTkFET19tacOpcmNvbGVzLnBwdHg=?=”UEsDBBQAAAAIAEKGKU762tixfgIAAPImAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbM2az3LTMBDG
X8XjKxMrFVAKk6QH4MafzpQXEPbaEdiWRlJC82wceCReAdmhxe0w1Euk0V6cKJL2+0W2vl17/PP7For being able to be received :
–=_1fbabf0ea27176f3edf593172ea16c77
Content-Type: multipart/alternative;
boundary="=_4b38783ca2f1a2cd5225df66845716ad"–=_4b38783ca2f1a2cd5225df66845716ad
Content-Type: application/x-mspowerpoint.12;
name=“JefeDeVentas_USER =?UTF-8?B?R1JBTkFET19tacOpcmNvbGVzLnBwdHg=?=”
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=“JefeDeVentas_USER =?UTF-8?B?R1JBTkFET19tacOpcmNvbGVzLnBwdHg=?=”UEsDBBQAAAAIAEKGKU762tixfgIAAPImAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbM2az3LTMBDG
X8XjKxMrFVAKk6QH4MafzpQXEPbaEdiWRlJC82wceCReAdmhxe0w1Euk0V6cKJL2+0W2vl17/PP7
.
.
.So as far as I have seen the code… getbodyrecursive, just calls several times itself… so one time it works…
it’s so extrange…
-
The only differences I can see in both (Android and IOS) dialogs with the server are :
iOS sends :
Accept-Encoding: gzip, deflate.
Accept-Language: es-es
Accept: /.while Android just sends the first one and as follows :
Accept-Encoding: gzip.Perhaps it could give a clue?
-
iOS requests the full RFC822 message via ActiveSync to parse it
.
Z-Push itself uses external libraries like MimeDecode: https://pear.php.net/package/Mail_mimeDecode
Just checked, we use the latest version, so no fix is to be expected upstream. The issue needs further debugging, most probably within this library. -
Hi @Sebastian !!
By your comments I assume you have been able to reproduce?. If not, I could happily contribute to fix, with an env for reproducing it with even root access…
I will try my bests too to find the problem… but do you really think the issue is there in that library? . Apart from iOS, Outlook is not affected too… and the attachment is properly opened in Outlook (with Excel or Libreoffice) and iOS…
Thanks mate!
-
One question for Z-push gurus…
for a message like I have posted previously… the code should not be entering in GetMessage() in the following conditional ?
// Attachments are also needed for MIME messages if(isset($message->parts)) {I say it… because it seems not to be entering there and perhaps should it enter… but anyway… if the conversations seem to be similar for both devices… shouldn’t Android be doing more or less similar to iOS?. It receives the same data (more or less… but yes…).
-
Anyone could provide us some new clue please :) ?
-
@Sebastian when you told your point of view, was due you you reproduced it?.
