none
Outlook 2013 behavior as an IMAP client

    Question

  • Open Specifications folks:

    Be aware of this thread over in Office IT Pro:
    http://social.technet.microsoft.com/Forums/en-US/officeitpro/thread/e8122c0c-7abd-4d1d-957b-cec5f5a7167f/

    In short, when Outlook 2013 is used as an IMAP client, it *removes* X- mail headers while moving messages between IMAP folders.  It also rewrites a header to identify Outlook as the X-Mailer.  Both of these are extremely undesirable behaviors, may well be against RFCs, and should be corrected post haste.

    Regards,

    Andrew Laurence


    Andrew Laurence

    Wednesday, June 05, 2013 5:20 AM

Answers

  • Hi Anonymous6314613,

    The behavior preserving the information in the header has been ported back to Outlook 2013 and will be publicly available in the near future.

    Thanks, Vilmos

    • Proposed as answer by Ben E. S Wednesday, July 30, 2014 12:06 PM
    • Marked as answer by atlauren Wednesday, July 30, 2014 5:24 PM
    Monday, July 28, 2014 6:32 PM
  • Hi,

    I would like to summarize what we have discussed on this thread. Before doing so, it’s important for me to state more clearly the purpose of this forum.  We discuss both documentation (specification and standards) and implementation here. However, our purpose in doing so, is always to accurately document the current protocols and formats used as well as the current product behavior. It is not the purpose of this forum to change the product behavior.  We do report product behavior deviations and problems but, unless clearly or explicitly documented, usually leave it to the product support channels to follow up with the product development teams for decisions on design and implementation changes.

    Having said that, here are the current states of the topics we’ve discussed:

    1. When Outlook shuffles the trace header fields, it is a violation of the RFC, which states that these header fields MUST NOT be reordered. This anomaly is not documented. There is a report on this, the current plan is that this behavior will be documented.
    2. The RFC states “header fields SHOULD NOT be reordered when a message is transported or transformed”, the same paragraph explicitly explains “It is important to note that the header fields are not guaranteed to be in a particular order. They may appear in any order”. Outlook does not keep the original order; there is a report on this, the current plan is that this behavior will be documented.
    3. The non-standard header fields, e.g. “Delivered-To”, are not preserved. There is no documentation that prescribes what to do with the non-standard header fields, specifically, not starting with “X-“, the assumption on our part (which we understand you do not share) is that the behavior to keep them or delete them is equally valid. Outlook deletes them, the current plan is that this behavior will be documented.

    If you want to change any of the above behavior, please send an email to dochelp and indicate it is for me and I will connect you with the product support team for Outlook to continue the conversation.

    Thanks, Vilmos

    Tuesday, September 09, 2014 5:21 AM
  • Hi Andrew,

    The information you have already sent was adequate to file a bug against Outlook 2013. If you’ll send the relevant part of the Exchange log, I might add some more information to the bug description.

    Thanks, Vilmos

    Thursday, July 25, 2013 8:27 PM

All replies

  • Andrew,

    Thank you for raising this question. One of our engineers will investigate this and follow-up with you soon.

    Regards,

    Edgar

    Wednesday, June 05, 2013 2:58 PM
    Moderator
  • Hi Andrew,

    Thank you for your question. I am the engineer who will be working with you on this issue. I am currently researching the problem and will provide you with an update soon.

    Regards,
    Vilmos Foltenyi - MSFT

    Thursday, June 06, 2013 5:30 PM
  • Hi Andrew,
     
    I reproduced your scenario using  Exchange and Outlook 2013, the
    X-Mailer: Microsoft Outlook 15.0
    remained unchanged. In order to investigate the case you described, I would like to see an unencrypted network capture starting from the session establishment and see how the header, more exactly the ‘X-Mailer’ has been changed. Be sure that the capture doesn’t contain any confidential information; the capture will probably be small enough so you can send it as attachment to ‘dochelp (at) microsoft (dot) com’ and  in the e-mail indicate that it is for me.
     
    Thanks, Vilmos

    Wednesday, June 26, 2013 4:46 PM
  • Hi Vilmos,

    I have verified the source issue reported in the Office IT Pro.  The repro path requires a non-Outlook client, an IMAP server (can be Exchange), and Outlook 2013:

    1] Using the non-Outlook client, send a message to an address on the IMAP server.
    2] Setup Outlook 2013 to use the IMAP server, *as* an IMAP client.  (The bug is in Outlook 2013's IMAP code.)
    3] Using Outlook 2013, view the message's Internet Headers.
    4] Copy the Internet Headers to a text file for comparison.
    5] Using Outlook 2013, MOVE the message to another folder on the IMAP server.
    6] Once again, view the Internet Headers.  Save this set to another text file.

    The headers captured in [4] and [6] are dramatically different.  The move operation in [5] *removes* all the X- and Received headers, and rewrites the X-Mailer header to read "Outlook 15.0".  This is the erroneous behavior.

    In my test just now, the original message was sent with Apple Mail on an OS X computer.  The header as viewed with Outlook 2013 is:
    X-Mailer: Apple Mail (2.1508)

    With Outlook 2013 (connected via IMAP to the mailbox), I moved the message to a folder on the same account.  On viewing the message in the destination folder, the Received and X-headers are *gone*.  The X-Mailer header now reads:
    X-Mailer: Microsoft Outlook 15.0

    I will email these header results into dochelp.  In the meantime, please repro this case.  I think you'll find the same results.

    Thank you,

    Andrew


    Andrew Laurence

    Friday, June 28, 2013 4:58 AM
  • Hi Andrew,

    Thank you for bringing to our attention that Outlook 2013 as IMAP client removes many items during a move operation.

    I’ve submitted a bug report against Outlook 2013.

    Thanks, Vilmos

    Wednesday, July 24, 2013 8:24 PM
  • Hi Vilmos,

    I have not had the opportunity to get an unencrypted wireshark trace, so I appreciate your filing the bug.

    I may be able to get a trace using Exchange's IMAP4 protocol log.  Would that be sufficient?

    -Andrew


    Andrew Laurence

    Wednesday, July 24, 2013 10:53 PM
  • Hi Andrew,

    The information you have already sent was adequate to file a bug against Outlook 2013. If you’ll send the relevant part of the Exchange log, I might add some more information to the bug description.

    Thanks, Vilmos

    Thursday, July 25, 2013 8:27 PM
  • Very good.  I can confirm this is a change in behavior from Outlook 2010 to Outlook 2013.  I depend on this to help fight spam.  When I move messages to the junk folder, I now lose all history ("Received" headers).  Really a problem!
    Wednesday, September 04, 2013 6:56 PM
  • Thank you to all of you, who managed to get a bug report filed :) !

    I tried many times to inform the Outlook Team since Dec, 18th 2012 to report this issue, so I am very happy that Andrew Laurence did find the proper forum :) !

    For what do we need Microsoft Connect (https://connect.microsoft.com), if there is no way to report Office Bugs? MS should make bug reporting easier!

    Friday, September 06, 2013 1:56 PM
  • Hi Robert Richter:

    This forum is for software developers who are using the Open Specification documentation to assist them in developing systems, services, and applications that are interoperable with Microsoft products. The Open Specifications can be found at: http://msdn.microsoft.com/en-us/library/cc203350(PROT.10).aspx.

    For filing Office bugs, you may want to try the following avenues to have a better chance of a bug being filed.

    http://answers.microsoft.com

    http://office.microsoft.com/en-us/suggestions.aspx


    Regards, Obaid Farooqi

    Friday, September 06, 2013 10:48 PM
    Moderator
  • Hi Vilmos,

    thank you for filing this bug.

    Is there a appropriate venue where I can register to be notified when / after this will be fixed?
    (If possible by then: including information what update specifically is required to consume the fix.)

    Thanks, Benjamin

    Monday, November 25, 2013 3:22 PM
  • Hi Benjamin,

    There is no automatic notification mechanism when a bug is fixed, you can ask for the status periodically.
    The bug report, the result of this Forum thread, is still under investigation.

    Thanks, Vilmos
    Wednesday, December 04, 2013 6:18 PM
  • Has there been any progress made on this issue? Users of Outlook 2013 have this problem with our IMAP server (emailtopia Response Manager) and we are anxious for a solution. Hoping a fix has made it into the imminent Office 2013 SP1.

    Thanks.


    Wednesday, February 12, 2014 8:21 PM
  • Hi Mike,

    Thank you for the follow up question. I’m going to gather the current information about the handling the X- mail headers and I’ll post the result here.

    Thanks, Vilmos
    Thursday, February 13, 2014 10:27 PM
  • Hi Mike,

    RFC3501 doesn’t specify whether the experimental, user-defined headers should or shouldn’t be preserved, changed, or deleted when a message is processed by the client, e.g. moved to another folder. Outlook 2013 changed the behavior from its previous version regarding the experimental headers. In a future release of Outlook the experimental X- mail headers will be preserved; it is not decided, yet, that the changed behavior will be back-ported or not.

    Thanks, Vilmos

    Tuesday, February 25, 2014 8:55 PM
  • Why are you talking about X- mail headers? OL2K13 kills all headers, not only X- headers! Maybe, RFC3501 does not talk about X- headers, but show me one client who is replacing all headers during a move to another folder. I don't think that the current behavior is wanted by design, it's just a bug!

    Unfortunately the newly released SP1 does not fix the mail header issue, so I am sure for now that this won't be fixed anymore...

    Tuesday, February 25, 2014 11:13 PM
  • Hi Mike,

    RFC3501 doesn’t specify whether the experimental, user-defined headers should or shouldn’t be preserved, changed, or deleted when a message is processed by the client, e.g. moved to another folder. Outlook 2013 changed the behavior from its previous version regarding the experimental headers. In a future release of Outlook the experimental X- mail headers will be preserved; it is not decided, yet, that the changed behavior will be back-ported or not.

    Thanks, Vilmos

    Hi Vilmos!

    Does that change in client behaviour also include no longer rewriting the X-Mailer from its original value to Outlook 15.0?

    Beyond the application of third party tools using X-* mailheaders, changing and/or removing "Received" as well as "X-Mailer" etc headers does make tracing back client/server issues significantly harder. (When using an MTA somewhere other than Exchange; yes, it happens; yes, it may not be what you wish for. We live in an imperfect world.)

    I am aware, that COPY in RFC 3501 does not specify how headers are specifically handled.
    For some reason, to date all common email clients left this information untouched and preserved it.

    If you contend that "should" and "preserve flags and internal date" only require you to preserve exactly that, I wonder when a new feature will arise to automatically rewrite "Subject" and "To"/"From" as well, given that they are not part of the message body either.

    Please do help us out here: what's your rationale behind throwing away (and rewriting, as with X-Mailer) all data in the header except for a few, that until Outlook 2013 everyone else writing IMAP clients thought worthy enough to preserve?

    Thanks!


    • Edited by Ben E. S Wednesday, February 26, 2014 3:18 PM mixed up name at first, sorry.
    Wednesday, February 26, 2014 3:17 PM
  • Hi Mike,

    RFC3501 doesn’t specify whether the experimental, user-defined headers should or shouldn’t be preserved, changed, or deleted when a message is processed by the client, e.g. moved to another folder. Outlook 2013 changed the behavior from its previous version regarding the experimental headers. In a future release of Outlook the experimental X- mail headers will be preserved; it is not decided, yet, that the changed behavior will be back-ported or not.

    Thanks, Vilmos

    Hello Vilmos,

    The behavior suggests that Outlook 2013 accomplishes the move task with the APPEND command, not COPY.  With COPY the task is executed at the server, optimizing bandwidth; APPEND is a client-task, effectively uploading a *new* copy of the message to the server.

    If this is the case, the issue is two-fold:
    [1] APPEND is a wasteful use of client resources and network bandwidth.
    [2] OL2013's APPEND omits/rewrites prior headers, destroying valuable history.

    Can you confirm that APPEND is used in 2013?

    Thank you,

    Andrew


    Andrew Laurence

    Wednesday, February 26, 2014 6:59 PM
  • Thanks for the reply, Vilmos.

    Like others who have replied, we strongly urge you to reconsider the switch from using COPY to using APPEND, but as long as you are doing it, please keep the message being copied intact. As has been pointed out, it's not just "X-" headers that are being lost. I can't see this as anything other than a fairly serious bug and hope to see the fix for it "back-ported" to 2013 in a upcoming service pack.

    Thursday, February 27, 2014 6:08 PM
  • Hi Robert,

    Please give a list of the headers, which were removed; I’ll check whether the behavior of Outlook 2013 is consistent with the normative provisions defined by RFC3501 and [MS-STANOIMAP]. If you could point to the specific clauses in those documents that specify retaining user-defined (“X-“) headers when moving a message from one folder to another, it would be helpful. I wrote in my previous posting that the current behavior will be changed in a future release of Outlook.

    Hi Ben,

    The details of the headers preservation change are not finalized, yet, the X-Mailer will be preserved as it is. I would not comment on the implementation of the protocol, the purpose of this forum is to discuss the protocol itself, see my closing paragraph.

    Hi Andrew,

    As I wrote before on this forum we discuss the protocol, not its effectiveness. The header handling was discussed before. Please see my closing paragraph below.

    Hi Mike,

    My answer to you is the same as to Robert, see above.

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

    Summary of this thread: Outlook 2013 and its previous versions comply to RFC3501 and its companion [MS-STANOIMAPI] even they behave differently regarding header handling; it is possible because of the too concise wording of RFC3501. Because multiple posters asked for the preservation of the information in the headers I filed a bug against Outlook. The behavior change suggestion in the bug was honored and a future release of Outlook will contain it. It is not decided, yet, that the changed behavior will be back-ported or not, I'll post it when the information is available. For the other, not answered topics the
    http://social.msdn.microsoft.com/Forums/exchange/en-US/home?forum=outlookdev
    forum looks more appropriate.

    Thanks, Vilmos


    Monday, March 03, 2014 11:35 PM
  • Hi,

    We currently have no plans to back port the mentioned change in behavior to Outlook 2013. If you would like to pursue this further, please contact Outlook product support as this is a product request and not specific to the Open Specifications document set. The product support channel for this would be a direct engagement with Microsoft Office Support through either Premier Support or Standard Support .

    Thanks, Vilmos


    Friday, May 30, 2014 3:42 PM
  • I guess there is a good thing Thunderbird is out there. It's sad that something which has "worked" in all previous versions of Outlook and now doesn't work is not considered a bug.  I feel like I've spent bad money.
    Saturday, July 26, 2014 5:32 AM
  • BTW, removing headers makes it hard to track SPAM origins and analyze why a message might have been properly labeled or mislabeled as Junk Email.  This means that Outlook 2013 is actually participating the global proliferation of SPAM by covering up attempts to stop it. 
    Saturday, July 26, 2014 5:44 AM
  • Hi Anonymous6314613,

    The behavior preserving the information in the header has been ported back to Outlook 2013 and will be publicly available in the near future.

    Thanks, Vilmos

    • Proposed as answer by Ben E. S Wednesday, July 30, 2014 12:06 PM
    • Marked as answer by atlauren Wednesday, July 30, 2014 5:24 PM
    Monday, July 28, 2014 6:32 PM
  • Wonderful!  Thank you Vilmos.

    -Andrew


    Andrew Laurence

    Monday, July 28, 2014 6:35 PM
  • That is good news indeed,

    thank you Vilmos!

    Monday, July 28, 2014 8:41 PM
  • Never thought that this would happen after reporting this BUG on 18 Dec 2012(!!) for the very first time: http://social.technet.microsoft.com/Forums/en-US/officeitpro/thread/e8122c0c-7abd-4d1d-957b-cec5f5a7167f/

    Thank you!

    Wednesday, July 30, 2014 6:39 PM
  • Hi Anonymous6314613,

    The behavior preserving the information in the header has been ported back to Outlook 2013 and will be publicly available in the near future.

    Thanks, Vilmos

    Hi Vilmos,

    after installing the updates of yesterday's patch-day, your mentioned header-preserve feature is in action, BUT WTH has written that code???

    The headers are all present as far as I can see, but they are not in the correct order any longer!!

    Is that really too much to ask for to code such a "little thing" in the proper way..?

    Regards,
    Robert

    Wednesday, August 13, 2014 11:32 AM
  • @Robert
    @Vilmos

    I appreciate your efforts and would like to think I understand your motives,
    I'd like to follow up on this issue as well.

    First off, I understand that re-serialization of object models/data (which appears to happen in Outlook 2013 as the full stack of headers is incorporated in some kind of data model) causes the result to be in the order the internal model saves data... which certainly doesn't have to be in the same sequence as the original information.

    This may not be an issue easily worked around without too great an effort, especially given the performance and maintenance considerations the Outlook development team surely has to adhere to.

    All in all, however, I'd like to thank you for not only considering but implementing the original request!
    It definitely made a difference for me: custom solutions that use header information are possible again, even if my clients use Outlook 2013.

    Now my two questions, for each of you:

    @Robert: would you mind providing a detailed example of a full email header before and after Outlook 2013 touched it? I'd greatly appreciate it (especially if it includes more than two "Received: " lines.)

    @Vilmos: if your time permits it, would you mind pointing me to the .msp or KB entry that includes this updated functionality?
    Thanks!

    Beyond that:

    Any more precise header preservation feature request might be better suited for a new discussion, pointing out the exact details that we (Robert?) need. Without such details, guessing what the customer wants is always a very hard - if not impossible - task to achieve. After all, we've come very far and I think this has been one of my best experiences in terms of "they finally fixed something I wouldn't have believed they ever would" at Microsoft.

    Thank you!
    & my regards,
    Benjamin

    Wednesday, August 13, 2014 3:24 PM
  • Echoing Benjamin, I too would very much like to see the KB entry that describes this issue and fix.

    best,

    Andrew


    Andrew Laurence

    Thursday, August 14, 2014 8:11 AM
  • Hi Andrew,

    for the last months I tested after each Patch-Day (2nd Tuesday every month) whether the header-issues are resolved, moving one mail from my inbox to another imap-folder. Every time all headers were lost, only some Outlook internal headers were present. However, after the last Patch-Day, 12 August 2014, I noticed that the headers are preserved. Unfortunaley, not in the correct order as they were in my inbox, i.e. the Return-Path isn't any longer at the top, but somewhere in the midst of the headers, the Received-Headers are not in the correct order, but upside down, etc.

    So, it isn't very useful for me, as my Outlook Add-In expects the headers to be 'untouched' like before in Outlook 2007 and Outlook 2010.

    I also searched the KB entries of the last Patch-Day, but didn't find any notice about the header 'fix'.

    to Vilmos: PLEASE inform MS that the recent 'fix' needs another fix regarding the correct order of the headers.

    Thanks to all involved getting the header-problem fixed...

    Regards,
    Robert.

    Thursday, August 14, 2014 10:00 AM
  • Hi,

    The details of the hotfix can be found here: http://support.microsoft.com/kb/2883074/en-us

    Robert, Benjamin basically answered your posting. The subject of this thread is the preservation of the information in the header, this is done. As Benjamin suggested, please provide an example and describe what order changes have occurred and I’ll check whether is any violation of the documented behavior; e.g. if “Received:” is before “Return-Path:”, it is a problem, but the order change of the “Received:”s is not.

    Thanks, Vilmos

    Saturday, August 16, 2014 7:33 AM
  • This is great news. I hope the issues around this fix are worked out. As far as preserving the order of headers, that should not be difficult. In Java the LinkedHashMap gives you the functionality of speed and preserving iteration order. Without this class a HashMap (dictionary in .net terms?) and a LinkedList working together should work. As this would just require allocating a couple of pointers per header line, there should be very little overhead.

    Please consider this.  Header order is also important.  Spam reports should stay in the order they were added.  This way if two SPAM engines process a message, its possible to see how each one functioned.  It is common for two or even three Spam engines to see a message.  There would be a Spam engine at the sender.  Another at the relay host.  And a final one at the receiving server.   If you also want to count Outlook's own Spam engine there would be a fourth.

    Thanks.

    Sunday, August 17, 2014 4:57 AM
  • Well, crap I spoke too soon......

    As you can see, Outlook is still screwing up the headers once a piece of email is marked as Junk.  All of the Spam Assassin headers are gone.  Can't see why this passed (or failed for that matter.)  Tracing it back to the source server is pointless, because Microsoft has taken the liberty of erasing that information from the email.  I really wish I didn't waste my money on Outlook 2013.  It's basically a downgrade from all previous versions.  The really sad thing is that there are claims on this board that this *very* unwanted behavior has been addressed.  We'll be using something else.  Don't expect me to every update my Office version again.

    As soon as you mark email as junk, there goes all of the historical information, and the ability to trace it back to its source.   

    Return-Path: <EvanCarroll@christfellow.wosburmese.com>

    Reply-To: <Evan.Carroll@christfellow.wosburmese.com>
    From: "Background Investigation" <Evan@christfellow.wosburmese.com>
    To: <xxxx@xxxxxxx.com>
    Subject: All information now online
    Date: Tue, 29 Apr 2014 11:47:16 -0400
    Message-ID: <111.3354.34520140429042949.1451.12624.624.e27830afabb3f9664e116d2d0074d5cf@christfellow.wosburmese.com>
    MIME-Version: 1.0
    Content-Type: text/plain;
    charset="us-ascii"
    Content-Transfer-Encoding: 7bit
    X-Mailer: Microsoft Outlook 15.0
    Thread-Index: AQJtrPuC3Ky14CFU+xDLqM02g3siXw==
    X-OlkEid: 00000000A78E7B53C916C447B25B16C776F5CB00070079DC8CFA24F919479399BEFBAD42571600000000020F000079DC8CFA24F919479399BEFBAD425716000000001BC50000AA0AE526754A98429A5E143E477389D7

    Monday, August 18, 2014 7:30 AM
  • Hi Anonymous6314613,

    The behavior preserving the information in the header has been ported back to Outlook 2013 and will be publicly available in the near future.

    Thanks, Vilmos

    No it has not.  See proof in this thread.
    Monday, August 18, 2014 7:32 AM
  • As someone wanted a proof of scrambled headers with the so-called 'fix' installed, I have taken one mail in my inbox (headers intact) and moved it to another IMAP-Folder (headers scrambled after move).

    So, here we go...

    1. Original Mail in INBOX (Headers OK)

    Return-Path: <hotfix@microsoft.com>
    X-Original-To: duncan@afn-portal.de
    Delivered-To: duncan@afn-portal.de
    Received: from localhost (localhost [127.0.0.1])
    	by columbia.axmail-server.com (Postfix) with ESMTP id 2011027C4087
    	for <duncan@afn-portal.de>; Sun, 18 May 2014 18:45:50 +0200 (CEST)
    Received: from columbia.axmail-server.com ([127.0.0.1])
    	by localhost (columbia.axmail-server.com [127.0.0.1]) (amavisd-new, port 10024)
    	with LMTP id OsDMKzSa2pNP for <duncan@afn-portal.de>;
    	Sun, 18 May 2014 18:45:49 +0200 (CEST)
    Received: from rycon.axmail-server.com (rycon.axmail-server.com [45.125.81.22])
    	by columbia.axmail-server.com (Postfix) with ESMTP id 481B427C401D
    	for <duncan@afn-portal.de>; Sun, 18 May 2014 18:45:49 +0200 (CEST)
    X-Virus-Scanned-axmail-Incoming: A.N.J.A.-VirusScan at rycon.axmail-server.com
    Received: from localhost (localhost [127.0.0.1])
    	by rycon.axmail-server.com (axmail Forwarder, v1.7) with LMTP id f1f10675358f4e76939413546390cb9a
    	for <duncan@afn-portal.de>; Sun, 18 May 2014 18:45:37 +0200
    Received-SPF: Pass (rycon.axmail-server.com: domain of hotfix@microsoft.com
    	designates 131.107.1.44 as permitted sender)
    	receiver=rycon.axmail-server.com; client_ip=131.107.1.44;
    	identity=mailfrom; envelope-from=<hotfix@microsoft.com>;
    Received: from smtp.mssupport.microsoft.com (smtp.mssupport.microsoft.com [131.107.1.44])
    	(using TLS with Cipher: Rc4 (Strength: 128 bit))
    	by rycon.axmail-server.com (axmail ESMTP Service, v1.7) with ESMTP id c1576285a1b94784b00deb7e97a8c740
    	for <duncan@afn-portal.de>; Sun, 18 May 2014 18:45:30 +0200
    Received: from tk5-exhub-e802.partners.extranet.microsoft.com (10.251.58.68)
     by TK5-EXMLT-E801.partners.extranet.microsoft.com (10.251.58.30) with
     Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 18 May 2014 09:44:28 -0700
    Received: from TK5CSHFWS02VM (10.251.201.28) by
     TK5-EXHUB-E802.partners.extranet.microsoft.com (10.251.58.56) with Microsoft
     SMTP Server id 8.1.340.0; Sun, 18 May 2014 09:44:27 -0700
    MIME-Version: 1.0
    From: <hotfix@microsoft.com>
    To: <duncan@afn-portal.de>
    Date: Sun, 18 May 2014 09:44:27 -0700
    Subject: Der von Ihnen angeforderte Link zum Hotfixdownload
    Content-Type: text/plain; charset="utf-8"
    Content-Transfer-Encoding: base64
    Message-ID: <f9383e3f-7936-4092-af87-d3f60baffe3d@tk5-exhub-e802.partners.extranet.microsoft.com>
    X-Originating-IP-axmail-Incoming: 131.107.1.44
    X-Envelope-From-axmail-Incoming: <hotfix@microsoft.com>
    X-OriginalArrivalTime-axmail-Incoming: Sun, 18 May 2014 18:45:30 +0200
    X-Message-ID-axmail-Incoming: c1576285a1b94784b00deb7e97a8c740


    2. Mail after move-operation from INBOX to another IMAP-Folder (Headers CORRPUTED)

    Received: from localhost (localhost [127.0.0.1])
    	by rycon.axmail-server.com (axmail Forwarder, v1.7) with LMTP id f1f10675358f4e76939413546390cb9a
    	for <duncan@afn-portal.de>; Sun, 18 May 2014 18:45:37 +0200
    Received: from rycon.axmail-server.com (rycon.axmail-server.com [45.125.81.22])
    	by columbia.axmail-server.com (Postfix) with ESMTP id 481B427C401D
    	for <duncan@afn-portal.de>; Sun, 18 May 2014 18:45:49 +0200 (CEST)
    Received: from smtp.mssupport.microsoft.com (smtp.mssupport.microsoft.com [131.107.1.44])
    	(using TLS with Cipher: Rc4 (Strength: 128 bit))
    	by rycon.axmail-server.com (axmail ESMTP Service, v1.7) with ESMTP id c1576285a1b94784b00deb7e97a8c740
    	for <duncan@afn-portal.de>; Sun, 18 May 2014 18:45:30 +0200
    Received: from TK5CSHFWS02VM (10.251.201.28) by
     TK5-EXHUB-E802.partners.extranet.microsoft.com (10.251.58.56) with Microsoft
     SMTP Server id 8.1.340.0; Sun, 18 May 2014 09:44:27 -0700
    Received: from tk5-exhub-e802.partners.extranet.microsoft.com (10.251.58.68)
     by TK5-EXMLT-E801.partners.extranet.microsoft.com (10.251.58.30) with
     Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 18 May 2014 09:44:28 -0700
    Received: from columbia.axmail-server.com ([127.0.0.1])
    	by localhost (columbia.axmail-server.com [127.0.0.1]) (amavisd-new, port 10024)
    	with LMTP id OsDMKzSa2pNP for <duncan@afn-portal.de>;
    	Sun, 18 May 2014 18:45:49 +0200 (CEST)
    Received: from localhost (localhost [127.0.0.1])
    	by columbia.axmail-server.com (Postfix) with ESMTP id 2011027C4087
    	for <duncan@afn-portal.de>; Sun, 18 May 2014 18:45:50 +0200 (CEST)
    Return-Path: <hotfix@microsoft.com>
    From: <hotfix@microsoft.com>
    To: <duncan@afn-portal.de>
    Subject: Der von Ihnen angeforderte Link zum Hotfixdownload
    Date: Sun, 18 May 2014 18:44:27 +0200
    Message-ID: <f9383e3f-7936-4092-af87-d3f60baffe3d@tk5-exhub-e802.partners.extranet.microsoft.com>
    MIME-Version: 1.0
    Content-Type: text/plain;
    	charset="utf-8"
    Content-Transfer-Encoding: 8bit
    X-Mailer: Microsoft Outlook 15.0
    X-Original-To: duncan@afn-portal.de
    Thread-Index: AQIbKLJbeVqNkYr4+dz2KT0e3G+0iQ==
    X-Virus-Scanned-axmail-Incoming: A.N.J.A.-VirusScan at rycon.axmail-server.com
    X-Originating-IP-axmail-Incoming: 131.107.1.44
    X-Envelope-From-axmail-Incoming: <hotfix@microsoft.com>
    X-OriginalArrivalTime-axmail-Incoming: Sun, 18 May 2014 18:45:30 +0200
    X-Message-ID-axmail-Incoming: c1576285a1b94784b00deb7e97a8c740


    So, my question again - WTH has coded this 'fix' ??

    Regards,
    Robert.



    Monday, August 18, 2014 1:28 PM
  • Hi,

    The details of the hotfix can be found here: http://support.microsoft.com/kb/2883074/en-us

    Robert, Benjamin basically answered your posting. The subject of this thread is the preservation of the information in the header, this is done. As Benjamin suggested, please provide an example and describe what order changes have occurred and I’ll check whether is any violation of the documented behavior; e.g. if “Received:” is before “Return-Path:”, it is a problem, but the order change of the “Received:”s is not.

    Thanks, Vilmos

    Hi Vilmos,

    please look at my posting above to see my provided information about header-corruption.

    May I ask, WHY the change of the 'Received:' order is OK for you? It's definitely not OK for me and I suppose not OK for 99.99% of the rest of us!

    The Return-Path is now somewhere in the midst of the headers!

    Please remember that the Headers should be left UNTOUCHED - Outlook 2007 and 2010 are working 100% correctly! Why is it so difficult to get OL 2013 working in the same manner? You have the source-code of OL2007/2010, so please look at it and fix OL2013 once and for all -> PLEASE!!

    Regards,
    Robert.

    Monday, August 18, 2014 1:42 PM
  • Hi,

    Anonymous6314613, please present your observation similar to Robert; the original header, what was the operation, and what is the result. You can post or send it to me and I’ll analyze the changes.

    Robert, I would like to categorize the changes in the headers:

    • The “Return-Path:” moved down, after the “Received:”s – problem.
    • The “X-“ headers are scattered in the before move and grouped after move; the order of the “X-“ headers has been kept – not problem.
    • The “Delivered-To:” and “Received-SPT:” were omitted – not problem.
    • The order of “Received:”s changed – problem.
    • Change the order of the other entries – not problem.
    • Adding “X-Mailer:” – not problem.
    • Adding “Thread-Index:” – not problem.

    Please verify the above list and we’ll continue the investigation based on the confirmed list.

    Thanks, Vilmos
    Tuesday, August 19, 2014 8:00 PM
  • Return-Path: <xxxxxxxx@jenstalcup.com>
    X-Original-To: xxxxxxxxx
    Delivered-To: xxxxxxxx
    Received: from mx.mg1.unifiedemail.net (mx.mg1.unifiedemail.net [xxx.xxx.xxx.x])
    	by xxx.xxxxxxxxx.com (Postfix) with ESMTP id CDBF2F401D5
    	for <xxxxx@xxxxxxxxxx.com>; Tue, 19 Aug 2014 18:42:26 -0400 (EDT)
    Received: from vps.jenstalcup.com ([137.175.50.221]) by mx.mg1.unifiedemail.net with MailEnable ESMTP; Tue, 19 Aug 2014 18:42:12 -0400
    DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dkim; d=jenstalcup.com;
     h=Mime-Version:Content-Type:Message-Id:Date:From:To:Subject; i=costco_code@jenstalcup.com;
     bh=eHh0fXhRqCtLs17eTA8aJxWZGJI=;
     b=qGi2uQh3ABn2JLyCLXHw5iw/kfQ2H/WBaKDreMWzoM9spYomTeveG/Mng5vWom8HsouvOqSGivAj
       SB9ZY0dxG4dBHCNtkLssb+/47obs4aej0JssahZLOGNc6+wxRuH8oyCs9s8zTwv/EfqpvxqIdUTy
       SfilG5b836rMBycQvHM=
    Received: by vps.jenstalcup.com id huf99g0001g1 for <xxxxxxx@xxxxxxx.com>; Tue, 19 Aug 2014 22:41:00 +0000 (envelope-from <costco_code-xxxxxxxx.com@jenstalcup.com>)
    Mime-Version: 1.0
    Content-Type: multipart/alternative; boundary="fb90-f2d2-eb6d-a29d-79cd-fddb-dcab-a704"
    Message-Id: <407abacdbddfdc97d92ad6be2d2f09bf.b00fd2477ecb6a37@jenstalcup.com>
    Date: Tue, 19 Aug 2014 22:41:00 +0000
    From: Costco Coupons<costco_code@jenstalcup.com>
    To: xxxxxxxxx@yorknation.com
    Subject: Congratulations on your Costco Survey Reward
    Received-SPF: pass (mx.mg1.unifiedemail.net: domain of jenstalcup.com designates 137.175.50.221 as permitted sender)
    	client-ip=137.175.50.221
    X-ME-Bayesian: 0.000000
    X-Spam-Flag: YES
    X-Spam-Status: Yes, score=7.8 required=5.0 tests=BAYES_99,
    	HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,RDNS_NONE,T_DKIM_INVALID,
    	UNPARSEABLE_RELAY autolearn=no version=3.3.1
    X-Spam-Report: 
    	*  7.0 BAYES_99 BODY: Bayes spam probability is 99 to 100%
    	*      [score: 1.0000]
    	*  0.0 HTML_MESSAGE BODY: HTML included in message
    	*  0.0 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or identical to
    	*       background
    	*  0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
    	*  0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
    	*  0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines
    X-Spam-Level: *******
    X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on xxxxxxxx.com
    
    Original above.  Run a rule which looks for "X-Spam-Flag: Yes" and move to "Junk E-Mail".  Now the header is
    Return-Path: <costco_code-xxxxxxxxxx@jenstalcup.com>
    From: "Costco Coupons" <costco_code@jenstalcup.com>
    To: <xxxxx@xxxxxxxx.com>
    Subject: Congratulations on your Costco Survey Reward
    Date: Tue, 19 Aug 2014 18:41:00 -0400
    Message-ID: <407abacdbddfdc97d92ad6be2d2f09bf.b00fd2477ecb6a37@jenstalcup.com>
    MIME-Version: 1.0
    Content-Type: multipart/alternative;
    	boundary="----=_NextPart_000_0078_01CFBBDE.D15339E0"
    X-Mailer: Microsoft Outlook 15.0
    Thread-Index: AQH/jPVjyEa2afGaET39mGRRY7Sj1A==
    X-OlkEid: 00000000A78E7B53C916C447B25B16C776F5CB00070079DC8CFA24F919479399BEFBAD42571600000000020F000079DC8CFA24F919479399BEFBAD425716000000001BC7000002DF85C34838CA42AE948A8B1E72DD5A

    This is happening on any move out of the inbox.
    WHOOPS!!! Just noticed I'm not on the right version of Outlook 2013, but might as well document the Version: 15.0.4631.1004 behavior.  Will retest after the download.
    Tuesday, August 19, 2014 11:16 PM
  • Hi Anonymous6314613,

    I don't see any reordering in your last posting.

    Thanks, Vilmos
    Wednesday, August 20, 2014 4:59 AM
  • Am I the only one with reordered headers???
    Thursday, August 21, 2014 10:36 AM
  • Am I the only one with reordered headers???

    I did notice the first few headers can be reordered.  It looks like my post is the same email twice, sorry about that.  I saw "received" and "return path" get swapped.
    Friday, August 22, 2014 12:02 AM
  • From INBOX:

    Return-Path: <sports.ge2daobwga2tamzt-xxxxxx=xxxxxx.com@returns.bulk.yahoo.com>
    X-Original-To: xxxxxx@xxxxxx.com
    Delivered-To: xxxxxx@xxxxxx.com
    Received: from mx.mg1.unifiedemail.net (mx.mg1.unifiedemail.net [209.143.130.65])
     by web2.xxxxxx.com (Postfix) with ESMTP id F13DDF401D8
     for <xxxxxx@xxxxxx.com>; Thu, 21 Aug 2014 03:11:36 -0400 (EDT)
    Received: from n13-vm9.bullet.mail.bf1.yahoo.com ([66.196.80.186]) by mx.mg1.unifiedemail.net with MailEnable ESMTP; Thu, 21 Aug 2014 03:11:29 -0400
    DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sports.yahoo.com; s=fa12; t=1408605087; bh=tLtWmvRUskLxGSkp0CSorD/ty3q0OhhfBc0wo0uUBF0=; h=Received:Received:Received:To:From:Reply-To:Subject:Date:Sender:MIME-Version:X-Yahoo-Newman-Property:X-Yahoo-Newman-Id:Content-Type; b=qiRyJ16jGKqab73IYxvZrxBWFvK1RE//+5VIHr5s1Mpn97R1BbRUo89r8ZKQjM5Mz2OFsKzabe0z0zfBgjZ0q4yZl9X2qt7yAwjKqUuqOEMkHsA7lLcAjneMAJRNSHqjaUrVa0/VMwj/R//PsiBgTJ/ae8QHdAvfZVEOHKd42ZE=
    DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=fa12; d=sports.yahoo.com;
     b=a4RsBkI2hS5Zhr1KOwE/h8NEDlcxi4RpWnyKzU2nNmFPezUTrVQWYuI/VO6j9nKSPGvFdtrZ9IyVMhvlznZ+WT4r7cQBaoVAEcNq1karxcbz7ijSGe5MzWF5YI+K7YLZTF5XTKt8jzC7GZ8stHDU7dUE140bFvI7gxHOayjSdUs=;
    Received: from [66.196.81.179] by n13.bullet.mail.bf1.yahoo.com with NNFMP; 21 Aug 2014 07:11:27 -0000
    Received: from [69.147.79.86] by t9.bullet.mail.bf1.yahoo.com with NNFMP; 21 Aug 2014 07:11:27 -0000
    Received: from [127.0.0.1] by fan1281.sports.bf1.yahoo.com with NNFMP; 21 Aug 2014 07:10:33 -0000
    To: xxxxxx@xxxxxx.com
    From: Yahoo Sports <sports-fantasy-replies@sports.yahoo.com>
    Reply-To: Yahoo Sports <sports-fantasy-replies@sports.yahoo.com>
    Subject: Fantasy Auto Racing
    Date: 21 Aug 2014 00:10:33 -0700
    Sender: Yahoo Sports <sports-fantasy-replies@sports.yahoo.com>
    MIME-Version: 1.0
    X-Yahoo-Newman-Property: sports
    X-Yahoo-Newman-Id: nascar_reminders_109513_1408605033
    Content-Type: multipart/alternative; boundary="YYY_MESSAGE_YYY"
    Message-ID: <5BA82468486B49B88E4BD4835CF2A4FA.MAI@mx.mg1.unifiedemail.net>
    Received-SPF: pass (mx.mg1.unifiedemail.net: domain of returns.bulk.yahoo.com designates 66.196.80.186 as permitted sender)
     client-ip=66.196.80.186
    X-ME-Bayesian: 0.000000
    X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD,
     HTML_MESSAGE,RDNS_NONE,T_DKIM_INVALID,T_REMOTE_IMAGE,UNPARSEABLE_RELAY
     autolearn=no version=3.3.1
    X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on web.xxxxxx.com

    After move to trash:

    Received: from n13-vm9.bullet.mail.bf1.yahoo.com ([66.196.80.186]) by mx.mg1.unifiedemail.net with MailEnable ESMTP; Thu, 21 Aug 2014 03:11:29 -0400
    Received: from mx.mg1.unifiedemail.net (mx.mg1.unifiedemail.net [209.143.130.65])
     by web2.xxxxxx.com (Postfix) with ESMTP id F13DDF401D8
     for <xxxxxx@xxxxxx.com>; Thu, 21 Aug 2014 03:11:36 -0400 (EDT)
    Received: from [66.196.81.179] by n13.bullet.mail.bf1.yahoo.com with NNFMP; 21 Aug 2014 07:11:27 -0000
    Received: from [127.0.0.1] by fan1281.sports.bf1.yahoo.com with NNFMP; 21 Aug 2014 07:10:33 -0000
    Received: from [69.147.79.86] by t9.bullet.mail.bf1.yahoo.com with NNFMP; 21 Aug 2014 07:11:27 -0000
    Return-Path: <sports.ge2daobwga2tamzt-xxxxxx=xxxxxx.com@returns.bulk.yahoo.com>
    Reply-To: "Yahoo Sports" <sports-fantasy-replies@sports.yahoo.com>
    From: "Yahoo Sports" <sports-fantasy-replies@sports.yahoo.com>
    To: <xxxxxx@xxxxxx.com>
    Subject: Fantasy Auto Racing
    Date: Thu, 21 Aug 2014 03:10:33 -0400
    Message-ID: <5BA82468486B49B88E4BD4835CF2A4FA.MAI@mx.mg1.unifiedemail.net>
    MIME-Version: 1.0
    Content-Type: multipart/alternative;
     boundary="----=_NextPart_000_0116_01CFBD7B.51B22450"
    X-Mailer: Microsoft Outlook 15.0
    X-Original-To: xxxxxx@xxxxxx.com
    X-ME-Bayesian: 0.000000
    X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD,
     HTML_MESSAGE,RDNS_NONE,T_DKIM_INVALID,T_REMOTE_IMAGE,UNPARSEABLE_RELAY
     autolearn=no version=3.3.1
    X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on web.xxxxxx.com
    X-Yahoo-Newman-Property: sports
    X-Yahoo-Newman-Id: nascar_reminders_109513_1408605033
    Thread-Index: AQLMH3bDzzQeOX/U/sC1oYymATeeVw==
    X-OlkEid: 00000000A78E7B53C916C447B25B16C776F5CB000700C3B68E10F77511CEB4CD00AA00BBB6E600000000000B000079DC8CFA24F919479399BEFBAD4257160000000040190000893A3165844E7348B61A465B1388FBDB
    There are actually a handful missing.  Anything that started with "D," except "date" is gone.


    Friday, August 22, 2014 12:14 AM
  • Hi Anonymous6314613,

    I don't see any reordering in your last posting.

    Thanks, Vilmos

    Deleting the bad post so it won't confuse anyone.
    Friday, August 22, 2014 12:15 AM
  • Hi,

    Based on the submitted material by Robert and Anonymous6314613 I submitted a suggestion for:

    1. The order of “Return-Path:” and “Received:” should be kept.
    2. The order of the “X-“ entries should be kept.

    during moving a message to another folder.

    Thanks, Vilmos

    Sunday, August 24, 2014 6:18 PM
  • Why not keeping ALL AS IT IS like Outlook 2007/2010 does?

    It is also important for me that the "Delivered-To:" header ist kept as my AddIn relies on this!

    Regards,
    Robert.

    Sunday, August 24, 2014 6:57 PM
  • Hi Robert,

    As far as I know the "Delivered-To:" is an unknown command and it is ignored. If you know where it is documented, please let me know.

    Thanks, Vilmos

    Sunday, August 24, 2014 7:37 PM
  • Hi Vilmos,

    AFAIK the Delivered-To: header is non-standard.

    But I asked why Outlook does not leave the headers untouched? OL2K7 and OL2K10 work correctly, so where is the problem with OL2K13?

    Is there any reason WHY OL2K13 strips the headers out?

    Regards,
    Robert.

    Sunday, August 24, 2014 8:05 PM
  • To me the issue is very simple:  

    Outlook 2013 should never alter an email.  If I copy it then it should make an exact copy.  If I move it, them it should make an exact move.  The move operation on a Linux/Postfix setup is you cut the text data from one file and you insert it into another file.  There is no magic to it; therefore, no magic should be performed.  

    A carefully crafted bash script can do the job and do a better job than Outlook 2013.  Outlook 2013 should never alter the content of the message.  If it really needs to add an header that would be okay, but anything beyond that is just inconsiderate.  The email does not belong to Outlook or Microsoft.  So Outlook nor Microsoft shouldn't just go around changing things.  

    It is very possible, to almost a 100% certainty with smart phones and tablets, that multiple email clients will access an email message.  Outlook 2013 needs to be considerate of that.  Right now I can use Outlook 2007, Outlook 2010, Windows Mobile 5, Windows Mobile 6, Thunderbird, the email client for PalmOS, the email client for Android, Squirrel Mail, Round Cube, Ximian Evolution, versions of Outlook Express, or even the Java Mail API, and not a single one of them would take it upon itself to start deleting headers.  I can even use them all at the same time without causing much in the way of problems.  I wouldn't attempt to do concurrent moves, but one use at a time would be safe.  

    None of them basically attempt to take control of the IMAP account.  Why does Outlook 2013 basically think the IMAP account belongs to it?  I can tell you right now, it doesn't.  It makes Outlook 2013 a bad guest. It's the type of guest who would come over and throw out your dishes because it doesn't like the color.  I understand if you need to leave behind a little "trash" like your own email header.  Just do it like a good guest would: Put it in line with everything else, and don't mess with anything that is not yours without permission.

    Monday, August 25, 2014 8:53 PM
  • Hi Anonymous6314613!

    Couldn't said it better myself :-) !!

    Monday, August 25, 2014 9:04 PM
  • Hi Robert and Anonymous6314613,

    I’m sorry that the update to Outlook 2013 to retain “X-“ headers has not resolved all of this community’s concerns. Based on the comments in this thread we have broken the remaining concerns into two groups:

    • The ordering of header fields is not retained when a message is moved from one IMAP folder to another IMAP folder in Outlook. RFC 2822, section 3.6 states that  “It is important to note that the header fields are not guaranteed to be in a particular order.” However, that paragraph goes on to state that “the trace header fields and resent header fields MUST NOT be reordered”. Microsoft’s implementation of moving messages between IMAP folders in Outlook 2013 does not follow this requirement, and we will update the implementation notes in [MS-STANOIMAP] to describe Outlook 2013’s behavior of returning the headers in an arbitrary order.
    • The non-standard headers, e.g. “Delivered-To”, are not preserved when moving a message between IMAP folders. The recent fix was written to preserve all non-standard header fields that use the method described in RFC 822 for naming user-defined fields, specifically, by using the string “X-“ at the beginning of the header name. As the "Delivered-To" header is not a standard header, interpretation and retention of that field is left up to each implementer. Microsoft’s implementation in Outlook 2013 does not retain non-standard fields that do not begin with “X-“.

    If you wish to discuss changing the behavior of Outlook with regards to either of these two items, please send an email to "dochelp (at) microsoft (dot) com" and indicate it is for me and I will connect you with the product support team for Outlook to continue the conversation.

    Thanks, Vilmos

    Thursday, August 28, 2014 10:13 PM
  • Hi Vilmos,

    I have asked several times WHY Outlook 2013 alters the Mail-Headers, but did not get an answer yet. There must be a reason behind this! So, WHY? OL2K7 and OL2K10 work perfectly, so why not OL2K13?

    I am the Chief Software Architect of 'f Mail Server', a SMTP Anti-Spam Server, written completely in C#. I have worked on E-Mail related stuff for nearly two decades and I 've never encountered such a strange behavior like your client acts on mail moves between IMAP-Folders.

    I found this BUG, yes it is a bug (no need for discussion), on 18 Dec 2012 (!!) and reported this in: http://social.technet.microsoft.com/Forums/en-US/officeitpro/thread/e8122c0c-7abd-4d1d-957b-cec5f5a7167f/

    In 3 months we are talking about this for 2 years! I've neither got an answer WHY this has been implemented as MS did, nor why there is need for discussion to NOT get it fixed. Please explain WHY such a trivial thing gets delayed in endless discussions and does not get fixed.

    Regarding the 'Delivered-To:' header: I agree 100% with Anonymous6314613 that Mail-Headers must stay UNTOUCHED! It's bad practice to say: it's not described in the RFC, so we can do what we want. As Anonymous6314613 said: EVERY other Mail-Client (even OL2K7 and OL2K10) work 'correctly', but not OL2K13.

    So please enlighten us, WHY you (or the Outlook Dev.-Team) 'refuse' to correct OL2K13 to work like OL2K7/10?

    I assume that we won't get it fixed...

    Regards,
    Robert.

    Friday, August 29, 2014 10:56 PM
  • Thank you Vilmos.  I hope your manager is aware of the hard work you've put in here for us.  

    Will be emailing you.  

    Is there a reason the "move" operation isn't done with server side commands?  What if I move a 10 MB email over a slow link?  Why not let the email server do it's job?  Why should I have to risk paying a data tariff?  Consider I might be on an airplane.

    I strongly urge your team to use this:

    http://tools.ietf.org/html/rfc3501#section-6.4.7

    BTW, RFC 2822 is obsoleted by http://tools.ietf.org/html/rfc5322.  However there are other RFCs which need to be considered: http://tools.ietf.org/html/rfc6376#section-3.5, http://tools.ietf.org/html/rfc4408#section-7, http://tools.ietf.org/html/rfc4021

    I'm sure there more.  There will be more.  One day there might even be a header tagged in there to track whether or not "postage" was paid.  You can never guess.  So please, please, just COPY the message.

    Tuesday, September 02, 2014 2:48 AM
  • Hi,

    I would like to summarize what we have discussed on this thread. Before doing so, it’s important for me to state more clearly the purpose of this forum.  We discuss both documentation (specification and standards) and implementation here. However, our purpose in doing so, is always to accurately document the current protocols and formats used as well as the current product behavior. It is not the purpose of this forum to change the product behavior.  We do report product behavior deviations and problems but, unless clearly or explicitly documented, usually leave it to the product support channels to follow up with the product development teams for decisions on design and implementation changes.

    Having said that, here are the current states of the topics we’ve discussed:

    1. When Outlook shuffles the trace header fields, it is a violation of the RFC, which states that these header fields MUST NOT be reordered. This anomaly is not documented. There is a report on this, the current plan is that this behavior will be documented.
    2. The RFC states “header fields SHOULD NOT be reordered when a message is transported or transformed”, the same paragraph explicitly explains “It is important to note that the header fields are not guaranteed to be in a particular order. They may appear in any order”. Outlook does not keep the original order; there is a report on this, the current plan is that this behavior will be documented.
    3. The non-standard header fields, e.g. “Delivered-To”, are not preserved. There is no documentation that prescribes what to do with the non-standard header fields, specifically, not starting with “X-“, the assumption on our part (which we understand you do not share) is that the behavior to keep them or delete them is equally valid. Outlook deletes them, the current plan is that this behavior will be documented.

    If you want to change any of the above behavior, please send an email to dochelp and indicate it is for me and I will connect you with the product support team for Outlook to continue the conversation.

    Thanks, Vilmos

    Tuesday, September 09, 2014 5:21 AM
  • OK - I give up! Deleting OL2K13 right now :( ...

    ...and my customers will do the same!

    Wednesday, September 17, 2014 5:56 PM
  • Hi Robert,

    I understand your frustration.  As I mentioned previously, I would be more than happy to connect you to one of our Outlook specialists to continue the conversation around these issues that you would like to see addressed.  Others have taken advantage of this offer. Unfortunately, this forum is not the best channel to pursue these behavior changes. 

    Please send me email if you wish to continue.

    Thanks, Vilmos

    Thursday, September 18, 2014 7:11 PM
  • Robert,

    I know this is an old thread and it doesn't seem to have arrived at any kind of satisfactory conclusion, but I'm just wondering if you ever got an answer or figured out a resolution to the issue.

    I am currently seeing the same behavior in Outlook 2016 and this is the only thread I've come across where someone is actually clearly expressing the root of the problem. I'd appreciate any additional insight if you've made any headway on this problem over the past two years. Unfortunately, it doesn't seem like a priority to MS.

    Thanks!

    Wednesday, September 21, 2016 4:49 PM