Re: [bug-mailutils] multipart/alternative not displaying in Yahoo.com

[Jean Louis]

On Mon, Apr 17, 2017 at 03:52:10PM +0300, Sergey Poznyakoff wrote:
> Jean Louis <address@hidden> 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
> > <address@hidden>"  -E 'set
> > record=maildir:~/Maildir/address@hidden'  -s 'Hello there'
> > --alternative --content-type=text/html
> > --attach=/home/data1/protected/index.html "Jean Louis
> > <address@hidden>"  --content-type=text/plain
> 
> Thanks.  Let me notice that the Content-Disposition and
> Content-Transfer-Encoding settings have no effect.
> 
> > You need to replace address@hidden 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: <address@hidden>
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