Addition of configuration or alternatives to ParseEmail

[rorycl]

This might be only valid to my use case, but I only need to read the headers of a lot of emails.

I can imagine a few ways of doing this:

• add a new exported func such as ParseEmailHeader
  this might need to make the body unreadable
• add a new, parallel NewParseEmailConfig func
  returning a *Config struct off which you could run ParseEmail (parsing only headers if this option is set)
• add optional config to ParseEmail

So a few thoughts about the last option...

With a nod towards Dave Cheney's "Functional options for friendly APIs" I wonder if adding a variadic option struct or (better) functional options I wondered if you might consider adding some config options.

A quick hack as follows dropped my processing time to 1/10th of the time in comparison to full email parsing for about 1700 messages. (Please note this is not a proposal for the actual config code!).

type Config struct {
    HeadersOnly bool
    // somethingElse bool
}

func ParseEmail(r io.Reader, config ...Config) (Email, error) {
    var email Email

    msg, err := mail.ReadMessage(r)
    if err != nil {
        return email, fmt.Errorf("letters.ParseEmail: cannot read message: %w", err)
    }

    headers, err := parseHeaders(msg.Header)
    if err != nil {
        return email, fmt.Errorf("letters.ParseEmail: cannot parse headers: %w", err)
    }

    email = Email{
        Headers: headers,
    }

    // bad code
    if config != nil && config[0].HeadersOnly {
        return email, nil
    }
   ...

[rorycl]

Hi @mnako

Having further used mnako/letters in a bunch of small projects, most recently mailfinder I have some suggestions for refinements to ParseEmail, as follows:

I think it would be useful to allow:

• parsing only of headers (as noted above)
• parsing only of inline attachments, potentially only those of the general text (text/enriched text or html) variety
• parse everything as now

The first two would considerably speed up header-only or inline text-only use-cases.

Many of the recent mbox or maildir message parsers I've come across return an io.Reader for each message, for example the Proton mbox reader. Consequently each of these parsers should, in my view, take an io.Reader.

A further bonus request is to export package error types, such as ErrorInvalidAddress and ErrorInvalidMIMEType to allow clients to catch these errors using Errors.As.