Re: patch attachments still unwelcome?

[Jani Nikula <jani.nikula@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]

On Mon, 04 Nov 2019, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Mon, Nov 4, 2019 at 2:13 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>>
>> On Fri, Nov 01, 2019 at 10:04:56AM +0100, Greg KH wrote:
>> > > So the documentation in the kernel advising against sending
>> > > patch attachments seems hypocritical.  Changing the kernel docs
>> > > allow patch attachments could be a good start to making life
>> > > easier for contributors without SMTP or IMAP access.
>> >
>> > It's not hypocritical, as lots of email clients still get this wrong and
>> > make responding to attachments almost impossible.  Many do get it right,
>> > but trying to document the differences here is quite difficult (I tried
>> > once, gave up as it was a mess).
>> >
>> > > Are many MUAs still incapable of handling them?
>> > > mutt shows text patches inline, at least.
>> >
>> > For most MUAs that send them, yes, but not for all.  I know of at least
>> > 2 that send text attachments in formats that mutt will not show it
>> > inline, nor allow responding to them properly.  MacOS Mail is one easy
>> > example to point to as getting this totally wrong.
>> >
>> > So, if you know what you are doing, yes, this is fine, but it's still a
>> > good idea to say "please do not do this" to make it easier for people
>> > just starting out.
>>
>> Perhaps we should explicitly explain this and then include a white
>> list of MUA's that can send text attachments safely/correctly?  (e.g.,
>> if you are using the following MUA's, using text attachments are OK;
>> if you are using the following MUA's, it will definitely NOT work;
>> with all others, proceed with caution.)
>
>
> One thing that wasn't clear to me when I implemented syzbot is that
> some people see attachments inline. syzbot included whole kernel
> config and 1MB of logs as attachments, I assumed that other people see
> them as, well, attachments. So that may be worth documenting as well.
> Though, I did not know that document exists as well, so it would not
> help me...

Typically you'd have a multipart/mixed MIME message with several parts
of various Content-Types. In this case presumably text/plain, but
text/x-diff is not out of the question for patches. Also seen a lot of
application/octet-stream for logs.

You can give a *hint* to the recipient MUA on how to interpret each part
by setting Content-Disposition: attachment or inline. Bottom line,
whether you can control that in your MUA, and whether the recipient MUA
actually respects that is anyone's guess.

For fun, this multipart message contains three parts, the one you're
reading, and two additional parts, one of which should be inline and the
other one an attachment.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

[-- Attachment #2: inline --]
[-- Type: text/plain, Size: 31 bytes --]

This is supposed to be inline.

[-- Attachment #3: attachment --]
[-- Type: text/plain, Size: 38 bytes --]

This is supposed to be an attachment.