Z-push application type content-type of an email

Sebastian

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

egoitzau

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!

egoitzau

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…

egoitzau

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/PP7

For 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…

egoitzau

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?

Sebastian

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.

egoitzau

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!

egoitzau

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…).

egoitzau

Anyone could provide us some new clue please :) ?

egoitzau

@Sebastian when you told your point of view, was due you you reproduced it?.