Expand Upon/Refactor Email Attachments

[ikiril01]

We currently can't capture useful email attachment characteristics like the MIME Type, so we should consider restructuring the Email Message Object to support these entities. Another possibility would be to create a separate Email Attachment Object (based upon the File Object) to capture this data.

[gtback]

If we really want to go all-out on this, we should should actually recreate the MIME hierarchy. Items like "Body" and "Attachments" are an incredibly useful abstraction in many applications, but the RFC 5322 format can't be 100% faithfully represented in CybOX. If we create a MIMEPartType, which could contain nested parts, I think it would help a lot.

[ikiril01]

Agree with you Greg - I guess the question is whether we want to 100% recreate RFC 5322 or have some abstraction of it. Another possibility may be to create a relatively simple AttachmentType in the Email Object with the following notional properties:

Content_Description (String; provides a brief textual description of a given attachment.) Content_Disposition (String; provides a description of the presentation method used in the mime message content. A bodypart is marked "inline" if it is intended to be displayed automatically upon display of the message. Bodyparts can be designated "attachment" to indicate that they are separate from the main body of the email message, and that their display should not be automatic, but contingent upon some further action of the user.) Content_Transfer_Encoding (String; specifies an auxiliary encoding that was applied to the data to allow it to pass through mail transport mechanisms which may have data or character set limitations.) Description (String; used to identify the contents of a attachment file.) File (FileObjectType; describes the actual attachment file) forwarded (boolean; describes whether the attachment was received as a result of forwarding) *MIME_Type (String; the MIME type of the attachment)

[gtback]

"Attachment" is a useful notion in email clients, but what I'm really talking about is each MIME part, including the ones that never get presented to the displayed to the user, such as multipart/*. If you changed the name of the type to MIMEPartType, and allowed recursive inclusion of additional MIME parts, I'd be 98% of the way with you :smile:

• I don't see the need for both Content_Description and Description, particularly since both are human-written and cannot be "automated". For that reason, I'm not 100% convinced that either is necessary. Unless I misunderstand what you mean.
• I'm not sure if I'd want to reuse the "FileObject" here, since a lot of those properties are assuming the file is on disk, rather than a MIME part. I would be content with Name + Hashes.
• I don't know if forwarded is really applicable