mikel / mail

A Really Ruby Mail Library
MIT License
3.61k stars 935 forks source link

Attachment is incorrectly added to the email which has html and text part #1499

Open ibalosh opened 1 year ago

ibalosh commented 1 year ago

In the example in the readme file there is this code snippet:

@mail = Mail.new do
  to      'nicolas@test.lindsaar.net.au'
  from    'Mikel Lindsaar <mikel@test.lindsaar.net.au>'
  subject 'First multipart email sent with Mail'

  text_part do
    body 'Here is the attachment you wanted'
  end

  html_part do
    content_type 'text/html; charset=UTF-8'
    body '<h1>Funky Title</h1><p>Here is the attachment you wanted</p>'
  end

  add_file '/path/to/myfile.pdf'
end

this snippet would generate an email which would look something like this:

Date: Wed, 02 Nov 2022 12:39:14 +0100
From: Mikel Lindsaar <mikel@test.lindsaar.net.au>
To: nicolas@test.lindsaar.net.au
Message-ID: <636256e27cf1c_bfc52f8-39e@IgorsMacStudio.mail>
Subject: First multipart email sent with Mail
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_636256ddc87d7_bfc52f8-4b1";
 charset=UTF-8
Content-Transfer-Encoding: 7bit

----==_mimepart_636256ddc87d7_bfc52f8-4b1
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

Here is the attachment you wanted
----==_mimepart_636256ddc87d7_bfc52f8-4b1
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<h1>Funky Title</h1><p>Here is the attachment you wanted</p>
----==_mimepart_636256ddc87d7_bfc52f8-4b1
Content-Type: image/png;
 filename=postmark.png
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename=postmark.png
Content-ID: <636256e27da4d_bfc52f8-283@IgorsMacStudio.mail>

iVBORw0KGgoAAAANSUhEUgAAAPAAAADwCAMAAAAJixmgAAABU1BMVEUAAAD+
/v77+/v4+PjNzc3R0dHNzc3w8PDl5eX4+Pj9/f37+/v+/v7Nzc3W1tb8/Pzi
4uLNzc3W1tb+/v77+/vNzc3S0tL////Ozs7+/v7Nzc39/f3Z2dnNzc319fXO...

Judging by RFC 2046 the email should have been generated with structure that looks something like this:

while the structure is:

which seems wrong since RFC says:

The multipart/alternative type is syntactically identical to multipart/mixed, but the semantics are different. In particular, each of the parts is an "alternative" version of the same information. [...] In general, the best choice is the LAST part of a type supported by the recipient system's local environment.

by my understanding, multiplart/alternative is mostly used for viewing alternative representation of content html, text, or something else, while attachment is not fitting this case.

I have reproduced this with mail.gem version 2.7.1

dlouzan commented 1 year ago

@ibalosh I think you're just relying on the default simple behaviour, and you'll have to force the content-types and parts if you want that structure; a bit further into the readme you can find samples on how to use multipart/mixed, multipart/related, and multipart/alternative: https://github.com/mikel/mail/blob/master/README.md#writing-and-sending-a-multipartalternative-html-and-text-email

ibalosh commented 1 year ago

@dlouzan thank you for reply. I agree, that is how I am creating multipart messages, using something like the example you shared, so I can have proper structure in the email. I am not using the simple example.

Still though, the incorrect placements I shared is generated by example which is in the readme file. If that's not how email should be created, it should not be there at all.