Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mail::Body object returned from Mail::Message#body does not inherit message's charset #1410

Open
sylph01 opened this issue Sep 13, 2020 · 5 comments

Comments

@sylph01
Copy link

sylph01 commented Sep 13, 2020

It seems like the returned Mail::Body instance from Mail::Message#body always uses the default charset US-ASCII regardless of the Content-Type header in the original message.

mail-body-charset-notated

Is this behavior intended? If not, I am ready to write up a patch for this. (I might need some help on testing)

@clinejj
Copy link

clinejj commented Aug 17, 2021

I also experienced this issue with ActionMailbox on Rails (see rails/rails#43038)

Steps to reproduce

Given the email contents below, I would expect the plain-text portion of the email to be decoded using UTF-8 because of the header, but instead Mail uses ASCII-US. We are using the default configuration for ActionMailbox, which according to the guide should set UTF-8.

Email Contents (sent from Gmail)

MIME-Version: 1.0
Date: Tue, 17 Aug 2021 11:32:25 -0400
References: <redacted>
In-Reply-To: <redacted>
Message-ID: <redacted>
Subject: Re: Subject
From: <redacted>
To: <redacted>
Content-Type: multipart/alternative; boundary="00000000000056fcd505c9c30680"

--00000000000056fcd505c9c30680
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Teamwork =F0=9F=99=8C=F0=9F=8F=BB

-John


On Tue, Aug 17, 2021 at 11:29 AM Redacted <redacted> wrote:

> -- Reply ABOVE THIS LINE --
>

--00000000000056fcd505c9c30680
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Teamwork =F0=9F=99=8C=F0=9F=8F=BB</div>

--00000000000056fcd505c9c30680--

Expected behavior

Mail should report the charset as UTF-8 and decode as such, given the header for the first plain-text body part. Note the charset in the first block here:

irb(main):025:0> email.parts.first
=> #<Mail::Part:52620, Multipart: false, Headers: <Content-Type: text/plain; charset="UTF-8">, <Content-Transfer-Encoding: quoted-printable>>
irb(main):026:0> email.parts.first.body
=>
#<Mail::Body:0x000055b221450370
 @ascii_only=true,
 @boundary=nil,
 @charset="US-ASCII",
 @encoding="quoted-printable",
 @epilogue=nil,
 @part_sort_order=["text/plain", "text/enriched", "text/html", "multipart/alternative"],
 @parts=[],
 @preamble=nil,
 @raw_source=
  "Teamwork =F0=9F=99=8C=F0=9F=8F=BB\r\n\r\n-John\r\n\r\n\r\nOn Tue, Aug 17, 2021 at 11:29 AM Redacted <\r\nredacted> wrote:\r\n\r\n> -- Reply ABOVE THIS LINE --\r\n>">
irb(main):027:0> email.parts.first.headers
=> {}
irb(main):028:0> email.parts.first.header
=>
#<Mail::Header:0x000055b22121b168
 @charset="UTF-8",
 @fields=
  [#<Mail::Field 0x19b40 @name="Content-Type" @unparsed_value="text/plain; charset=\"UTF-8\"" @charset="UTF-8" @field_order_id=23 @field=#<Mail::ContentTypeField:0x000055b221219ca0 @charset="UTF-8", @main_type="text", @sub_type=nil, @parameters=nil, @name="Content-Type", @length=nil, @element=#<Mail::ContentTypeElement:0x000055b221219a20 @main_type="text", @sub_type="plain", @parameters=[{"charset"=>"UTF-8"}]>, @value="text/plain; charset=\"UTF-8\"">>,
   #<Mail::Field 0x19b68 @name="Content-Transfer-Encoding" @unparsed_value="quoted-printable" @charset="UTF-8" @field_order_id=24 @field=#<Mail::ContentTransferEncodingField:0x000055b2211f1188 @charset="UTF-8", @name="Content-Transfer-Encoding", @length=nil, @element=#<Mail::ContentTransferEncodingElement:0x000055b2211f1048 @encoding="quoted-printable">, @value="quoted-printable">>],
 @raw_source="Content-Type: text/plain; charset=\"UTF-8\"\r\nContent-Transfer-Encoding: quoted-printable">

Actual behavior

Mail uses US-ASCII for the body and UTF-8 for the header.

System configuration

Rails version:
6.1.4
Ruby version:
3.0.2

@diesl
Copy link

diesl commented Dec 8, 2022

The same error happened to me this week. It would be nice if this could be fixed.

@kwent
Copy link

kwent commented Dec 8, 2022

Same here !

@lylo
Copy link

lylo commented Oct 13, 2023

Is there a known workaround?

@jens
Copy link

jens commented Dec 4, 2023

Is there a known workaround?

What I do is just call the decoded method directly on the mail or part object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants