Email Attachment Info when Downloading from IMAP without Attachments

If the Imap.AutoDownloadAttachments property is set to false, or if headers-only are downloaded, then emails will be downloaded without attachments.  However, attachment information, such as the count, and the size and filename of each attachment is still available.

When an email is downloaded from an IMAP server without the attachment data, the attachment information is added as headers to the email:

  • ckx-imap-numattach: contains the number of attachments.
  • ckx-imap-attach-nm-{N}: contains the name of the Nth attachment, where N begins at 1 for the 1st attachment.  For example “ckx-imap-attach-nm-1”
  • ckx-imap-attach-sz-{N}: contains the size in bytes of the Nth attachment.

The IMAP API provides methods for getting this information:

  • GetMailNumAttach
  • GetMailAttachSize
  • GetMailAttachFilename

Each of these methods begins with the string “GetMail”, and the 1st argument is the email object from which the information is to be retrieved.  If the “ckx-imap-*” header is not found, then it returns the information provided by the email object itself:

  • GetMailNumAttach:  If the ckx-imap-numattach header is not present, it returns the value of the emailObject.NumAttachments property.   (where emailObject is the email object passed to GetMailNumAttach)
  • GetMailAttachSize: If the ckx-imap-attach-sz-* header is not present, it calls emailObject.GetAttachmentSize and returns its value.
  • GetMailAttachFilename: If the ckx-imap-attach-nm-* header is not present, it calls emailObject.GetAttachmentFilename and returns its value.

The Chilkat.Email object (CkEmail, CkoEmail, etc.) also has properties and methods for getting attachment information.  However, these apply to attachments that are already downloaded and present within the email object.  For example:

  • Email.NumAttachments:  This property returns the number of attachments that are fully present within the email object.
  • Email.GetAttachmentFilename:  This method returns the filename of the Nth attachment that is already fully present in the email object.
  • Email.GetAttachmentSize:  Again, it returns the size in bytes of the Nth attachment that is fully present in the email object.

Sending Emails with Large Attachments

Question:

I have downloaded the Chilkat Email component for POP3/SMTP.  When I tried to send email by attaching a file of size of  2 MB,  the email is not been sent.  Could you please let me know how I can send large size attachments using the Chilkat component?

Answer:

There is no limitation in the Chilkat Email component.  It can send emails with attachments of any size.  The limitation is most likely in the SMTP server, or in the receiving mail server (not accepting emails larger than a certain size).  I would recommend examining the contents of the mailman.LastErrorText property after calling SendEmail (or after calling whichever method is used to send the email).  If everything looks OK and the SendEmail was successful, then check your SMTP server logs.  If all seems OK there, then it may be a limitation in the destination (recipient) mail server, or perhaps a size limitation set for the recipients email account.

Email Attachment Not Found?

The following is a list of the most common mistakes made when expecting to find an attachment in an email object:

  1. You downloaded headers-only.  If you call a method to download only the headers of an email, then the attachments will not be included.  With IMAP you will still get information about the attachments, but with POP3 you will not get them at all.  See this blog post about POP3 email headers and attachment info.
  2. What you are expecting to see as an attachment is actually a “related item”.  A related item is an image, style sheet, etc. that is part of the HTML presentation.  It is an embedded item that is referenced by the HTML body of an email and is not a formal attachment.  You’ll find a complete set of properties and methods for related items:  NumRelatedItems, GetRelatedData, SaveRelatedItem, etc.
  3. It is an “attached message”.  Similar to related items, a complete email that is attached to another email is considered separately by Chilkat.  The property is NumAttachedMessages.  To get the Nth attached message, call GetAttachedMessage(index).  this returns a new email object that is the Nth attached message.
  4. It is an attachment found within an attached message.  You would first need to get the attached message and then you’ll see the attachments within it.

    POP3 Headers and Attachment Info

    The POP3 protocol is not very feature rich. To download an email “header” the POP3 client must issue a “TOP” command. The following text is from RFC 1939 and describes the response to the TOP command:

    ...
    After the initial +OK, the
    POP3 server sends the headers of the message, the blank
    line separating the headers from the body, and then the
    number of lines of the indicated message's body, being
    careful to byte-stuff the termination character (as with
    all multi-line responses).
    ...
    

    What this means is that the response will contain the N raw lines following the email header. An email with attachments is typically a multipart/mixed email and therefore the lines following the initial MIME header are the MIME sub-headers and sub-header bodies. For example, consider the following email which contains 3 GIF image attachments:

    MIME-Version: 1.0
    Date: Tue, 04 Nov 2008 14:54:33 -0600
    Message-ID: <CHILKAT-MID-1adb0da5-2646-edac-1f79-9e288b0677ac@CK2007>
    X-Mailer: Chilkat Software Inc (http://www.chilkatsoft.com)
    X-Priority: 3 (Normal)
    Subject: This is a test
    From: "Support" <support@something-123.com>
    Return-Path: support@something-123.com
    To: "Admin" <admin@something-123.com>
    Content-Type: multipart/mixed;
    	boundary="-----_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX"
    
    This is a multi-part message in MIME format.
    
    -------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
    Content-Type: text/plain
    Content-Transfer-Encoding: quoted-printable
    
    This is line 1
    This is line 2
    This is line 3
    This is line 4
    This is line 5
    This is line 6
    This is line 7
    This is line 8
    This is line 9
    
    -------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
    Content-Type: image/gif;
    	name="small1.gif"
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment;
    	 filename="small1.gif"
    
    R0lGODlhFAAUAJH/AP///wD/PACLIQAAACwAAAAAFAAUAEACFoyPqcvtLoaclL6Ls968+w+G
    4kiWYwEAOw==
    
    -------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
    Content-Type: image/gif;
    	name="small2.gif"
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment;
    	 filename="small2.gif"
    
    R0lGODlhFAAUAJH/AP///wD/PACLIQAAACwAAAAAFAAUAEACFoyPqcvtLoaclL6Ls968+w+G
    4kiWYwEAOw==
    
    -------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
    Content-Type: image/gif;
    	name="small3.gif"
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment;
    	 filename="small3.gif"
    
    R0lGODlhFAAUAJH/AP///wD/PACLIQAAACwAAAAAFAAUAEACFoyPqcvtLoaclL6Ls968+w+G
    4kiWYwEAOw==
    
    -------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX--
    
    

    A POP3 server would respond to a “TOP 25” lines command by sending the following:
    (The line numbers enclosed in parentheses are not actually included in the POP3 server’s response)

    MIME-Version: 1.0
    Date: Tue, 04 Nov 2008 14:54:33 -0600
    Message-ID: <CHILKAT-MID-1adb0da5-2646-edac-1f79-9e288b0677ac@CK2007>
    X-Mailer: Chilkat Software Inc (http://www.chilkatsoft.com)
    X-Priority: 3 (Normal)
    Subject: This is a test
    From: "Support" <support@something-123.com>
    Return-Path: support@something-123.com
    To: "Admin" <admin@something-123.com>
    Content-Type: multipart/mixed;
    	boundary="-----_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX"
    
    (1)This is a multi-part message in MIME format.
    (2)
    (3)-------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
    (4)Content-Type: text/plain
    (5)Content-Transfer-Encoding: quoted-printable
    (6)
    (7)This is line 1
    (8)This is line 2
    (9)This is line 3
    (10)This is line 4
    (11)This is line 5
    (12)This is line 6
    (13)This is line 7
    (14)This is line 8
    (15)This is line 9
    (16)
    (17)-------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
    (18)Content-Type: image/gif;
    (19)	name="small1.gif"
    (20)Content-Transfer-Encoding: base64
    (21)Content-Disposition: attachment;
    (22)	 filename="small1.gif"
    (23)
    (24)R0lGODlhFAAUAJH/AP///wD/PACLIQAAACwAAAAAFAAUAEACFoyPqcvtLoaclL6Ls968+w+G
    (25)4kiWYwEAOw==
    

    The POP3 client has no knowledge of the attachments following the 1st 25 lines. The POP3 client, if it’s able to parse the prematurely chopped-off MIME, may have knowledge of attachments that might have been included in the response (it would depend on how good the MIME parser is capable of dealing with prematurely terminated MIME). You can see that no matter how many header lines are retrieved, you can never be sure of receiving all the attachments (or even knowing about them) unless the entire email is downloaded. For example, you could have an email with two attachments — one very large one and one very small one. If the small one follows the large one, you’ll never see it unless you download the full contents of the large attachment to get at the small attachment that follows…