OL2013 was the first version to support ActiveSync at all.

So in fact we should upgrade to OL2007 or 2010 maybe..
Do you know if in 2007 and 2010 are using smartreply an smartforward 
as default and if there are major issues with ActiveSync?

Thanks!

Not to mention because of (2) we don't know WHICH flag to set.

In order to set the "Answered" flag directly on the IMAP server we 
need to know the folder the original message is in as well as the 
message's UID. We don't know either of these things from the simple 
SENDMAIL command that OL2013 is issuing. All we have is the 
In-Reply-To header - which tells us nothing about about which folder 
the original email is located in. It's possible to search for this 
message on the IMAP server, but since we don't know which folder it's 
in, it is a potentially inefficient operation for little gain (setting 
the Answered or Forwarded flag - something the client should be doing 
on it's own).
Correct. Since the In-Reply-To header is sent in both reply and 
forward operations, we don't know which action was performed. I guess 
parsing the subject could be an option, but as you say, it's not 100% 
reliable since it can be changed...

Agree, but they should try smartreply and smarforward as default..
Well we can't do anything.
I'm not really understanding what you mean..

Think about this test-scenario:

1. I get a message from lets say "client@gmail.com"
   -> message-header:
------------8<----------------------------------------------------------------
Message-ID: 
<CACQS2qqQrAa2QMi=pHRB4Rgn8XZtAhuqCq99LvT-Kp4SbU4LNQ@mail.gmail.com>
------------8<----------------------------------------------------------------

2. I reply to this message from OL2013:
   -> message-header(s):
------------8<----------------------------------------------------------------
References: 
<CACQS2qqQrAa2QMi=pHRB4Rgn8XZtAhuqCq99LvT-Kp4SbU4LNQ@mail.gmail.com>
In-Reply-To: 
<CACQS2qqQrAa2QMi=pHRB4Rgn8XZtAhuqCq99LvT-Kp4SbU4LNQ@mail.gmail.com>
------------8<----------------------------------------------------------------

3. I forward this message from OL2013:
------------8<----------------------------------------------------------------
References: 
<CACQS2qqQrAa2QMi=pHRB4Rgn8XZtAhuqCq99LvT-Kp4SbU4LNQ@mail.gmail.com>
In-Reply-To: 
<CACQS2qqQrAa2QMi=pHRB4Rgn8XZtAhuqCq99LvT-Kp4SbU4LNQ@mail.gmail.com>
------------8<----------------------------------------------------------------

..so the problems in coding would be:
   1. saving the original "Message-ID" vs. "UID"
   2. finding a possibility to distinguish if it's a REPLY or FORWARD 
(parsing the Subject is not OK since it could be changed)

Am I supposing this right?

This one isn't really a fault. The specs don't state that a SMART 
request MUST be used, only that it CAN be used to save bandwidth. The 
SMART request saves bandwidth at the expense of server load (since the 
original IMAP message must be fetched from the IMAP server and parsed).

After looking at this further, though, it's not going to be possible 
to work around this since we have NO way of knowing if it's a reply vs 
a forward, nor do we know the original UID of the original IMAP 
message, or even what folder it's from (so we can't efficiently look 
it up).

These things mean that the log message would be pointless, and we 
couldn't set the IMAP flag either.

..and again it's some Outlook "magic"..

As quoted from Microsoft since EAS 14.0 it is implemented in every 
their software, but it is *NOT* .

Could the "In-Reply-Header" parsing just enabled in code or do you 
have to program it?

Thanks!

This is because OL doesn't send "SMART" replies or forwards, so it's 
not obvious it's a reply. We can sniff out the In-Reply-To header 
though.

..to state more precisely it's just happening when working with 
Outlook 2013, from Android 4.X the replied flag is syncronised! 
(confirmed in webmail).

Hi guys,
not sure if this is a BUG, but I'll post it even though..

Issue: Replied message flags are not synched between OL2013 and 
Android 4.X smartphone..

Since of EAS 14.0 the "Reply state sync" should be run with devices 
capable of this protocoll spec I suppose this should work in my 
environment..

Could you plese confirm this or give me a hint to enable it on my 
installation?

Thanks!