finally I found the cause of the error. It was in my local setting 
(ending php tag)

I extended the test script to:

<?php

require_once('lib/Application.php');

    $conf['cookie']['path'] = '/Microsoft-Server-ActiveSync';
     $serverType = 'ActiveSync';
     $nocompress = true;
     $session_control = 'none';
     $cache_control = 'private';

Horde_Registry::appInit('horde', array(
     'authentication' => 'none',
     'nocompress' => $nocompress,
     'session_control' => $session_control,
     'session_cache_limiter' => $cache_control
));

header('Content-Length: 451');
header('Content-Type: application/vnd.ms-sync.wbxml');
echo file_get_contents('/tmp/ob_data.txt');

?>

-------------------------

Now I can reproduce this bug in my system. If I uncomment the 
Horde_Registry::appInit stuff, the wbxml content is good. If I use 
Horde_Registry::appInit then I get ONE extra linefeed in the beginning 
of the wbxml content.

I made a simple test.php:

header('Content-Type: application/vnd.ms-sync.wbxml');
print(chr(0x03));


in the tcpdump file there is no linefeed char at the beginning of the 
wbxml content, but if I put a return; after a 
$this->_encoder->StartWBXML(); in the FolderSync.php I get the extra 
linefeeds.


I suspect the key is in the http header fields.

No I didn't do that.

Then what is your opinion?

No, as I seriously doubt your issue  is due to a setting or configuration.

Do you have any idea, how can I figure out what setting is wrong?

You didn't by any chance edit some horde files and accidentally add 
some line feeds to the beginning of the file (before the opening <?php 
tag) did you?

Then this means that the "extra" 0x0a is not coming from the 
Horde_ActiveSync library, but some other part of the webserver 
response.  The only difference what you did makes is that your 
temporary file will contain *only* what is sent from the code in 
Horde_ActiveSync, while your tcpdump contains *everything* that is 
sent as part of the http response.

I just changed the 
framework/Core/lib/Horde/Core/Factory/ActiveSyncServer.php file.
I changed the 13. line from new 
Horde_ActiveSync_Wbxml_Encoder(fopen('php://output', 'w+')) to
new Horde_ActiveSync_Wbxml_Encoder(fopen('/tmp/xbxml.txt', 'w+')) and 
checked the file. It doesn't have the two 0x0a in the beginning. I 
assume this is because of the "php://output" fopen option. Maybe some 
php.ini setting?

Umm yes. Sorry. I already fixed this config issue. I put a fresh 
syslog to http://proxy.madalbal.hu/syslog.txt

I won't be able to view this until I get back home. In the meantime, 
your horde.log contains the following error, so I'm not really sure 
where the activesync logs you gave me were from since according to 
this, your server was unable to create them.:

Jun 17 11:15:46 test HORDE: [horde] PHP ERROR: 
fopen(/tmp/activesync.log/androidc1096662271.txt): failed to open 
stream: Nincs ilyen fájl vagy könyvtár [pid 6938 on line 41 of 
"/usr/local/src/horde/framework/Core/lib/Horde/Core/ActiveSync/Logger/Factory.php"]
Jun 17 11:15:46 test HORDE: 1. Horde_Rpc_ActiveSync->getResponse() 
/usr/local/src/horde/horde/rpc.php:156 2. 
Horde_ActiveSync->handleRequest() 
/usr/local/src/horde/framework/Rpc/lib/Horde/Rpc/ActiveSync.php:141 3. 
Horde_ActiveSync->_setLogger() 
/usr/local/src/horde/framework/ActiveSync/lib/Horde/ActiveSync.php:549 
4. Horde_Core_ActiveSync_Logger_Factory->create() 
/usr/local/src/horde/framework/ActiveSync/lib/Horde/ActiveSync.php:498 
5. fopen() 
/usr/local/src/horde/framework/Core/lib/Horde/Core/ActiveSync/Logger/Factory.php:41 6. 
Horde_ErrorHandler::errorHandler()

No. After the CR/LF. Please check the log file with wireshark. You will see.

What you are seeing are the CR/LF after the HTTP response headers. 
This is normal.

tcpdump log: http://proxy.madalbal.hu/sync.log
ActiveSync logs: http://proxy.madalbal.hu/activesync.tar.bz2

You can see that after a Cmd=FolderSync request, the rpc.php sends WBXML
content starting with two hexa 0x0a. It should be the version number 
of the actual
WBXML but it's two newline char. After that begins the real WBXML content.