mime encoding in 5.10.2

mime encoding in 5.10.2

[NAGY Andras]

Gnus 5.10.2 encodes a message with a plain us-ascii text part and an
attachment like this:

,----
| MIME-Version: 1.0
| Content-Type: multipart/mixed; boundary="=-=-="
| 
| --=-=-=
| 
| plain text
| 
| 
| --=-=-=
| Content-Type: application/octet-stream
| Content-Disposition: attachment; filename=printcap
| 
| attachment
| 
| --=-=-=--
`----


Note the missing content-type header for the text part.  Is this
behavior standards compliant?


Andras

Re: mime encoding in 5.10.2

[Katsumi Yamaoka]

>>>>> In <87smopgf5l.fsf@goldfish.local>
>>>>>	NAGY Andras <nagya@inf.elte.hu> wrote:

> Note the missing content-type header for the text part.  Is this
> behavior standards compliant?

That is probably based on RFC2045:

5.2.  Content-Type Defaults

   Default RFC 822 messages without a MIME Content-Type header are taken
   by this protocol to be plain text in the US-ASCII character set,
   which can be explicitly specified as:

     Content-type: text/plain; charset=us-ascii

   This default is assumed if no Content-Type header field is specified.
   It is also recommend that this default be assumed when a
   syntactically invalid Content-Type header field is encountered. ...

When a text part contains Japanese text, Gnus correctly puts the
Content-Type header like:

Content-Type: text/plain; charset=iso-2022-jp
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: mime encoding in 5.10.2

[Simon Josefsson]

NAGY Andras <nagya@inf.elte.hu> writes:

> Gnus 5.10.2 encodes a message with a plain us-ascii text part and an
> attachment like this:
>
> ,----
> | MIME-Version: 1.0
> | Content-Type: multipart/mixed; boundary="=-=-="
> | 
> | --=-=-=
> | 
> | plain text
> | 
> | 
> | --=-=-=
> | Content-Type: application/octet-stream
> | Content-Disposition: attachment; filename=printcap
> | 
> | attachment
> | 
> | --=-=-=--
> `----
>
>
> Note the missing content-type header for the text part.  Is this
> behavior standards compliant?

Yes, but I recall that Lars asked if we should change this, since it
confuses Outlook.  I'm not sure exactly what happens in Outlook
though.  If it plays a little melody and brings up an animated
interactive troll complaining about malformed messages, maybe it could
be entertaining to preserve the behavior, but if Outlook simply
crashes and bring down the OS too, maybe we should make the change.
Or the other way around.