Re: archive not showing all attachements

On Sat, Mar 26, 2022 at 10:41 AM Magnus Hagander <magnus(at)hagander(dot)net>
wrote:

>
> The problem is that:
> 1. It's not an attachment. That is:
> Content-Disposition: inline; filename="0001-doc_wip-diff.txt"
> explicitly says it's not an attachment.
>
> So the reason it's not listed as an attachment (per the subject of the
> email) is because it *isn't* an attachment.
>
>
> 2. We only show the first plaintext part of messages
>
> This is the actual problem. Our archives don't know how to merge
> multiple plaintext parts when they are set to be viewed inline and not
> as attachments.
>
>
It would be nice if our archive viewer conformed on the point that anything
showing inline show up, in order, in the "body" section of the viewer.
We'd probably add some structural separators to distinguish the parts.

If that is not possible then every part except the first needs to be made
accessible as an attachment regardless of the Content-Disposition
suggestion.

There is an argument for making every individual part of the message
individually downloadable, even inline ones, the first part included. I
think this would be nice, instead of the only way to save the message body
locally being to copy-paste, or to download the raw message which contains
more data than one probably wishes to download. This would be my
preference. We'd name the inline parts which lack filenames something like
"inline_n.ext" and decide the extension from the Content-Type. This does
bring up the question - what are we doing if an attachment doesn't also
have a filename?

If that UI choice goes too far, and we solve the multiple inline problem,
then we should at least provide a download option for any part that has a
filename provided. Inline parts with filenames would be shown on the
webpage body and would also have a download option. Frankly, for many
patches (small-ish ones at least) this would be an ideal combination, but I
doubt most people have fine enough control provided by their mail clients
to make these decisions intentionally and on a per-message basis.

I haven't tried to reconcile this with the cf bot's needs.

I also haven't worked through any dynamics involving child message parts
that are themselves multi-part messages. That seems like a "let the user
download it and figure it out themselves" thing instead of trying to make
our viewer interactive to the extent necessary to actually handle such a
message. Having some stats on whether we even encounter this situation
would help.

David J.