Uniform interface for getting email body?

[sdhull]

Apologies if a better venue for this question would be Stackoverflow or similar—feel free to send me away.

We're on mail 2.8.0.1 & Rails 6.0.6

We have a situation at work where a mailer (actionmailer) has multiple actions which all render the same template, eg:

  def mail_email_template(template, mail_options)
    process_email_template(template)   # sets ivars @liquid_subject and @liquid_body

    mail(mail_options.merge(subject: @liquid_subject)) do |format|
      # Only format html because we use Premailer to take care of text format
      format.html { render "email_template" }   # renders @liquid_body
    end
  end

We also have an after_action that parses the email and adjusts styling based on customer preferences, eg:

  def apply_branding_button_colors
    settings = @user.email_template_branding_settings
    return unless settings
    styler = Email::HtmlStyler.new(mail.decode_body, settings)
    mail.body = styler.html
  end

However, when writing specs to troubleshoot a bug, I found that when the email had an ics attachment, mail.decode_body returned nil, but mail.html_part.to_s returned the email body. So I thought I'd switch to that to be safer, but in a different mailer action being tested (no attachment), mail.html_part.to_s returned an empty string, while mail.body.to_s returned the html body!

(mail in this context is the ActionMailer::Base#mail method which returns an instance of Mail::Message.)

So finally I ended up with email_body = mail.body.to_s.presence || mail.html_part.to_s as a best effort but I wanted to ask:

Am I missing something? Is there a uniform interface to reliably get a string representation of the email body?

[timoschilling]

The reason for that is that a Mail::Message with one part is different to a Mail::Message with multiple part. Having a html part and an attachment means it's multipart. You solution email_body = mail.body.to_s.presence || mail.html_part.to_s is right, maybe just use decoded and not to_s, it's the same but more explicit.

What you can do is that you always add a text part to your mail, so it will always be multipart, no matter an attachment exists or not.

[jon-sully]

I'm also interested in this discussion, though I discovered it upon parsing many different example inbound emails rather than outbound. I too have found that when dealing with multipart messages in varying styles (e.g. an HTML part, inline attachment, then another HTML part), simply "getting the body" is... difficult. No doubt this is because complicated emails are complicated and this is not a simple undertaking. This is how we've solved it for a couple of years. I just recently switched it to be a patch onto Mail::Message itself, but we've been running this logic for quite a while:

class Mail::Message
  def most_likely_body
    # Parsing the 'body' out of an email is actually quite difficult. There can be multiple different parts
    # in multiple different orders and chunks (e.g. html with an attachment in the middle makes 3 html parts)
    if (html_parts = all_parts.select { |p| p.mime_type == "text/html" && !p.attachment? }.presence)
      html_parts.map(&:decoded).join
    # If all we have is plain text parts, we'll use those in the same way
    elsif (plain_text_parts = all_parts.select { |p| p.mime_type == "text/plain" && !p.attachment? }.presence)
      plain_text_parts.map(&:decoded).join
    # Barring either of those, we'll just have to take the straight decoded body.
    else
      decode_body.presence
    end
  end
end

But I came to the repo to find out if this is a reasonable approach or just totally wrong (hope not!). And, maybe more interestingly, wondering the same thing OP was: does Mail itself have its own canonical method for producing a body string when it comes to complicated emails of varying nature?