package email_message

  1. Overview
  2. Docs
Legend:
Library
Module
Module type
Parameter
Class
Class type
module Mimetype : sig ... end
type attachment_name = string
val sexp_of_attachment_name : attachment_name -> Sexplib0.Sexp.t
module Attachment : sig ... end
module Content : sig ... end
type t = Email.t
val sexp_of_t : t -> Sexplib0.Sexp.t
val create : ?from:Email_address.t -> to_:Email_address.t list -> ?cc:Email_address.t list -> ?reply_to:Email_address.t -> subject:string -> ?id:string -> ?in_reply_to:string -> ?date:Core.Time_float.t -> ?auto_generated:unit -> ?extra_headers:(string * string) list -> ?attachments:(attachment_name * Content.t) list -> ?no_tracing_headers:[ `Because_not_using_standard_email_infra ] -> Content.t -> t
val make_id : unit -> string

A unique value to be used in a Message-Id header

val from : t -> Email_address.t option
val to_ : t -> Email_address.t list option
val cc : t -> Email_address.t list option
val subject : t -> string option
val id : t -> string option
val extract_body : ?content_type:Mimetype.t -> t -> string option
val all_attachments : ?include_inline_parts:[ `None | `Named | `Named_or_has_content_id ] -> ?look_through_attached_mails:bool -> t -> Attachment.t list

all_attachments looks recursively through the e-mail parts, looking for attachments.

~include_inline_parts (default is `None) controls whether this function will attempt to interpret inline parts as attachments. `Named_or_has_content_id most aggressively classifies parts as attachments, including inline parts that are either named or have a Content-Id header. `Named will include inline parts that are named.

If ~look_through_attached_mails:true (the default), it will separately include both e-mail attachments as well as the attachments to those e-mails. Otherwise it will include e-mail attachments but not (separately) any of the attached e-mails' attachments.

val find_attachment : t -> attachment_name -> Attachment.t option

Related parts are those that are included in a multi-part message with a "Content-ID" header. This content can be referenced by adding the "cid:" prefix and stripping the enclosing '<' and '>'.

For example (from https://tools.ietf.org/html/rfc2392):

        From: foo1@bar.net
        To: foo2@bar.net
        Subject: A simple example
        Mime-Version: 1.0
        Content-Type: multipart/related; boundary="boundary-example-1"; type=Text/HTML
        --boundary-example 1
        Content-Type: Text/HTML; charset=US-ASCII

        to the other body part, for example through a statement such as:
        <IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">

        --boundary-example-1

        Content-ID: <foo4*foo1@bar.net>
        Content-Type: IMAGE/GIF
        Content-Transfer-Encoding: BASE64

        R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
        NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
        etc...

        --boundary-example-1--

Calling all_related_parts on this email would return a list of length one where the attachment_name is "foo4*foo1@bar.net" for the single entry.

Related parts are often used for inline images.

val inline_parts : t -> Content.t list
val map_attachments : ?include_inline_parts:[ `None | `Named | `Named_or_has_content_id ] -> t -> f:(Attachment.t -> [ `Keep | `Replace of t ]) -> t

map_attachments recurses into message/rfc822 parts. However, if a message/rfc822 part is replaced, there is no further recursion.

module Expert : sig ... end
module Stable : sig ... end