Action Mailbox mistakes attachment as body if no body exists

[HashNotAdam]

I have set up a mailbox to process DMARC reports. This has been working fine in most cases, but it seems that sometimes Google doesn't include body text in the email—only a zipped XML file as an attachment.

When this happens, Action Mailbox decodes the Base64 encoding of the attachment and assigns the string representation of the binary data to the body of the message without adding the file as an attachment. I have noticed that the email also isn't recognised as being multipart.

Steps to reproduce

I've created a gist which includes the unedited email source as copied from the EML file stored by Active Storage

Expected behavior

The body of the message should include the Base64 encoding of the attachment and there should be 1 attachment representing a ZIP file

Actual behavior

Calling body.to_s on the underlying Mail::Message will return a string representation of the binary data which can be unzipped to return the XML. If the EML file were to be opened in an email client, this would be presented as an attachment

System configuration

Rails version: 7.1.2

Ruby version: 3.2.2

[bparanj]

There is an open issue: #39364. Seems like Rails currently does not support SES. See supported providers here: https://guides.rubyonrails.org/action_mailbox_basics.html. Here is the minimal test case to reproduce this problem:

# frozen_string_literal: true

require "bundler/inline"

gemfile(true) do
  source "https://rubygems.org"

  git_source(:github) { |repo| "https://github.com/#{repo}.git" }

  gem "rails"
  # If you want to test against edge Rails replace the previous line with this:
  # gem "rails", github: "rails/rails", branch: "main"

  gem "sqlite3"
end

require "active_record/railtie"
require "active_storage/engine"
require "action_mailbox/engine"
require "tmpdir"

class TestApp < Rails::Application
  config.load_defaults Rails::VERSION::STRING.to_f

  config.root = __dir__
  config.hosts << "example.org"
  config.eager_load = false
  config.session_store :cookie_store, key: "cookie_store_key"
  config.secret_key_base = "secret_key_base"

  config.logger = Logger.new($stdout)
  Rails.logger  = config.logger

  config.active_storage.service = :local
  config.active_storage.service_configurations = {
    local: {
      root: Dir.tmpdir,
      service: "Disk"
    }
  }

  config.action_mailbox.ingress = :relay
end

ENV["DATABASE_URL"] = "sqlite3::memory:"

Rails.application.initialize!

require ActiveStorage::Engine.root.join("db/migrate/20170806125915_create_active_storage_tables.rb").to_s
require ActionMailbox::Engine.root.join("db/migrate/20180917164000_create_action_mailbox_tables.rb").to_s

ActiveRecord::Schema.define do
  CreateActiveStorageTables.new.change
  CreateActionMailboxTables.new.change
end

class ApplicationMailbox < ActionMailbox::Base
  routing (/^report@/i) => :dmarc_report
end

class DmarcReportMailbox < ActionMailbox::Base
  def process
    $attachments = mail.attachments
  end
end

require "minitest/autorun"

class DmarcReportMailboxTest < ActionMailbox::TestCase
   setup do
    source = <<~SOURCE
      From: noreply-dmarc-support@google.com 
      To: report@dmarc.eduadv.com.au

      OTAzOTkueG1sUEsFBgAAAAABAAEAYAAAAFUCAAAAAA==
    SOURCE

    @inbound_email = receive_inbound_email_from_source(source)
  end

  test "the email has an attachment" do
    assert_equal $attachments.size, 1
  end
end

[HashNotAdam]

@bparanj I'm using action_mailbox_amazon_ingress and I've tried the branch from that PR, neither handles this specific problem.

Given the raw email is handed off to Action Mailbox for processing, are you suggesting that SES structures emails in a way that is different from other providers? If so, do you happen to know of any examples of how this is handed by other providers? Given the SES/SNS PR has been running for 4 years, I'd be interested in helping to get this fixed, but I can't say I know much about email standards

[rails-bot]

This issue has been automatically marked as stale because it has not been commented on for at least three months.
The resources of the Rails team are limited, and so we are asking for your help.
If you can still reproduce this error on the 7-1-stable branch or on main, please reply with all of the information you have about it in order to keep the issue open.
Thank you for all your contributions.