Closed meain closed 7 months ago
I have not worked with Outlook, but I know Microsoft do some stuff that aren't standards.
The change seems simple, but adding headerEncoding
requires support and additional encoding. If I read well, this needs to be disableHeaderEncoding
to avoid apply it.
I'm guessing according to RFC6530, UTF-8 is valid in headers without any additional encoding.
this needs to be
disableHeaderEncoding
to avoid apply it
That would be simpler approach. I was proposing a headerEncoding
field in case we wanted to add a base64
encoding at a later point.
Perfect, you are right, please send a PR with the headerEncoding
, I maintain another package to parse the mail https://github.com/OfimaticSRL/parsemail, maybe we should merge some stuff from here to test some cases.
As of now, we always use
q
encoding for headers, but I'm assuming we could extend it to accommodate different encodings. We used to do this previously based on the value ofencoding
but that seems to have been removed in https://github.com/xhit/go-simple-mail/commit/7fdf6eac62d423846ccf212330d160192aec7caa possibly because we wanted different encoding for headers than messages.My specific usecase is to disable encoding for headers because Outlook somehow is not liking when we do
q
encoding in the.eml
files I try to import. Outlook seems to just send UTF-8 without any encoding as of now when I try to get.eml
file from them. I'm assuming this(not encoding headers) is not valid according to the spec, but somehow Outlook expects it this way. Do let me know if you have additional information on what I could be doing wrong if you have previously worked with Outlook.What are your thought on adding an additional field
headerEncoding
along withencoding
in themessage
struct and using that to decide what encoding to perform (ref)