On Mon, Apr 17, 2017 at 03:52:10PM +0300, Sergey Poznyakoff wrote: > Jean Louis <bugs@gnu.support> ha escrit: > > > 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 > > <yourem...@example.com>" -E 'set > > record=maildir:~/Maildir/myem...@yahoo.com' -s 'Hello there' > > --alternative --content-type=text/html > > --attach=/home/data1/protected/index.html "Jean Louis > > <myem...@yahoo.com>" --content-type=text/plain > > Thanks. Let me notice that the Content-Disposition and > Content-Transfer-Encoding settings have no effect. > > > You need to replace myem...@yahoo.com with your Yahoo address, > > 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. > > > 3. Raw content of the message as it arrived at the remote node. > > > > It is here temporary: > > 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 ());
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. > 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. > 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. > Surprisingly, the message does contain the X-Mailer header that seems to > have been produced by mailutils. Because it was. > 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. > 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. > 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: <courier.0000000058f4c275.00000...@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 _______________________________________________ Bug-mailutils mailing list Bug-mailutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-mailutils
