Discussion:
[bug-mailutils] multipart/alternative not displaying in Yahoo.com
Jean Louis
2017-04-16 21:10:34 UTC
Permalink
Hello,

When I send mailing, the multipart/alternative is not displaying in
Yahoo.com

When I receive email from leadpages.com into Yahoo, I can see they
have it as multipart/related that includes the multipart/alternative

Please review, how we can do it that it is really deliverable by using
mail from mailutils?

Imagine, sending multipart/alternative with text and html together is
displaying in Yahoo as having attachments. So something is certainly
wrong.

Do you know what?

Jean
Sergey Poznyakoff
2017-04-17 06:41:26 UTC
Permalink
Hi Jean,
Post by Jean Louis
Imagine, sending multipart/alternative with text and html together is
displaying in Yahoo as having attachments. So something is certainly
wrong.
Do you know what?
No I don't. The information you sent is way too vague for me to be able
to tell anything. I should know at least the following:

1. The command line used to send the mail.
2. Preferably, the output produced by the mail binary when sending the
message with verbose on (-E 'set verbose').
3. Raw content of the message as it arrived at the remote node.

Regards,
Sergey
Jean Louis
2017-04-17 07:01:03 UTC
Permalink
Post by Sergey Poznyakoff
Hi Jean,
Post by Jean Louis
Imagine, sending multipart/alternative with text and html together is
displaying in Yahoo as having attachments. So something is certainly
wrong.
Do you know what?
No I don't. The information you sent is way too vague for me to be able
1. The command line used to send the mail.
mail -E "unset askcc" -a "Date: `/bin/date +'%a, %d %b %Y %T %z'`" -a "Content-Type: text/plain; charset=utf-8" -a "Content-Disposition: inline" -a "Content-Transfer-Encoding: 8bit" -a "From: Jean Louis <***@example.com>" -E 'set record=maildir:~/Maildir/***@yahoo.com' -s 'Hello there' --alternative --content-type=text/html --attach=/home/data1/protected/index.html "Jean Louis <***@yahoo.com>" --content-type=text/plain

You need to replace ***@yahoo.com with your Yahoo address, and set From:

Then you may delete the set record, if you don't have such setup.

And you need to feed text from standard input.

That email as formed, is visible in Google without problems. In Yahoo,
it is not, it appears as 2 attachments. Screenshot attached.

In K9 application I see email correctly
(https://f-droid.org/posts/k-9-mail/), also in mutt, I see visible
multipart/alternative just as always.

I do not wish to blaim "mail" until you find out what is wrong. I am
guessing that mail is not constructing multipart/alternative
correctly, but there must be some slight error.

When I use makemime utility from Courier package, and send email as
multipart/alternative, it is just in same order

multipart/alternative
-> text part
-> html part

and html email is nicely visible in Yahoo. Same when I am doing it
with my other Perl stuff.
Post by Sergey Poznyakoff
2. Preferably, the output produced by the mail binary when sending the
message with verbose on (-E 'set verbose').
You may now with the command try yourself.
Post by Sergey Poznyakoff
3. Raw content of the message as it arrived at the remote node.
It is here temporary:
https://gnu.support/files/tmp/rawcontent.txt

The one which I constructed with makemime utility from Courier
package, you can see here, and it is showing well in Yahoo, with HTML
being shown as preferred part (I did not handle utf-8 correctly)
https://gnu.support/files/tmp/visible.txt

By the way, I could not enable quoted-printable with mail, even it was
accepted, I remember yesterday that it did not show up.

Once mail is cleaned up and working, this will be rare utility that
constructs multipart/alternative on the command line.

Jean
Sergey Poznyakoff
2017-04-17 12:52:10 UTC
Permalink
Post by Jean Louis
mail -E "unset askcc" -a "Date: `/bin/date +'%a, %d %b %Y %T %z'`"
inline" -a "Content-Transfer-Encoding: 8bit" -a "From: Jean Louis
--alternative --content-type=text/html
--attach=/home/data1/protected/index.html "Jean Louis
Thanks. Let me notice that the Content-Disposition and
Content-Transfer-Encoding settings have no effect.
Sorry, I have none. But never mind.
Post by Jean Louis
Post by Sergey Poznyakoff
2. Preferably, the output produced by the mail binary when sending the
message with verbose on (-E 'set verbose').
You may now with the command try yourself.
Jean, allow me to bring your attention to the fact that the output *I*'d get
is completely irrelevant. What *is* relevant, is what *you* get.
Post by Jean Louis
Post by Sergey Poznyakoff
3. Raw content of the message as it arrived at the remote node.
https://gnu.support/files/tmp/rawcontent.txt
Thanks. I must say that a brief glance on this mail suffices to
state that this message was *not* created by GNU mail. First of all, notice
this:

Content-Type: multipart/alternative; boundary="=_stw1.rcdrun.com-1522-1492412035-0001-2"

That's not a boundary line generated by GNU mailutils. We use the
following code (libmailutils/mime/mime.c:473):

snprintf (boundary, sizeof boundary, "%ld-%ld=:%ld",
(long) random (), (long) time (0), (long) getpid ());

As you seem it is obvious the content-type header above was not created
by GNU mailutils.

Secondly, it has the leading plaintext stanza

"This is a MIME-formatted message. If you see this text it means that
your E-mail software does not support MIME-formatted messages."

which mailutils never creates, either.

Surprisingly, the message does contain the X-Mailer header that seems to
have been produced by mailutils. The only way I can interpret it, is
that the message have been reformatted by the receiving party upon
arrival.

Apart from these obvious facts, it is a perfectly valid MIME message,
that no sane mail reader can interpret as containing attachments.

However, while I'm writing these lines, it strikes me that the content
type of the second MIME part contains the "name" attribute. While RFC
1341 does not explicitly forbid its use for the "inline" content
disposition, I can easily conceive that it may lead some MUAs astray.
If my guess is right, the attached patch should fix that.

Regards,
Sergey
Jean Louis
2017-04-17 13:33:08 UTC
Permalink
Post by Sergey Poznyakoff
Post by Jean Louis
mail -E "unset askcc" -a "Date: `/bin/date +'%a, %d %b %Y %T %z'`"
inline" -a "Content-Transfer-Encoding: 8bit" -a "From: Jean Louis
--alternative --content-type=text/html
--attach=/home/data1/protected/index.html "Jean Louis
Thanks. Let me notice that the Content-Disposition and
Content-Transfer-Encoding settings have no effect.
Sorry, I have none. But never mind.
Jean, allow me to bring your attention to the fact that the output *I*'d get
is completely irrelevant. What *is* relevant, is what *you* get.
Post by Jean Louis
Post by Sergey Poznyakoff
3. Raw content of the message as it arrived at the remote node.
https://gnu.support/files/tmp/rawcontent.txt
Thanks. I must say that a brief glance on this mail suffices to
state that this message was *not* created by GNU mail. First of
Content-Type: multipart/alternative; boundary="=_stw1.rcdrun.com-1522-1492412035-0001-2"
That's not a boundary line generated by GNU mailutils. We use the
snprintf (boundary, sizeof boundary, "%ld-%ld=:%ld",
(long) random (), (long) time (0), (long) getpid ());
The boundary line created on the local computer is following:
Content-Type: multipart/alternative; boundary="=_protected.rcdrun.com-3874-1492434723-0001-2"

In regards if it was created by GNU Mailutils or not, I would not be
putting these efforts to lie to you or create confusion, without
providing you true facts.

It was created by GNU Mailutils, it maybe was rewritten.

I was inspecting now, and boundary line on local computer is the one
above. Once it arrives to my server, the boundary line is changed to:

Content-Type: multipart/alternative; boundary="=_stw1.rcdrun.com-11649-1492435160-0001-2"

At this moment I do not know which software is changing it.
Post by Sergey Poznyakoff
As you seem it is obvious the content-type header above was not created
by GNU mailutils.
It is not so obvious for me, you know it, I can give my clues.
Post by Sergey Poznyakoff
Secondly, it has the leading plaintext stanza
"This is a MIME-formatted message. If you see this text it means that
your E-mail software does not support MIME-formatted messages."
which mailutils never creates, either.
That is probably done by Courier Sendmail.

Yet, I am using same Courier Sendmail when sending for last years. I
do not know what was changed or not.
Post by Sergey Poznyakoff
Surprisingly, the message does contain the X-Mailer header that seems to
have been produced by mailutils.
Because it was.
Post by Sergey Poznyakoff
The only way I can interpret it, is that the message have been
reformatted by the receiving party upon arrival.
Because that stanza appears when I send it to me locally, it means
that local sendmail is reformatting something. It works locally, and
it works on Google, only not on Yahoo.
Post by Sergey Poznyakoff
Apart from these obvious facts, it is a perfectly valid MIME message,
that no sane mail reader can interpret as containing attachments.
Thank you.

I believe that, yet there is maybe some underlying cause, or maybe
Yahoo is simply wrong. Still I have to find it out.
Post by Sergey Poznyakoff
However, while I'm writing these lines, it strikes me that the content
type of the second MIME part contains the "name" attribute. While RFC
1341 does not explicitly forbid its use for the "inline" content
disposition, I can easily conceive that it may lead some MUAs astray.
If my guess is right, the attached patch should fix that.
I have tested with other tool to construct MIME with name attribute
being "HTML" and here is the raw message:
https://gnu.support/files/tmp/with-NAME-HTML.txt

and it was delivered fine to Yahoo, so that HTML is visible.

The difference I see is that GNU Mailutils makes header:

Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_stw1.rcdrun.com-1522-1492412035-0001-2"
Date: Mon, 17 Apr 2017 09:49:11 +0300

while the makemime utility which I use to construct other MIME
message, which is correctly shown,have it different, after the
Subject:

Subject: Hello there Ä<U+008D>Ä<U+008D> â„¢ omasdans kjnaksnd kjansdjkn akjnd jknajksnd ajksns
Content-Disposition: inline
Content-Type: multipart/alternative; boundary="=_1_1492435573_4015"
Content-Transfer-Encoding: quoted-printable
Message-ID: <***@protected.rcdrun.com>
Date: Mon, 17 Apr 2017 16:26:13 +0300


Maybe that order makes some difference, you know it better.

In any case the MIME with Name, that I send with makemime, does work
well, while from Mailutils not, and that one is that I would like to
make it work, for deliverability to Yahoo people.

Jean
Sergey Poznyakoff
2017-04-17 14:45:38 UTC
Permalink
Post by Jean Louis
In regards if it was created by GNU Mailutils or not, I would not be
putting these efforts to lie to you or create confusion, without
providing you true facts.
My intent was not, of course, to put into doubt the credibility of the
provided information, but to analyze the facts.
Post by Jean Louis
In any case the MIME with Name, that I send with makemime, does work
well, while from Mailutils not, and that one is that I would like to
make it work, for deliverability to Yahoo people.
I've proposed the patch. Did you test it? Did it help or not?

Regards,
Sergey
Jean Louis
2017-04-17 18:03:50 UTC
Permalink
Post by Sergey Poznyakoff
Post by Jean Louis
In regards if it was created by GNU Mailutils or not, I would not be
putting these efforts to lie to you or create confusion, without
providing you true facts.
My intent was not, of course, to put into doubt the credibility of the
provided information, but to analyze the facts.
Post by Jean Louis
In any case the MIME with Name, that I send with makemime, does work
well, while from Mailutils not, and that one is that I would like to
make it work, for deliverability to Yahoo people.
I've proposed the patch. Did you test it? Did it help or not?
I have applied the patch and it did not help.

Message is seen as being with 2 attachments.

Message that arrived:
https://gnu.support/files/tmp/2017-04-17-21:01:26-Monday.txt

Command line used:
mail -E \"unset askcc\" -a \"Date: `/bin/date +'%a, %d %b %Y %T %z'`\" -a \"Content-Type: text/plain; charset=utf-8\" -a \"Content-Disposition: inline\" -a \"Content-Transfer-Encoding: 8bit\" -a \"From: Jean Louis <***@rcdrun.com>\" -E 'set record=maildir:~/Maildir/***@yahoo.com' -s 'Hello there' --alternative --content-type=text/html --attach=/home/data1/protected/index.html \"Jean Louis <***@yahoo.com>\" --content-type=text/plain

In general, do you see anything wrong in that message that arrived?


Jean
Sergey Poznyakoff
2017-04-18 08:20:32 UTC
Permalink
Hi Jean,

Please try this.

Regards,
Sergey
Jean Louis
2017-04-18 08:59:14 UTC
Permalink
Post by Sergey Poznyakoff
Hi Jean,
Please try this.
Reportedly, yahoo mail reader misinterprets the Content-Disposition
header set in multipart/alternative MIME parts.
* mail/send.c (saveatt): Don't set Content-Disposition for
multipart/alternative.
---
mail/send.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Thank you, what you did, improved the situation, now the HTML email
becomes visible and does not appear as attachment.

I guess you removed the Content-Disposition: inline

In the email that I am constructed with makemime tool from Courier
MTA, I see after the Subject line, the Content-Disposition: inline,
and the email is working, only for your notice.

Now the email constructed by mail tool from Mailutils, is still
appearing in Yahoo, that there is "Text" as attachment.

The email constructed with makemime, also have the text and html part,
but text part is not appearing as attachment.

Do you think that in --alternative, also the text part shall not be
with Content-Disposition: inline?

That way text would not appear as attachment.

Jean
Sergey Poznyakoff
2017-04-18 09:48:44 UTC
Permalink
Post by Jean Louis
Do you think that in --alternative, also the text part shall not be
with Content-Disposition: inline?
The patch remove Content-Disposition from all parts. Can you show me
the received message?

Regards,
Sergey
Jean Louis
2017-04-18 10:02:07 UTC
Permalink
Post by Sergey Poznyakoff
Post by Jean Louis
Do you think that in --alternative, also the text part shall not be
with Content-Disposition: inline?
The patch remove Content-Disposition from all parts. Can you show me
the received message?
https://gnu.support/files/tmp/2017-04-18-13:00:40-Tuesday.txt

For some reason I see that still in the message.

Is it correct not to have Content-Disposition: inline in
multipart/alternative?


Jean
Sergey Poznyakoff
2017-04-18 10:19:50 UTC
Permalink
Jean, I've sent a test mail to your yahoo account. Please check it. Does it
show up correctly?

Regards,
Sergey
Jean Louis
2017-04-18 10:41:11 UTC
Permalink
It does show up correctly in Yahoo.
Post by Sergey Poznyakoff
Jean, I've sent a test mail to your yahoo account. Please check it. Does it
show up correctly?
Sergey Poznyakoff
2017-04-18 16:16:39 UTC
Permalink
Post by Jean Louis
It does show up correctly in Yahoo.
Ok. I have pushed a new changeset (partially related to your problem).
Please pull, and retry.

Regards,
Sergey
Jean Louis
2017-04-18 16:22:01 UTC
Permalink
Post by Sergey Poznyakoff
Post by Jean Louis
It does show up correctly in Yahoo.
Ok. I have pushed a new changeset (partially related to your problem).
Please pull, and retry.
Thank you much.

I have stashed the changes to send.c in order to pull from the git.

I am compiling and will let you know.

Not that I have intentions to satisfy the Yahoo mail reader. And the
only reason I have account there is that one client reported not to
have seen the email. Then I realized that 9500+ emails were sent to
Yahoo. At least those are periodical emails, so in the next run, they
will see it. It was possible to download files as attachments.

The email sending should be by standard, whatever Yahoo does, so I
hope that with my request, you did not disturb the standards of
sending such multipart emails.

Jean
Sergey Poznyakoff
2017-04-18 18:16:45 UTC
Permalink
Post by Jean Louis
I am compiling and will let you know.
Thanks. I'm looking forward to it.
Post by Jean Louis
The email sending should be by standard, whatever Yahoo does, so I
hope that with my request, you did not disturb the standards of
sending such multipart emails.
That's no problem, standards often leave sufficient leeway for
misunderstanding between client and server. The case we're handling is
just an example of this. Interoperability is very important, and I
appreciate very much your help ( and perseverance :) ) in resolving
this problem.

Regards,
Sergey
Jean Louis
2017-04-18 18:59:16 UTC
Permalink
Post by Sergey Poznyakoff
Post by Jean Louis
I am compiling and will let you know.
Thanks. I'm looking forward to it.
Post by Jean Louis
The email sending should be by standard, whatever Yahoo does, so I
hope that with my request, you did not disturb the standards of
sending such multipart emails.
That's no problem, standards often leave sufficient leeway for
misunderstanding between client and server. The case we're handling is
just an example of this. Interoperability is very important, and I
appreciate very much your help ( and perseverance :) ) in resolving
this problem.
Thank you. It is working now in Yahoo, I can see the message. It looks
like charset is being set automatically? The HTML file shows
iso-8859-1 and I just hope it does not disturb vieweing the HTML file
which has inside UTF-8 settings, I still think it can disturb it.

It can be that I caused this problem by adding the Content-Disposition
or by not using correctly the mail utility. Below you can find how I
am using it.

;;; GNU Mailutils functions

;;; echo "Hello" | mail -a "Date: `/bin/date +'%a, %d %b %Y %T %z'`" -a "From: Mr. John Doe <***@example.com>" -E 'set record=maildir:~/Maildir/***@example.com' -s "Test (DELETE ME)" ***@localhost

(defun mu-set-record (maildir)
(if maildir
(format nil " -E 'set record=maildir:~~/Maildir/~a' " maildir)
nil))

(defun mu-subject (subject)
(format nil " -s '~a' " subject))

(defun mu-from (name from)
(format nil " -a \"From: ~a <~a>\" " name from))

(defun mu-header-unicode ()
(concatenate 'string
" -a \"Content-Type: text/plain; charset=utf-8\" "
" -a \"Content-Disposition: inline\" "
" -a \"Content-Transfer-Encoding: 8bit\" "))

(defun mu-html-alternative (file)
(if (not (zerop (length file)))
(format nil " --alternative --content-type=text/html --attach=~a" file)
""))

(defun mu-to (name to)
(setf name (substitute #\- #\@ name))
(setf name (substitute #\. #\, name))
(setf name (substitute #\Space #\. name))
(if (> (length name) 0)
(format nil " \"~a <~a>\" " name to)
(format nil " \"~a\" " to)))

(defun mu-date ()
(format nil " -a \"Date: `/bin/date +'%a, %d %b %Y %T %z'`\" "))

(defun mu-attach (file)
(if (zerop (length (namestring file)))
""
(format nil " -A \"~a\" " file)))

(defun mu-attachments (attachments)
(if (listp attachments)
(format nil " ~{~a~} " (map 'list #'mu-attach attachments))
(mu-attach attachments)))

(defun mu-body-type (type)
(format nil " --content-type=~a " type))

(defun mu-mail (&key from-name from-email to-email (to-name "") subject (set-record to-email) body (attachments "") (html-alternative "") (test nil)
(body-type "text/plain"))
(let ((mu-mail (concatenate 'string
"mail -E \"unset askcc\" "
(mu-date)
(mu-header-unicode)
(mu-from from-name from-email)
(mu-set-record set-record)
(mu-subject subject)
(mu-html-alternative html-alternative)
(mu-attachments attachments)
(mu-to to-name to-email)
(mu-body-type body-type)
)))
(if test
(format t "~%FROM: ~a ~a, TO: ~a ~a, SUBJECT: ~a~%"
from-name from-email to-name to-email subject)
(values (with-input-from-string (s body)
(uiop:run-program mu-mail :input s :external-format uiop:*utf-8-external-format*))
mu-mail))))

;; (princ (cadr (multiple-value-list
;; (mu-mail :from-name "Jean Louis"
;; :from-email "***@example.com"
;; :to-email "***@yahoo.com"
;; :to-name "Jean Louis"
;; :subject "Hello there"
;; :body-type "text/plain"
;; :body "Text message here čekaj ™ ® "
;; :html-alternative "/home/data1/protected/public_html/index.html") ) ))

;; :attachments (list "/tmp/file" "/tmp/anotherfile")




and this one I use to send email by using makemime utility:

;; (ql:quickload "cl-rfc2047")

(defun makemime-send (text html &key from-name from-email to-name to-email subject)
(let* ((text-file "/dev/shm/text-file")
(html-file "/dev/shm/html-file")
(text-file (progn
(alexandria:write-string-into-file text text-file :if-does-not-exist :create :if-exists :supersede)
text-file))
(html-file (progn
(alexandria:write-string-into-file html html-file :if-does-not-exist :create :if-exists :supersede)
html-file))
(makemime-file "/dev/shm/makemime")
(makemime-set (alexandria:write-string-into-file (format nil "-j
(
-m
multipart/alternative
-a
Mime-Version: 1.0
-a
From: ~a <~a>
-a
To: ~a <~a>
-a
Subject: ~a
-a
Content-Disposition: inline
-e
quoted-printable
-C utf-8
(
-c text/plain
-C utf-8
~a
)
)
(
-c text/html
-N HTML
-C utf-8
~a
)
" (cl-rfc2047:encode from-name) from-email
(cl-rfc2047:encode to-name) to-email
subject text-file html-file) makemime-file :if-exists :supersede :if-does-not-exist :create))
(makemime (slurp-stream-io-command "makemime @-" makemime-set))
(sendmail (format nil "/usr/bin/sendmail -F \"~a\" -f ~a" from-name from-email)))
(string-to-command sendmail makemime)))

;; (send-example)

(defun send-example ()
(makemime-send
"Hello čč"
"<!doctype html public \"-//W3C//DTD HTML 4.0 Transitional //EN\">
<html>
<head>
<meta http-equiv=\"Content-Type\"
content=\"text/html; charset=utf-8\"> <title></title>
</head>
<body>
<h2>Hello there</h2>

<p>http://www.google.com</p>

<p>This is some text here. č</p>
</body>
</html>"
:from-name "Jean"
:from-email "***@example.com"
:to-name "Mr. L č™''"
:to-email "***@yahoo.com"
:subject "Hello there čč ™ omasdans kjnaksnd kjansdjkn akjnd jknajksnd ajksns"))

;; (send-example)
Sergey Poznyakoff
2017-04-19 07:56:40 UTC
Permalink
Hi Jean,
Post by Jean Louis
Thank you. It is working now in Yahoo, I can see the message. It looks
like charset is being set automatically? The HTML file shows
iso-8859-1 and I just hope it does not disturb vieweing the HTML file
which has inside UTF-8 settings, I still think it can disturb it.
You can specify charset with the --content-type option:

--content-type='text/plain; charset=utf-8'
Post by Jean Louis
(defun mu-header-unicode ()
(concatenate 'string
" -a \"Content-Type: text/plain; charset=utf-8\" "
" -a \"Content-Disposition: inline\" "
" -a \"Content-Transfer-Encoding: 8bit\" "))
That's useless -- none of Content-* options can be set from the command
line. You will get error messages for all three.
Post by Jean Louis
(defun mu-html-alternative (file)
(if (not (zerop (length file)))
(format nil " --alternative --content-type=text/html --attach=~a" file)
""))
To pass charset, I'd propose the following change:

(defun mu-html-alternative (file cset)
(if (not (zerop (length file)))
(format nil " --alternative --content-type='text/html; charset=~a' --attach=~a" cset file)
""))
Post by Jean Louis
(defun mu-body-type (type)
(format nil " --content-type=~a " type))
The same trivial change applies to this defun as well. Also, please pull.
I've just pushed ff1a8a6e, which makes --content-type apply to the
message read from stdin.

Regards,
Sergey
Jean Louis
2017-04-19 07:57:56 UTC
Permalink
Alright thank you, I am pulling, compiling
Post by Sergey Poznyakoff
--content-type='text/plain; charset=utf-8'
Post by Jean Louis
(defun mu-header-unicode ()
(concatenate 'string
" -a "Content-Type: text/plain; charset=utf-8" "
" -a "Content-Disposition: inline" "
" -a "Content-Transfer-Encoding: 8bit" "))
That's useless -- none of Content-* options can be set from the command
line. You will get error messages for all three.
The first one works for sure, the Content-Type: text/plain;
charset=utf-8
Post by Sergey Poznyakoff
Post by Jean Louis
(defun mu-html-alternative (file)
(if (not (zerop (length file)))
(format nil " --alternative --content-type=text/html --attach=~a" file)
""))
(defun mu-html-alternative (file cset)
(if (not (zerop (length file)))
(format nil " --alternative --content-type='text/html; charset=~a' --attach=~a" cset file)
""))
Post by Jean Louis
(defun mu-body-type (type)
(format nil " --content-type=~a " type))
The same trivial change applies to this defun as well. Also, please pull.
I've just pushed ff1a8a6e, which makes --content-type apply to the
message read from stdin.
Thank you, I will use this solution now.

Jean
Jean Louis
2017-04-19 08:55:38 UTC
Permalink
Post by Sergey Poznyakoff
The same trivial change applies to this defun as well. Also, please pull.
I've just pushed ff1a8a6e, which makes --content-type apply to the
message read from stdin.
I have now tested it, and it works just fine, the HTML file arrives as
UTF-8 with your tips and changes.

Jean

Jean Louis
2017-04-19 07:59:28 UTC
Permalink
Post by Sergey Poznyakoff
Post by Jean Louis
(defun mu-header-unicode ()
(concatenate 'string
" -a "Content-Type: text/plain; charset=utf-8" "
" -a "Content-Disposition: inline" "
" -a "Content-Transfer-Encoding: 8bit" "))
That's useless -- none of Content-* options can be set from the command
line. You will get error messages for all three.
Maybe it is useless, however, they get injected, and there was never
error message on them.

Jean
Sergey Poznyakoff
2017-04-19 08:16:03 UTC
Permalink
Post by Jean Louis
Maybe it is useless, however, they get injected, and there was never
error message on them.
Running your command line I get:

mail: Content-Type: not setting header
mail: Content-Disposition: not setting header
mail: Content-Transfer-Encoding: not setting header

Regards,
Sergey
Jean Louis
2017-04-19 08:14:31 UTC
Permalink
Post by Sergey Poznyakoff
Post by Jean Louis
Maybe it is useless, however, they get injected, and there was never
error message on them.
mail: Content-Type: not setting header
mail: Content-Disposition: not setting header
mail: Content-Transfer-Encoding: not setting header
mail -a "Content-Transfer-Encoding: 8bit" -a "Content-Type:
text/plain; charset=utf-8" ***@protected

Subject: ččček
ččlkekl
CTRL-D

and it comes just fine with those headings set. Not sure if they are
set correctly, yet they arrive.
Sergey Poznyakoff
2017-04-19 08:48:13 UTC
Permalink
FWIW, we were talking about sending MIME messages. The command line
above has nothing to do with the subject.

Regards,
Sergey
Jean Louis
2017-04-19 08:54:53 UTC
Permalink
Post by Sergey Poznyakoff
FWIW, we were talking about sending MIME messages. The command line
above has nothing to do with the subject.
You mean with --alternative? I guess all that is deleted in that mode.

Jean
Jean Louis
2017-04-18 19:02:10 UTC
Permalink
Post by Sergey Poznyakoff
Post by Jean Louis
The email sending should be by standard, whatever Yahoo does, so I
hope that with my request, you did not disturb the standards of
sending such multipart emails.
That's no problem, standards often leave sufficient leeway for
misunderstanding between client and server. The case we're handling is
just an example of this. Interoperability is very important, and I
appreciate very much your help ( and perseverance :) ) in resolving
this problem.
I have tested sending the HTML file and the charset is set to
iso-8859-1 and thus UTF-8 cannot be seen, I get: ®™ difficulties

The charset for text was set as UTF-8.

Jean
Loading...