none
Implement ActiveSync Client question: Mail command - GetAttachment RRS feed

  • Question

  • To dear Microsoft developers,

    Recently I have surveyed ActiveSync Protocol document, and encountered an unsolved problem:

    I found the mail attachment in a mail which are sent from mail server system (which may tell you there has an email address can not be recognized) can't be accessed with GetAttachment command. However, the message of the mail itself can be accessed in Sync GetChanges.

    To be more specifically, I sent a mail with an address that does not exist, and after a period, I will receive a returned mail in my inbox from system. Then I try to get the content of this mail with Sync command, and found that there has an attachment which may be the original mail I sent before. However, when I try to get this attachment with GetAttachment command, the Exchage Server told me that it's not accessible.

    Since the document I surveyed does not mention this behavior, do I make something wrong or this behavior will vary from version to version of the protocol?

    Thanks for your help

    P.s. I implement my client protocol with ActiveSync version 2.5

    Best regards,
    Nicholas
    Monday, December 29, 2008 9:36 AM

Answers

  • Hi Nicholas,

     

    HTTP code "400 Bad request" typically indicates a problem with the syntax of the request. We suspect that the issue is with the AttachmentName parameter, which is a field of the Request-URI of the HTTP POST for the GetAttachment command.

     

    In ActiveSync 2.5, the HTTP Request-URI must be encoded according to RFC 2396 http://www.ietf.org/rfc/rfc2396.txt.

    For instance, an ASCII space character in the AttachmentName would result in a %20 for his HEX value. Recall that the ASCII "-" is an unreserved character (Section 2.3) whereas the ASCII space " " is an escape character (Section 2.4).

     

    Since you are able to successfully fetch regular attachments (e.g. PDF, Excel, Word, jpeg, png, and email), I would suggest you compare the Request-URI encoding you are sending in the successful cases to the case of the NDR attachment.

     

    Please let us know if this is helpful.

     

    Regards,

    Edgar

     

    Friday, January 9, 2009 11:18 PM
    Moderator

All replies

  • Nicholas,

       Thanks for posting the question regarding protocol documentation.  One of our team members will look into your question and respond to you soon.
    Hongwei Sun -MSFT
    Monday, December 29, 2008 4:36 PM
  • Hi Nicholas,

     

    While I am investigating your ActiveSync case, I have some clarification questions.

    a.    Which error code are you getting when you attempt to sync-retrieve the attachment of the delivery status notification?

    b.    When you mentioned the attachment is not accessible, are you experiencing a general error or specific error related to GetAttachment? http://msdn.microsoft.com/en-us/library/aa580757.aspx

    -      ErrorCannotOpenFileAttachment: GetAttachment returns this error if it cannot retrieve the body of a file attachment.

    -      ErrorInvalidAttachmentId: This error is returned by GetAttachment or DeleteAttachment when an attachment that corresponds to the specified ID is not found.

    c.    Which version of Exchange Server are you running?

    d.    Are you running Windows Mobile on your ActiveSync client? If yes, which version are you using?

    e.    Do you have access to the IIS log on the Exchange server or the HTTP log on the ActiveSync client?

     

    Meanwhile, you might consider the scenario in [MS-ASCMD] Section 4.1.3, which provides an example for fetching an attachment. It uses the Sync command to synchronize a new message with an attachment to the client. Then, the ItemOperations command is used to retrieve the attachment. 

    The latest version of [MS-ASCMD] is available at http://msdn.microsoft.com/en-us/library/dd299441.aspx

     

    Regards,

    Edgar

    Friday, January 2, 2009 3:14 PM
    Moderator
  • to dear Edgar,

    Thanks for your response :-)

    a. Which error code are you getting when you attempt to sync-retrieve the attachment of the delivery status notification?

    → I got an HTTP 400 Bad Request error, and the following is my request header:
    POST /Microsoft-Server-ActiveSync?Cmd=GetAttachment&User=[HIDE]&DeviceId=[HIDE]&DeviceType=[HIDE]&AttachmentName=Inbox/Undeliverable: aTestMail-4.EML/1_multipart_xF8FF_3_aTestMail.eml 
    MS-ASProtocolVersion: 2.5 
    User-Agent: [HIDE] 
    Authorization: [HIDE] 
    Content-Length: 0 

    b. When you mentioned the attachment is not accessible, are you experiencing a general error or specific error related to GetAttachment? http://msdn.microsoft.com/en-us/library/aa580757.aspx

    → No. I confront a HTTP error directly, but other attachments are accessible.

    c. Which version of Exchange Server are you running?

    → We run Exchange Server 2003 SP2, and use ActiveSync protocol version 2.5

    d. Are you running Windows Mobile on your ActiveSync client? If yes, which version are you using?

    → No. We test and implement our ActiveSync client with Python library on the Windows XP

    e. Do you have access to the IIS log on the Exchange server or the HTTP log on the ActiveSync client?

    → No. The Exchange Server we communicate with is a remote server, and the IIS log is not accessible. We get our HTTP response header below:
    HTTP/1.1 400 Bad Request 
    Content-Length: 20 
    Date: Wed, 07 Jan 2009 03:38:52 GMT 
    Content-Type: text/html 


    Thanks for your response and help again! ;-)

    Best regards,
    Nicholas
    Wednesday, January 7, 2009 3:39 AM
  • Hi Nicholas,

    Thanks for the clarification answers.
    When you mentioned that other attachments are accessible, what types of attachments are you able to retrieve with GetAttachment? Could you specify whether you tried different content-type values?
    Could you provide raw traces of the following emails including all internet headers:
    - the orignal email that triggers the delivery status notification
    - the delivery status notification from the Exchange server
    I will update you as soon as I have the answer or more clarification questions.

    Regards,
    Edgar
    Thursday, January 8, 2009 2:42 AM
    Moderator
  • to dear Edgar,

    a. What types of attachments are you able to retrieve with GetAttachment?

    → Except for the attachment type (with an original mail) in a returned mail, others are just fine.

    b. Could you specify whether you tried different content-type values?

    → Did you meant whether I have tried to fetch other types of attachment? Yes. I have tried to fetch a PDF file, an Excel file, a Word doc, few pictures (jpeg, png) and a mail as an attachment I sent to my account.

    c. Could you provide raw traces of the following emails including all internet headers?

    Sure.

    The original mail is sent through the ActiveSync client, I can't get the original MIME types of the mail. However, I could post some information here (displayed by the OWA interface):

    From: et05 <et05@[HIDE]> 
    To: &amp;qout;ET04&amp;&quot; &amp;lt;et04@[HIDE]&amp;gt;; &amp;quot;Nicholas&amp;quot; &amp;lt;nicholas_@[HIDE]&amp;gt; 
    Cc: 
    Subject: aTestMail 
    Attachments: testPic.bmp(86B) 
     
    <Without_mail_body> 

    As you can see, the receiver address is a mess, and this mail shall be returned since the address can not be recognized by server. However, I still got a HTTP 200 OK at the time I used "SendMail" command to send this mail.

    The HTTP response after I sent the original mail:
    HTTP/1.1 200 OK 
    Content-Length: 0 
    Pragma: no-cache 
    X-Powered-By: ASP.NET 
    Server: Microsoft-IIS/6.0 
    Ms-Server-ActiveSync: 6.5.7638.1 
    Date: Fri, 28 Nov 2008 09:57:00 GMT 

    And the returned mail:
    1    <Add> 
    2     <ServerId>1:5</ServerId> 
    3     <ApplicationData> 
    4      <To xmlns="POOMMAIL">&quot;et05&quot; &lt;et05@[HIDE]&gt;</To> 
    5      <From xmlns="POOMMAIL">&quot;System Administrator&quot; &lt;postmaster@[HIDE]&gt;</From> 
    6      <Subject xmlns="POOMMAIL">Undeliverable: aTestMail</Subject> 
    7      <DateReceived xmlns="POOMMAIL">2008-12-16T13:09:26.595Z</DateReceived> 
    8      <DisplayTo xmlns="POOMMAIL">ET04; Nicholas</DisplayTo> 
    9      <ThreadTopic xmlns="POOMMAIL">aTestMail</ThreadTopic> 
    10      <Importance xmlns="POOMMAIL">2</Importance> 
    11      <Read xmlns="POOMMAIL">1</Read> 
    12      <Attachments xmlns="POOMMAIL"
    13       <Attachment> 
    14        <AttMethod>5</AttMethod> 
    15        <AttSize>591</AttSize> 
    16        <DisplayName>aTestMail.eml</DisplayName> 
    17        <AttName>Inbox/Undeliverable: aTestMail-4.EML/1_multipart_xF8FF_3_aTestMail.eml</AttName> 
    18       </Attachment> 
    19      </Attachments> 
    20      <MessageClass xmlns="POOMMAIL">REPORT.IPM.Note.NDR</MessageClass> 
    21      <InternetCPID xmlns="POOMMAIL">65001</InternetCPID> 
    22     </ApplicationData> 
    23    </Add> 

    Best regards,
    Nicholas
    Thursday, January 8, 2009 7:12 AM
  • Hi Nicholas,

     

    HTTP code "400 Bad request" typically indicates a problem with the syntax of the request. We suspect that the issue is with the AttachmentName parameter, which is a field of the Request-URI of the HTTP POST for the GetAttachment command.

     

    In ActiveSync 2.5, the HTTP Request-URI must be encoded according to RFC 2396 http://www.ietf.org/rfc/rfc2396.txt.

    For instance, an ASCII space character in the AttachmentName would result in a %20 for his HEX value. Recall that the ASCII "-" is an unreserved character (Section 2.3) whereas the ASCII space " " is an escape character (Section 2.4).

     

    Since you are able to successfully fetch regular attachments (e.g. PDF, Excel, Word, jpeg, png, and email), I would suggest you compare the Request-URI encoding you are sending in the successful cases to the case of the NDR attachment.

     

    Please let us know if this is helpful.

     

    Regards,

    Edgar

     

    Friday, January 9, 2009 11:18 PM
    Moderator
  • to dear Edgar,

    Yes! you're right! This really works!! :-)

    Thanks for your help again.
    As you said, the successful programs did encode the AttachmentName parameter, and the failed one did not.

    Great job! ;-)

    Best regards,
    Nicholas
    Monday, January 12, 2009 2:18 AM