Re: [Evolution] Backup Evolution Data .. only works for "On This Computer"?

On Tue, 2015-10-20 at 14:33 +0200, Milan Crha wrote:
On Tue, 2015-10-20 at 10:56 +0000, Joakim Tjernlund wrote:
<m:MessageText>MIME content conversion failed.</m:MessageText>

Do you know the folder this failed on? I can give you a curl

I have found a few mail(s) that yields this error and looking at them
in webmail I can see a PGP signature in an attachment that I suspect
has the wrong/no MIME type.
How can I see more?
I guess evo has a conversion problem with the signature and aborts
the whole mail.

it's not the evolution-ews, but the Exchange server having problem
convert the message into the MIME version. I mean, the error above is
returned by the server, after the evolution-ews requested the server to
return the message as its MIME version, not as a set of properties.

Some versions of the Exchange server support only S/MIME, not PGP,
which sort of explains the issue.

I am pretty sure it is an "bad" MIME type from earlier mail conversions from
our earlier mail system.
However, does evo need to fail the whole mail due to one bad MIME type in an
attachment? I would be happy to have an attachment with a "bad" MIME type or
loosing the bad attachment.
In webmail this attachment is just a plain text document.

Either way, evo should just skip a "bad" mail during copy and not abort the
whole copy operation. Is that feasible to do ?

I tried to copy couple PGP messages into an Exchange 2007 server (using
evolution-ews) and it garbles the messages which are encrypted, not
those signed only. I tried the same messages with an Exchange 2013
server and it works fine there, all the messages look the same as in
their source directory.

I do not know how much the actual result depends on the method the
message was received (either by copying, as in my case, or by a SMTP,
like probably in your case), but I cannot try the encrypted messages, I
do not have the right GPG key.

Thinking of it, the curl command I offered you to provide will not
help, it will return the same error, thus the only way to correct this
is to fallback to "construct message from properties on the client

Would it be possible to see what the bad MIME type is? Then one could
add this type manually to the Exchange server


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]